Twitter, Ruby on Rails, Scala and people who don’t RTFA

In the early days of web apps, you could mostly get by with Perl, SQL, HTML and a little bit of Javascript for mouseovers and whatnot. Framework? CGI.pm, baby.

Now you generally need HTML, CSS, Javascript, a Javascript framework, a backend language of choice, a framework of choice in that language, a high-performance backend language of choice for the critical bits, and SQL.

I did web apps from 1997 to 2001 and then picked back up in early 2008. It was pretty dizzying at first just knowing where to start. In the systems / multimedia world where I lived in the 7 years between it was C or C++ and a framework.

So what's the connection to the story? I think it's in the web world, perhaps as a result of its relative infancy, we apparently have to get used to the fact that the right solution to a problem is often using mixed-mode programming where individual tools are selected for individual tasks -- that development abilities in the web world is as much a question of breadth as depth. We shouldn't be so disenfranchised that our tools aren't general purpose.

The last two statements don't mean the first is true. Ruby's power is not the reason it's slow. Smalltalk VMs are proof by existence that the Ruby model can be fast. (See: Self, Strongtalk, Gemstone.) MagLev showed that Ruby is basically just an alternative Smalltalk syntax.

Charles Nutter, one of the creators of the JRuby VM for the Ruby language, recently posted an article about optimizations that could be made to the VM, and he improves Ruby performance by as much as twenty times by removing much of Ruby’s power and breaking compatibility.

"Remove much of Ruby's power"? Around 0.2% of Charles's speed-up came from removing the ability to override the primitive math operations. Other than that, his speedups removed none of Ruby's power.

(And nit-picking: Ruby is probably the most powerful programming language on the planet for creating DSLs, or domain specific languages. It can do this because any class or object can be extended, any method overridden, any constant undefined and redefined, and so on, and so forth.

Not true:

  >> class StrangeArray < Array; def [](x); x; end; end
  nil
  a = StrangeArray.new(10)
  => [nil, nil, nil, nil, nil, nil, nil, nil, nil, nil]
  >> a.map{|x| x}
  => [nil, nil, nil, nil, nil, nil, nil, nil, nil, nil] # wrong
  >> (0..(a.size - 1)).map{|x| a[x]}
  => [0, 1, 2, 3, 4, 5, 6, 7, 8, 9] # right

(Edited to correct example, as pointed out by hjdivad)

"Ruby is probably the most powerful programming language on the planet for creating DSLs, or domain specific languages."

If Ruby has anything over Lisp in the DSL domain (besides popularity), I'd love to know.

"A web development platform as powerful and syntactically concise as Rails could only have been done in Ruby."

Idem.

"This power does not come without a price. Ruby is slow. Ruby is generally recognized as being twice as slow as Python, and at least an order of magnitude slower than C++ or Java. Charles Nutter, one of the creators of the JRuby VM for the Ruby language, recently posted an article about optimizations that could be made to the VM, and he improves Ruby performance by as much as twenty times by removing much of Ruby’s power and breaking compatibility. If anything, it shows us skeptics that there is no such thing as a free lunch."

Lisp has all (?) the crazy features you love so much about Ruby and more, yet it's very fast (try SBCL, it compiles to native x86).

http://blog.headius.com/2009/04/how-jruby-makes-ruby-fast.ht...

is really outstanding. It shows you exactly why a language like Ruby is inherently slower than a language like Java. Mainly, because Ruby does a lot more work to give you the cool, dynamic capabilities that make people like Ruby in the first place. Of course, much of the cool work on speeding up dynamic languages like Javascript and Ruby is all about analyzing code to find places where you can safely make assumptions about the code (+ is not overridden here, so I can use the built in integer addition operator, etc.).

(I probably oversimplified that, but I hope it captures the general idea.)

The "Duby" language at the end makes me think of Common Lisp and how you can optionally declare types the compiler can use to compile faster code. Would it be worthwhile to add optional typing to Ruby?

Am I the only one who has never heard of this? I'd definitely be curious to see some relevant benchmarks if anyone has any.

Multiple ways to create literal strings so you can save escaping things inside of them or save some other action.

Closures with one block shortcut per method so you can save a little more characters there.

These things encourage the developer to revisit their implementations and cut the redundancies much more.

The p method coupled with the inspect feature that gives you the description of a certain object so you can debug it or at least see its content very easily.

No use comparing Ruby to LISP and Smalltalk in some "power subjectivity"... Ruby is hackish and used by "hackers" alike. It's not perfect of course...

And I liked this article for it put into better words what I wrote in some comments on the original article.

For example, yesterday I caused an infinite loop in my Rails controller because I forgot the "@" in front of a variable that had the same name as the action - so Ruby interpreted it as a method call, not a variable reference. Being able to call methods without "()" is part of the Ruby-DSL stuff, but I wonder if typing "()" would not actually be the lesser pain in the end. I probably lose much more time to hunting such bugs than I lose time typing ().

It actually slowed down the queue by about a factor of 10.

Maybe the jvm offers GC benefits on massive hardware, but I have not been pleased at all so far.