5 ms·

What I can't understand is why Ruby's standard implementation still has such terrible performance after all these years. Yes, the language is quite complicated,

What I can't understand is why Ruby's standard implementation still has such terrible performance after all these years. Yes, the language is quite complicated, at least syntactically, but semantically it's similar enough to Smalltalk, and most Smalltalks have fast jitting VMs, including Squeak and Pharo (CogVM). The Ruby community is enormous by comparison and full of productive, opinionated developers who write tons of code, books, and blog posts, and yet the standard implementation (MRI) remains abysmal (sorry). It's really unfortunate that the MRI devs won't support Rubinius or event adopt RSpec to ensure interoperability with it: http://rubini.us/2014/12/31/matz-s-ruby-developers-don-t-use-rubyspec/ http://rubini.us/2014/12/31/matz-s-ruby-developers-don-t-use...

cageface 12y ago
I've wondered about this too and my best guess it that writing a good optimizing compiler for a dynamic language like Ruby or Javascript is quite difficult and beyond the abilities of most developers. The JS engines in the major browsers are only fast because tremendous resources have been devoted to making them fast. I don't think PyPy or Rubinius have had anything close to the same level of investment. This is why I think JS is pretty much guaranteed to "win" the dynamic language race in the long run.
- pjmlp 12y ago
  Alongside Julia, most likely.
- MrBra 12y ago
  You're reasoning is taking a bit too much for granted that the best engineered solutions will be the ones coming off big corporations investments but in this field this has been proven wrong many times... that's not always the one and only win factor.. fortunately.
  - cageface 12y ago
    It's true that LuaJit is mostly the work of one person, as far as I understand. Maybe talent does take precedence in most cases. But the incentive for browser developers to improve and optimize JS is just vastly stronger, despite its flaws, for practical reasons. The impact of the work is just orders of magnitude larger.
vidarh 12y ago
Part of the problem is that one of Ruby's good sides is that most of the time, it does what you want without requiring most developers to delve into the darker corners of the language. Or indeed care much about performance. While there are lots of productive, opinionated Ruby developers, the vast majority of us don't know much about the internals of the language. Heck, for my part I'm working on a Ruby compiler (and have been writing about it for 7 years now... Unfortunately I have far too little time to devote to it), and part of the challenge is that there's no proper language spec and even most people working on MRI does not know the full semantics of the language. My favourite example of this, is that for a long time during the 1.8.x, the inheritance of one of the core classes was different than what was documented - I wrote an article about the Ruby object model and was "corrected"; except my diagram had been created based on instrumenting the interpreter to verify what actually happened. It was like that for years without anyone noticing (and to be fair, it was a dark corner of the language - very little code depends on the specifics of the inheritance of the eigenclasses of the core classes). Of those of us who love Ruby and are interested in compiler technology and have the motivation to slog it out to try to get working compilers - whether JIT or AOT - there are extremely few. And most of that effort is going into JRuby, which is definitively seeing some impressive improvements (e.g. with Truffle) but which a lot of us avoid because of the JVM. Ruby will get faster. And will get better implementations, but it may still take some time to have much impact.
Argorak 12y ago
MRI is using RubySpec (RSpec is something different). http://rubyci.org/ http://rubyci.org/ The issue is more complex than Brian puts it. https://lobste.rs/s/oozjtg/matz_s_ruby_developers_don_t_use_rubyspec_and_it_s_hurting_ruby/comments/z17jc5#c_z17jc5 https://lobste.rs/s/oozjtg/matz_s_ruby_developers_don_t_use_... Also, MRI makes great improvements every version _while keeping breaking changes rather low_. Changing a running system is hard. If jitting is what you want, JRuby is a very good option.
- YorickPeterse 12y ago
  At the time of terminating RubySpec not a single MRI contributor had committed any code back to the main RubySpec repository for over a year. Sure, they might use it in terms of "run the specs" but they never contributed anything back. Besides their fork was highly outdated compared to the original repository. Besides that I don't really get the fuzz about the particular tweet mentioned. This was in regard to various small changes being made that while nice were not very significant in the grand scheme of things.
  - Argorak 12y ago
    That's because they decided to drop their efforts in 2013, because RubySpec broke their build. Sure, it's a political debate, but just saying they don't run it also isn't honest.

cageface 12y ago

I've wondered about this too and my best guess it that writing a good optimizing compiler for a dynamic language like Ruby or Javascript is quite difficult and beyond the abilities of most developers. The JS engines in the major browsers are only fast because tremendous resources have been devoted to making them fast. I don't think PyPy or Rubinius have had anything close to the same level of investment. This is why I think JS is pretty much guaranteed to "win" the dynamic language race in the long run.

pjmlp 12y ago
Alongside Julia, most likely.
MrBra 12y ago
You're reasoning is taking a bit too much for granted that the best engineered solutions will be the ones coming off big corporations investments but in this field this has been proven wrong many times... that's not always the one and only win factor.. fortunately.
- cageface 12y ago
  It's true that LuaJit is mostly the work of one person, as far as I understand. Maybe talent does take precedence in most cases. But the incentive for browser developers to improve and optimize JS is just vastly stronger, despite its flaws, for practical reasons. The impact of the work is just orders of magnitude larger.

vidarh 12y ago

Part of the problem is that one of Ruby's good sides is that most of the time, it does what you want without requiring most developers to delve into the darker corners of the language. Or indeed care much about performance. While there are lots of productive, opinionated Ruby developers, the vast majority of us don't know much about the internals of the language. Heck, for my part I'm working on a Ruby compiler (and have been writing about it for 7 years now... Unfortunately I have far too little time to devote to it), and part of the challenge is that there's no proper language spec and even most people working on MRI does not know the full semantics of the language. My favourite example of this, is that for a long time during the 1.8.x, the inheritance of one of the core classes was different than what was documented - I wrote an article about the Ruby object model and was "corrected"; except my diagram had been created based on instrumenting the interpreter to verify what actually happened. It was like that for years without anyone noticing (and to be fair, it was a dark corner of the language - very little code depends on the specifics of the inheritance of the eigenclasses of the core classes). Of those of us who love Ruby and are interested in compiler technology and have the motivation to slog it out to try to get working compilers - whether JIT or AOT - there are extremely few. And most of that effort is going into JRuby, which is definitively seeing some impressive improvements (e.g. with Truffle) but which a lot of us avoid because of the JVM. Ruby will get faster. And will get better implementations, but it may still take some time to have much impact.

Argorak 12y ago

MRI is using RubySpec (RSpec is something different). http://rubyci.org/ http://rubyci.org/ The issue is more complex than Brian puts it. https://lobste.rs/s/oozjtg/matz_s_ruby_developers_don_t_use_rubyspec_and_it_s_hurting_ruby/comments/z17jc5#c_z17jc5 https://lobste.rs/s/oozjtg/matz_s_ruby_developers_don_t_use_... Also, MRI makes great improvements every version _while keeping breaking changes rather low_. Changing a running system is hard. If jitting is what you want, JRuby is a very good option.

YorickPeterse 12y ago
At the time of terminating RubySpec not a single MRI contributor had committed any code back to the main RubySpec repository for over a year. Sure, they might use it in terms of "run the specs" but they never contributed anything back. Besides their fork was highly outdated compared to the original repository. Besides that I don't really get the fuzz about the particular tweet mentioned. This was in regard to various small changes being made that while nice were not very significant in the grand scheme of things.
- Argorak 12y ago
  That's because they decided to drop their efforts in 2013, because RubySpec broke their build. Sure, it's a political debate, but just saying they don't run it also isn't honest.