I don't know if it's the lack of types, the fact that you see streams of "end end end" like Pascal used to do, the abysmal performance of the default VM or just the heavy reliance on monkey patching, but Ruby is not aging very well.
I don't know if it's the lack of types, the fact that you see streams of "end end end" like Pascal used to do, the abysmal performance of the default VM or just the heavy reliance on monkey patching, but Ruby is not aging very well.
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-...
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.
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.
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.
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(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.)
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.
Yes it is. ActiveSupport (part of Rails) monkey-patches the core library.