Is Ruby Dying?

New submitter John Moses writes "I have been working with node.js a lot lately, and have been discussing with co-workers if node.js is taking steam away from Ruby at all. I think the popularity of the language is an important talking point when selecting a language and framework for a new project. A graph on the release date of gems over time could help determine an answer. The front page of RubyGems only shows data on the most popular, but I am really interested in seeing recent activity. My theory is that if developers' contributions to different gems is slowing down, then so is the popularity of the language."

Comments

Short answer: no

[gentryx]

Long answer: a better indicator is how many Google queries for the respective languages are issued. And those suggest that Ruby is standing stronger than ever. Ruby is more than just Rails. And just because there is yet another web apps framework, it doesn't mean that the other ones automatically lose traction.

Re:Short answer: no

[hjf]

Silly programmer, you're not an "coder"! You don't know what's cool and what's not. Look at that UID. You must be like, 35! Yuck, old people!

Re:Short answer: no

[lgw]

How about picking the best tool for the job, rather than holding a popularity contest? Too old-fashioned?

It's good to avoid going too far off into the weeds, lest you find it impossible to hire someone to support code in some pet language, but that's not the concern here. Of the universe of languages, both mainstream and niche languages commonly used in your niche, pick the one that makes it easiest to develop and support the features in front of you.

It's pretty obvious someone is playing "what language will look best on my resume" here, and if playing that game is obvious to me from this distance, it will be glaring to hiring managers. Few people are looking for a history of "trendy" (you'd be amazed how fast "trendy" becomes "sad" in tech), while a history of doing the dirty, unpopular, work that keeps development teams productive is always welcome, long after the tech stack fades into obsolescence.

Re:Short answer: no

[Anonymous Coward]

Interesting that even though PHP's interest has declined over time (according to the same chart), it's still more popular than Python & Ruby combined.

Re:Short answer: no

[Lisias]

Nice try (intentionally spelling "java script" is not cute, dude!).

Here, I fixed it to you.

Not a surprise, anyway.

Re:Short answer: no

[Tumbleweed]

Look at that UID. You must be like, 35! Yuck, old people!

Careful there, kid. :)

Re:Short answer: no

[hjf]

Eeeeeeeeeewwwwwwwwwwww dirty old man!

Re:Short answer: no

[kelemvor4]

How about picking the best tool for the job, rather than holding a popularity contest? Too old-fashioned?

It's good to avoid going too far off into the weeds, lest you find it impossible to hire someone to support code in some pet language, but that's not the concern here. Of the universe of languages, both mainstream and niche languages commonly used in your niche, pick the one that makes it easiest to develop and support the features in front of you.

It's pretty obvious someone is playing "what language will look best on my resume" here, and if playing that game is obvious to me from this distance, it will be glaring to hiring managers. Few people are looking for a history of "trendy" (you'd be amazed how fast "trendy" becomes "sad" in tech), while a history of doing the dirty, unpopular, work that keeps development teams productive is always welcome, long after the tech stack fades into obsolescence.

All these pseudo-languages look bad to me when I review resume's. If you want to impress, learn C, C++, Assembler, or a few other real languages. Ruby, C$, VB, Python etc... those can be picked up on the fly if needed.

Re:Short answer: no

[SuricouRaven]

Learn C. Almost everything else draws from it. Learn C, and you're half-way to learning anything else.

Re:Short answer: no

[dunkelfalke]

The problem with it is that if you learn C as first language, you probably will always write C in any language. With all the ugly hacks and trying to reinvent the wheel time and time again.

I write in C for a living, but frankly, while I love my job, I don't like the language. It is just a bit more high level than a macro assembler and full of crazy behaviour.

Re:Short answer: no

[lgw]

I got hired at both my current and previous jobs with no expertise in the languages used, and paid quite well. Experience with the problem domain, and with doing the dirty jobs senior devs volunteers for (because dammit we can't keep working this way) is what matters. In my experience, it's only really the bottom-feeder companies that are looking for a very specific tech stack instead of "smart enough to come up to speed;" the kind of places you work when you're desperate for anything, not what you want to steer towards!

Re:Short answer: no

[shutdown -p now]

the compiler is free to rearrange the order of the fields as it sees fit.

No, it is not. ISO/IEC 9899:1999, 6.7.2.1 "Structure and union specifiers", paragraph 13:

"Within a structure object, the non-bit-field members and the units in which bit-fields reside have addresses that increase in the order in which they are declared. A pointer to a structure object, suitably converted, points to its initial member (or if that member is a bit-field, then to the unit in which it resides), and vice versa. There may be unnamed padding within a structure object, but not at its beginning."

The C++ standard has a similar provision. What's unspecified is whether there is any padding between the fields.

Re:Short answer: no

[shutdown -p now]

Oh, one other thing that's different in C++: the relative order of fields in a struct/class in different visibility blocks is unspecified. So, for example, in this one the fields must be ordered:

class foo {
public:
  int x;
  int y;
  int z;
};

Whereas in this one, x and y must be ordered exactly as specified, but z may precede or follow them:

class foo {
public:
  int x;
  int y;
public:
  int z;
};

Netcraft Confirms It

[Anonymous Coward]

It is now official. Netcraft has confirmed: Ruby is dying.

One more crippling bombshell hit the already beleaguered Ruby community when IDC confirmed that Ruby market share has dropped yet again, now down to less than a fraction of 1 percent of all languages. Coming on the heels of a recent Netcraft survey which plainly states that Ruby has lost more market share, this news serves to reinforce what we've known all along. Ruby is collapsing in complete disarray, as fittingly exemplified by failing dead last in the recent programmers survey.

You don't need to be the Amazing Kreskin to predict Ruby's future. The hand writing is on the wall: Ruby faces a bleak future. In fact there won't be any future at all for Ruby because Ruby is dying. Things are looking very bad for Ruby. As many of us are already aware, Ruby continues to lose market share. Red ink flows like a river of blood.

not dying in DevOps

[thule]

Chef and Puppet are huge in DevOps. It seems Ruby has found its niche.

But Node.JS IS WEBSCALE

[Billly Gates]

Node.js invents threading/processes and is webscale.

The best part is once you start coding it you will find yourself with a neat trimmed beard in designer plaid in a hip coffee shop listening to music not even out yet with 2 georgous ladies by your side giggling and being turned on by your most awesome code that is on your laptop screen.

Re:But Node.JS IS WEBSCALE

[Animats]

But it's web scale.

The event/callback/state machine model is a pain to program in, but at least you don't have race conditions on shared data. Also, now that most Javascript programmers are aware that the language supports closures, callbacks aren't so hard to code properly.

The classic problem with threads is that the usual locking primitives (which are almost always variants on the POSIX primitives) are treated as an OS object, rather than part of the language. For most languages, the language has no idea of which locks lock what data. Ada gets this right, but the Ada rendezvous is clunky. Even Go gets this wrong. (See the endless discussions of "is this a race condition?" in the Go newsgroup.) So race conditions are common in threaded software, and a cause of random failures.

Practical problems with threads include crappy implementations of lock primitives that make a system call even in the non-blocking case, the cost of fencing on superscalar CPUs, and poor scheduler coordination between context switching and message passing.

Most of those issues are way too theoretical for the average web programmer. It's better that they not have to think about them. There's a lot of web code to be written and we don't want to waste the good people on it.

Node.js

[thammoud]

We had to swallow a dagger and use JavaScript on the client as it is the only game in town. Please someone, enlighten me, why would I use this horrific language on the server side? What exactly am I missing? What is so great about Node.js that warrants having to deal with JS.

Re:Node.js

[countach74]

JavaScript is rather misunderstood. It does, indeed, have issues--perhaps more than other languages (I'd say certainly more than say, Ruby or Python). But it has merits as well that most people overlook or simply don't know about. It is, for instance, very expressive. Particularly in the server-side programming realm, NodeJS has a few advantages to it that most other languages / frameworks don't (or require more difficulty in implementing), such as:

1. Naturally asynchronous, NodeJS allows vastly more I/O than a similar threaded solution. Need to implement long polling for 2,000 concurrent users? Not a problem.

2. The ability to share libraries and other code effortlessly between server-side and client-side applications.

Some of the down sides to NodeJS are that, well... it uses JavaScript. Seriously, though, it could be worse: it could be PHP. JavaScript really isn't that bad, once you actually learn the language. I hated it until fairly recently because I didn't really understand it. Now that I've spent some time learning its intricacies and quirks, I am much more productive with it. I can even enjoy using it. Would I prefer using Python? Absolutely. But it's really not so bad.

Moving forward though, I think one of the biggest problem with JavaScript in general is that we have far too many people who know just enough JavaScript to be dangerous that trying to establish high community standards will be very, very hard. In fact, one of the reasons I like Python so much is not that Python itself is all that great (it, too, has issues), but rather that there are countless excellent, well maintained, well designed libraries available. The same is simply not true for JavaScript in general.

Re:Node.js

[countach74]

No, more like: http://pastie.org/private/ij3rdcgtkgteefgwj57mfg

I realize that's just an example of simple inheritance, but not bad for using nothing more than functions and prototypes. Yes, it's a little verbose. You can also do prototypal inheritance, etc. The point is that with just a couple of constructs, JavaScript can do things that most languages must separate into many more statements, expressions, etc. But to clarify, I am *not* saying JavaScript is awesome; it clearly has limitations. But it is pretty amazing what all can be done with such a simple language. It is misunderstood.

Re:Nope (title capitalization sucks, btw)

[Anonymous Coward]

No. Next question, is Slashdot dying?

Slashdot will be dead as soon as the new "design" comes out.

Obligatory: She's dead, Jim.

[PNutts]

Damit Jim, I'm a doctor, not a developer in a dynamic, reflective, object-oriented, general-purpose programming language that supports multiple programming paradigms, including functional, object oriented, and imperative.

Thank you, Wikipedia.

Wrong. We in industry are very upset with Ruby.

[Anonymous Coward]

Those of us in industry are very fed up with Ruby and Ruby on Rails, but I think it's much more because of their communities than it is because of the technologies themselves.

I don't know if there's a polite way of saying this, but far too many of the people involved with those communities are utter disasters who in turn create utterly disastrous software systems. For every Ruby success story we may hear about, there are probably 10 or 20 total disasters that aren't as widely known. The disasters are usually because of the people involved, not the technologies.

Those of us who've been in the industry for many years, if not decades, and have had to engage in hiring over the past 8 or so years will know what I'm talking about. We have to deal with candidates who have no formal education at all in computer science, software engineering, or a related field. They don't even have the equivalent of a single four-month community college programming course. If we're lucky, they've read a single book about web development using Ruby on Rails. (This is ignoring their other serious flaws, such as the complete inability to dress or act with even a minimal level of professionalism; I've interviewed some of these hipsters while they're wearing t-shirts with dumbass sayings on them, and fedora hats.)

Now, having been in the industry for years, I can see right through these people. When they get past HR, they don't get past me. But I can't be everywhere. I've worked with a few organizations lately where the people making the hiring or purchasing decisions in the past didn't know better, and now these organizations have ended up with their very own Ruby on Rails disasters.

The Ruby community may not realize it, but they're getting a very bad reputation in the industry. It's nearly as bad as the reputation that the PHP and JavaScript communities have now. But this is exactly what's expected to happen when dealing with programmers who do shitty work in the first place, or who think it's perfectly normal to write unmaintainable code, or who think it's acceptable to job hop 3 or 4 times a year, or who can't work in a professional manner, or who deliver one under-performing and costly software disaster after another.

At more and more places, "Ruby" and "Ruby on Rails" are becoming synonyms for "costly disaster". That's not the kind of reputation that a programming language or a web framework can have if it wants to survive and flourish past the short term. Maybe the people in these communities don't realize it, but they're losing trust at an alarming pace.

Short answer: yes.

[hessian]

Trends always die.

All-purpose languages that adapt over time are better tools to learn.

You learn more in depth, instead of having certain tasks be very easy.

This is similar to the trade off between wizard-based interfaces and actually knowing what you're doing with an operating system.

Re:ruby is obnoxious

[larry bagina]

For quick and dirty scripts, you can just define your methods and variables and not deal with classes. They're added to the main object, much like javascript globals and functions are added to the window object.

Re:Finally got it

[rk]

Hmmm. 46 here. And apparently still too fast for Slashdot who tells me to "Slow down, cowboy!"

So in other words, Ruby is running off the rails?

[JoeyRox]

:snicker:

Re:He's not "conceited". He's absolutely correct!

[tibman]

Bad language or not, it is already used heavily on the client-side. Using it server-side allows you to make use of the same objects without having to maintain things like validation logic in two languages. It also means that if you are using Karma or something similar for testing that you only need one testing framework. Otherwise you'd need two testing frameworks running. Switching gears from one language to the next isn't hard but going from strongly typed to dynamic often results in developers trying to strongly type their javascript or writing it in such a way that it becomes too rigid. Tests should be governing everything anyways, especially if it is TDD.

My company is using C# on the back-end and javascript on the front. I write php+javascript at home though (and have experienced a life-time of derision from "professional" developers for it). I still write C/C++ for linux and embedded projects. Too many developers have decided their language is the best and everything else is horrible. When really, every language is covered in warts. Every language has (had) growing pains. Have you ever wondered why if your language is the best it is rarely used in all situations? That's because it's not the best tool for every job.

Your kind is nothing new. Anyone who has a passion for programming runs into people with your attitude and just shrugs. It is almost like dealing with a form of bigotry.