Oh my. I like node, but that's a bunch of weird arguments. Most of them contain a kernel of truth, but jumping from that to node comes as some kind of non sequitur.
1) Version hell: No up-to-date packages on Linux distributions? As compared to the packages they have for a fictional stable node version?
2) Rails 3: I thought you were talking about sinatra? Where did Rails come into this?
3) Again with the versions. It would be nice to give a good reason why for him the push to 1.9 would be so important.
4) Speed: Yes, the V8 engine is quite fast. This won't matter for most of your work, though. Most of the heavy lifting for Node's event system is done by libev (written in C), the same that's underneath Eventmachine. Compared to I/O, it will hardly matter. And if it will, then moving to a compiled or JVM language will probably still be better.
5) Mobile: What's wrong with JRuby? It's closer to Dalvik than anything else. And again, what's the connection to node? You're not much better of there, never mind that it uses the same engine as in the (Froyo) browser.
6) Familiar frameworks: Not that familiar, as event-driven code has to be a bit different. But yeah, you've got a sinatra clone...
7) Javascript: Finally a good point. A single implementation language is usally quite nice, and not everyone wants to go the Seaside/Parenscript route.
Don't get me wrong, it might as well be a good decision, but these arguments are a bit immature, especially all the blabbing about Ruby 1.9, which isn't exactly the complete and utter miraculous revolutionary step.
Since when was EventMachine written in terms of libev? EventMachine, last time I looked (which is recently --- we write a lot of EM code here), has its own idiosyncratic event library.
Don't know with what I mixed that up (POE, probably. I know, libev is only an option there). Not that libev is a rather huge software, it's basically a wrapper around whatever the host OS provides (select, epoll, kqueue). From looking at it, eventmachines's C extension does the same. So my main point stands: A big part of the performance characteristics of node come from a lower-level C functionality. I guess that having an infrastructure that's mostly asynchronous comes second. Pure V8 speed won't matter that much for most tasks. If someone has counter-examples, I'd be pleased to hear them. As often with concurrency, better memory efficiency would probably win out.
It seems like the crux of his argument is speed. 1.8.x isn't fast enough, so they want to move to 1.9, but the community isn't moving to 1.9 fast enough, so they're moving to V8, which is fast.
I have no idea on who it is and I don't think it matters, but rather it was some interesting points and thought it was fitting to see where others on HN thought about it.
I actually tried to submit this as well before seeing it was already submitted.
My reason to submit it was that I thought it would be a interesting entry to a discussion about the current state of Ruby and to be specific 1.9.2/Rails3.
Miles' post was cross-posted to the Phoenix Ruby User Group list, which is where I first saw it (and where you can find a parallel thread).
What's interesting to me are the number of people attending the PRUG meetings who are increasingly exploring other languages.
There are different reasons for this; for some it's mostly intellectual curiosity, for others it's a preference for what language $foo can offer. (I'm in the middle ground, having gotten interested in Haskell as part of trying to expand my PL fu, and finding that it may be better long-term path than Ruby.)
At the last PRUG meeting we kicked around ideas for topics for future meetings. It wasn't limited to Ruby, and many people expressed an interest in hearing more about JavaScript, Node.js, and jQuery. In fact, the next PRUG meeting will be about the R language, and the meeting after that will have some folks (myself included) talking about jQuery. I think around October or November we'll get back to making Ruby the main topic of discussion. :)
That's more or less the same as what's happening at my local Ruby User Group in Amsterdam, last time it was all about JavaScript, Node and Coffeescript in particular.
Indeed I think it's great to see that people don't stay with one language!
I never was big on Ruby since writing JSON services with servlets and doing my UI in pure HTML / CSS / JavaScript gave me the same agile velocity. But I have to say writing JSON services with Node has become a more and more attractive proposition. It is so light weight and fast that I have been looking for the right project to get my feet wet on it.
A lot of the same comparisons could be made between Ruby/Rails and Java/Spring/Faces/Struts/Hibernate/etc when the Ruby/Rails combo first came out. That is to say, when a technology is in its early stages, fragmentation hasn't had a chance to set in. I think Node.js stands a pretty good choice of avoiding fragmentation for the near future, but that is only because it is a pretty raw implementation. Node.js is apples where Ruby on Rails is oranges.
Another thing the author would be wise to note that Node.js may not be ready for prime time just yet. The author has been attributed as saying such as recently as May of this year:
The API needs to stabilize a bit before I'd roll a large amount of code on top of it. If there's anything I've learned from Ruby on Rails, it's that you have to be prepared to tear in to a plug-in or module if the maintainer decides they're not going to maintain it with future versions of the technology that it plugs in to.
Overall, this rant jumps all over the place. We go from Sinatra, to Rails, to mobile. How is the switch from Sinatra to Node.js relevant to Ruby in a native mobile environment and also Rails? It's all just a little bit confusing.
I'm responsible for the app hosting environments at our company, so I understand the author's frustration with Ruby versions and the impending release of Rails 3. About 6 months ago, we started on a brand new web app and decided that we were going to look toward the future. We built it on top of Rails 3 (first beta) and Ruby 1.8.7. I literally had to compile various builds of Ruby 1.8.7 until I found one that would work with the first Rails 3 beta. We had to hold that configuration through Rails beta1 because we couldn't find a config that worked with Ruby, Rails, and all the plug-ins we are using. It has been painful. But now that Rails is closing in on a 3.0 release, and Ruby is closing in on 1.9.2, things seem to be coming together. Plug-in authors see a light at the end of the tunnel and are running toward it.
I also strongly disagree with the authors sentiment with regard to RVM. If there is a strong point to Ruby on Rails development, it is that every layer of the stack has received a lot of attention. RVM is an elegant solution, and it works well with bundler, which is integral to the Rails 3 release. Having pushed forward through several releases on top of Rails 3, RVM, and Capistrano, I can say with confidence that Rails app deployment has arrived. Mixing/managing Gem versions for production and staging environments in one OS environment is ready to rock. The one caveat being that there is no good solution for running more than one version of Ruby. The Passenger team is working on a solution to that, but I'm not sure we'll ever implement it. Running mixed Gems is one thing, running mixed interpreters in another. My preference is to keep some level of consistency at that layer.
I've not addressed all the author's points, because he's right about some things. Specifically speed and the "ooooooh shiny" mentality of most Rails developers. My lead developer is the best programmer I've ever worked with. I wouldn't trade him for anyone, but I do find it a constant battle to force a strict vetting process of new technologies. We went through no less than three authorization plug-ins during the early stages of app development on our most recent project, and the last revision consumed a not insignificant amount of time to strip from the project. I still feel like the trade-offs are worth it. At least for our project.
1) Version hell: No up-to-date packages on Linux distributions? As compared to the packages they have for a fictional stable node version?
2) Rails 3: I thought you were talking about sinatra? Where did Rails come into this?
3) Again with the versions. It would be nice to give a good reason why for him the push to 1.9 would be so important.
4) Speed: Yes, the V8 engine is quite fast. This won't matter for most of your work, though. Most of the heavy lifting for Node's event system is done by libev (written in C), the same that's underneath Eventmachine. Compared to I/O, it will hardly matter. And if it will, then moving to a compiled or JVM language will probably still be better.
5) Mobile: What's wrong with JRuby? It's closer to Dalvik than anything else. And again, what's the connection to node? You're not much better of there, never mind that it uses the same engine as in the (Froyo) browser.
6) Familiar frameworks: Not that familiar, as event-driven code has to be a bit different. But yeah, you've got a sinatra clone...
7) Javascript: Finally a good point. A single implementation language is usally quite nice, and not everyone wants to go the Seaside/Parenscript route.
Don't get me wrong, it might as well be a good decision, but these arguments are a bit immature, especially all the blabbing about Ruby 1.9, which isn't exactly the complete and utter miraculous revolutionary step.