3 ms·

I don't know if it's the lack of types Ruby is a dynamic language, so no, there are no types as such. There are ways to create types, but if you're doing that

I don't know if it's the lack of types Ruby is a dynamic language, so no, there are no types as such. There are ways to create types, but if you're doing that a lot, you're probably doing Ruby wrong. It's not meant to have types. Different way of thinking. the abysmal performance of the default VM That's a myth, a pervasive one. I'll point you to one source that debunks this, but there are many. http://www.unlimitednovelty.com/2012/06/ruby-is-faster-than-python-php-and-perl.html http://www.unlimitednovelty.com/2012/06/ruby-is-faster-than-... the heavy reliance on monkey patching Monkey patching is generally considered an anti-pattern. I'm not sure what in particular has "heavy reliance" on it, but it's not Ruby's libraries themselves, and it's not Rails. (Metaprogramming is not the same thing as monkey patching.) Ruby is not aging very well. IMHO Ruby is just now coming fully into its own, and is, for a young language, just reaching maturity.

namidark 13y ago
I would hardly say the performance of the default VM is a myth... just look at performance characteristics under multi-threading and GC pressure.
- bhauer 13y ago
  Speaking of Ruby performance, we haven't received a whole lot of pull requests improving the performance of the Ruby implementations on our benchmarks project [1]. If you feel Ruby isn't getting a fair shake on performance measurements, we'd love to see some pull request love. [1] http://www.techempower.com/benchmarks/ http://www.techempower.com/benchmarks/
  - laureny 13y ago
    That's quite a weird angle. Surely I can express unhappiness about a product's performance without being asked to fix it or to shut up?
    - bhauer 13y ago
      I think we're on the same side here. We've measured the performance of the fundamentals of web applications on two Ruby implementations (MRI, JRuby) and both perform poorly, as compared to the rest of the field. area51org says that Ruby's reputation of slowness is undeserved. I feel our data confirms the reputation. In fact, I don't think there's much room for improvement by tweaking our tests, but I figured I'd make the solicitation anyway to keep an open mind about it. I'm not asking you to fix it or shut up, especially since I feel your point of view is corroborated by the data. I am asking, however, for those who say Ruby's reputation is undeserved to consider providing some evidence for that point of view. And one conceivable way to do that would be to improve our Ruby tests.
  - pkroll 13y ago
    I asked about this in another thread that you responded to, and appreciated your answer. (Which had a bunch of links and a strong implication of "well, since you ASKED, here's what you need to go do something about it..." :) ) Given how little code there is in the Ruby/Rails tests there, it doesn't look like a lot of opportunity exists for speeding up the benchmarks by changing that code... but maybe it could be sped up by changing the gems. There are several JSON gems, at least one of which claims to be faster by 2-3x. In the PHP universe there's Phalcon, a C plugin to handle a lot of the work that otherwise would be done in raw PHP. It has good performance versus the other PHP frameworks (not up to the raw PHP numbers). Why hasn't this become the norm? I'm not asking bhauer, folks: why not replace chunks of the code that are slow but have been pretty stable (Rack comes to mind, but other chunks of Rails are probably good contenders) with C plugins/gems? We already commonly use Nginx or another server for static content, why not push that further? Hell, how much similar code could be put to use in other frameworks if the core was done in C/C++ or Java? The focus on the singular language as the only way to do any given framework seems to waste an amazing amount of code, and performance.
LukeShu 13y ago
> and it's not Rails. Yes it is. ActiveSupport (part of Rails) monkey-patches the core library.
- area51org 13y ago
  It does, but it doesn't heavily rely on this, as the poster was contending. It merely adds some helper methods.
damncabbage 13y ago
That's a myth, a pervasive one. I'll point you to one source that debunks this, but there are many. http://www.unlimitednovelty.com/2012/06/ruby-is-faster-than-python-php-and-perl.html It's unfortunately compromised by some boneheaded things in the MRI implementation. Method caching is a great example: https://charlie.bz/blog/things-that-clear-rubys-method-cache https://charlie.bz/blog/things-that-clear-rubys-method-cache (Rails startup does a lot of the mentioned things, for example, but then so do a lot of apps' controller actions unless they're careful. The OpenStruct example is particular egregious.)
laureny 13y ago
> IMHO Ruby is just now coming fully into its own, and is, for a young language Young? Ruby is 18 years old, it's certainly not a young language.
- dragonwriter 13y ago
  > Young? Ruby is 18 years old, it's certainly not a young language. Well, its not young compared to Go, but its young compared to C or Lisp or Smalltalk.

namidark 13y ago

I would hardly say the performance of the default VM is a myth... just look at performance characteristics under multi-threading and GC pressure.

bhauer 13y ago
Speaking of Ruby performance, we haven't received a whole lot of pull requests improving the performance of the Ruby implementations on our benchmarks project [1]. If you feel Ruby isn't getting a fair shake on performance measurements, we'd love to see some pull request love. [1] http://www.techempower.com/benchmarks/ http://www.techempower.com/benchmarks/
- laureny 13y ago
  That's quite a weird angle. Surely I can express unhappiness about a product's performance without being asked to fix it or to shut up?
  - bhauer 13y ago
    I think we're on the same side here. We've measured the performance of the fundamentals of web applications on two Ruby implementations (MRI, JRuby) and both perform poorly, as compared to the rest of the field. area51org says that Ruby's reputation of slowness is undeserved. I feel our data confirms the reputation. In fact, I don't think there's much room for improvement by tweaking our tests, but I figured I'd make the solicitation anyway to keep an open mind about it. I'm not asking you to fix it or shut up, especially since I feel your point of view is corroborated by the data. I am asking, however, for those who say Ruby's reputation is undeserved to consider providing some evidence for that point of view. And one conceivable way to do that would be to improve our Ruby tests.
- pkroll 13y ago
  I asked about this in another thread that you responded to, and appreciated your answer. (Which had a bunch of links and a strong implication of "well, since you ASKED, here's what you need to go do something about it..." :) ) Given how little code there is in the Ruby/Rails tests there, it doesn't look like a lot of opportunity exists for speeding up the benchmarks by changing that code... but maybe it could be sped up by changing the gems. There are several JSON gems, at least one of which claims to be faster by 2-3x. In the PHP universe there's Phalcon, a C plugin to handle a lot of the work that otherwise would be done in raw PHP. It has good performance versus the other PHP frameworks (not up to the raw PHP numbers). Why hasn't this become the norm? I'm not asking bhauer, folks: why not replace chunks of the code that are slow but have been pretty stable (Rack comes to mind, but other chunks of Rails are probably good contenders) with C plugins/gems? We already commonly use Nginx or another server for static content, why not push that further? Hell, how much similar code could be put to use in other frameworks if the core was done in C/C++ or Java? The focus on the singular language as the only way to do any given framework seems to waste an amazing amount of code, and performance.

LukeShu 13y ago

> and it's not Rails. Yes it is. ActiveSupport (part of Rails) monkey-patches the core library.

area51org 13y ago
It does, but it doesn't heavily rely on this, as the poster was contending. It merely adds some helper methods.

damncabbage 13y ago

That's a myth, a pervasive one. I'll point you to one source that debunks this, but there are many. http://www.unlimitednovelty.com/2012/06/ruby-is-faster-than-python-php-and-perl.html It's unfortunately compromised by some boneheaded things in the MRI implementation. Method caching is a great example: https://charlie.bz/blog/things-that-clear-rubys-method-cache https://charlie.bz/blog/things-that-clear-rubys-method-cache (Rails startup does a lot of the mentioned things, for example, but then so do a lot of apps' controller actions unless they're careful. The OpenStruct example is particular egregious.)

laureny 13y ago

> IMHO Ruby is just now coming fully into its own, and is, for a young language Young? Ruby is 18 years old, it's certainly not a young language.

dragonwriter 13y ago
> Young? Ruby is 18 years old, it's certainly not a young language. Well, its not young compared to Go, but its young compared to C or Lisp or Smalltalk.