[elliotlarson]

I’m excited about this work. Having a faster Ruby would be some wonderful icing on the cake. But, for me, using Ruby (and Rails) has always been about optimizing for developer hours over system performance. IMO Ruby is not a race horse, but it’s plenty “fast”. The real value is how quickly my team can iterate, and how enjoyable the process is.

[pjmlp]

Languages like Smalltalk or Lisp can have it both ways, the problem with Ruby is the manpower to have a comparable JIT available, although MJIT isn't the only one already available.

[igouy]

> Languages like Smalltalk or Lisp can have it both ways...

You seem to be suggesting that Smalltalk implementations are a whole lot faster than current Ruby ?

They are a whole lot faster than Matz's 2008 Ruby 1.8.7 but so is current Ruby:

https://benchmarksgame-team.pages.debian.net/benchmarksgame/...

[pjmlp]

I don't any commercial versions there, which is what I was referring to.

[igouy]

If you meant to say that no commercial implementations are shown on the benchmarks game website — that is not true.

https://benchmarksgame-team.pages.debian.net/benchmarksgame/...

and

"Largest Provider of Commercial Smalltalk

...Cincom is the largest commercial provider of Smalltalk in the world, with twice as many partners and customers than all other commercial providers combined."

http://www.cincomsmalltalk.com/main/products/visualworks/

[igouy]

As for Lisp implementations [SBCL against LispWorks and Allegro] do you have reason to doubt the opinion you heard last year —

"Generally they are in the same league."

https://news.ycombinator.com/item?id=17482481

[joelbluminator]

Yep, agreed. I actually think Rails should focus on reducing memory rather than raw speed (though the two are probably connected).