"Too slow" is a mischaracterization. Ruby was never too slow, only comparatively slow. What DHH was talking about is that when the system was I/O bound, even if you could eliminate all the time spent in Ruby, you'd only see small percentage increases in performance at best. But the calculus has changed. I/O isn't the bottleneck like it was when those statements were made. Now, if you could eliminate the time spent in Ruby, you'd see significant percentage increases in performance.
Nowadays the language (when it is as slow as Ruby)
is most likely to be the problem.
And now state:
"Too slow" is a mischaracterization. Ruby was never
too slow, only comparatively slow.
In response to my identifying the "Ruby is too slow" trope. Furthermore, when you assert:
Now, if you could eliminate the time spent in Ruby,
you'd see significant percentage increases in performance.
This implies a performance issue within Ruby when, in fact, the narrative has now been shifted into execution percentage allocations. For example, if an overall execution flow takes 1 millisecond and time within the Ruby runtime accounts for 600 microseconds, then the above would be true.
One way to describe your position is disingenuous.
> This implies a performance issue within Ruby when, in fact, the narrative has now been shifted into execution percentage allocations.
Yes, that's right. If you have performance problems then Ruby taking up the large majority percentage of the execution allocation means that Ruby is the problem.
But your incorrect assumption is that you will have performance problems in the first place. Neither Ruby nor databases are that slow.
You must have done that stupid HN thing where you pick random strings of words and try to derive meaning from them without taking in the entire context that surround those words into account?
