Is Ruby Dying? 400
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."
Node.js (Score:5, Interesting)
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 (Score:2, Interesting)
What's great about Node.js is that it doesn't warrant hiring actual programmers.
Wrong. We in industry are very upset with Ruby. (Score:5, Interesting)
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.
Re:Node.js (Score:4, Interesting)
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:But Node.JS IS WEBSCALE (Score:4, Interesting)
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.
Re:Short answer: no (Score:5, Interesting)
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!