Hacker News Reader

Comment by area51org | Hacker News Reader

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-...

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.

View on HN

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

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/

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?

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.

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.

  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.)

> 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.

> 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.

> and it's not Rails.

Yes it is. ActiveSupport (part of Rails) monkey-patches the core library.

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

Reply on news.ycombinator.com