Polling in real time always needs to be done in some compiled language. The good folks at 37 Signals ran into this when they launched their CampFire app.
For instance, consider what David Heinemeier Hansson says about Campfire, the chat software he helped developed. First written in Ruby On Rails, it soon became clear that the code that polls to see who is in the chat room needed to be as fast as possible:
"We rewrote the 100 lines of Ruby that handled the poll action in 300 lines of C. Jamis Buck did that in a couple of hours. Now each poll just does two super cheap db calls and polling is no longer a bottleneck. Campfire and a shared todo list is different because they’re not working on a shared resource. There’s no concept of locking. Or two people dragging the same item. So a 3 second delay between posting and showing up doesn’t matter. It does when you’re working on a shared resource."
False. Erlang is compiled natively via HIPE (the "High Performance Erlang" compiler, nice acronym!) on many platforms, and compiled to BEAM bytecode on the rest.
Running Erlang has some overhead, sure, but that's because it's designed for distributed systems where you can pull a plug out of the wall without interrupting service. I wouldn't use Erlang for number crunching, but using it as a glue language for a networked system hits all its strong points.
I didn't know that, I thought everything ran on beam. I guess the point is the canonical Ruby implementation is really slow when it doesn't need to be. It's not like it's a hard problem, or even that it hasn't already been solved (look at GemStone's Maglev: http://ruby.gemstone.com/)
I've stopped commenting about MRI entirely, it just makes people mad, and it's not even fun anymore. It's too easy. Still, I have to give Matz credit for making a language a lot of people sincerely love.
I know it's splitting hairs whether bytecode + a VM counts as compiled or interpreted (it's both, really), but compiling to bytecode rather than a pure interpreter usually makes enough of a difference performance-wise that it's worth giving some credit.
If people would just stop talking about Ruby 1.8, it wold allow for more meaningful discussion. 1.9 is a lot faster and has better support for concurrency.
I know, but often when people make that distinction, it's concerned with what performance ballpark the language has rather than strictly implementation issues.
For instance, consider what David Heinemeier Hansson says about Campfire, the chat software he helped developed. First written in Ruby On Rails, it soon became clear that the code that polls to see who is in the chat room needed to be as fast as possible:
"We rewrote the 100 lines of Ruby that handled the poll action in 300 lines of C. Jamis Buck did that in a couple of hours. Now each poll just does two super cheap db calls and polling is no longer a bottleneck. Campfire and a shared todo list is different because they’re not working on a shared resource. There’s no concept of locking. Or two people dragging the same item. So a 3 second delay between posting and showing up doesn’t matter. It does when you’re working on a shared resource."
http://www.ruby-forum.com/topic/62907
Later they tore out the C code and re-wrote it in Erlang.