[9rx]

> When there are performance issues, 95% of the times they come from the database, not the language.

DHH used to say that it didn't matter if Rails was slow because the database was I/O bound anyway. But that was a long time ago. Times have changed considerably. Most especially because DHH now promotes using SQLite, which completely takes the worst I/O offender right out of the picture. Nowadays the language (when it is as slow as Ruby) is most likely to be the problem.

[jfabre]

Doesn't matter if SQLite is now viable with rails, no legacy rails app is using it and it's not like you're going to wake up one morning and migrate your production db from postgres, mysql, sql server or oracle just because you felt like it.

In theory the language is slow, in practice it doesn't really matter because the db is much slower unless you're github or twitter and you really need to scale.

When you choose ruby, you trade faster dev time for slower runtime. I am OK with this trade-off 99% of the time. My dev time costs way more than a couple ms lost on my production server.

[9rx]

> When you choose ruby, you trade faster dev time for slower runtime.

Ruby is a beautiful language, but that does not translate to efficient use of dev time. Ruby is not a language that you can quickly write usable code in. Some other languages are clearly more productive. You can create works of art, though, which is still pretty appealing. Ruby does have a place in this world.

It was, again, DHH/Rails that used to make the claim about developer time — premised on Rails eliminating all the so-called "situps" that other frameworks imposed on developers. It is very true that when you eliminate a bunch of steps you can move a lot faster. But:

1. Everyone and their bother have created Rails clones in other languages that also eliminate the same "situps", negating any uniqueness Rails once offered on that front.

2. It turns out those "situps", while a dog in early development, actually speed development up down the road. If you are churning out a prototype to demonstrate an idea that will be thrown away after, its a pretty good tradeoff to ignore what you can, but things become far less clear cut when a program finds longevity.

[dmix]

> Nowadays the language (when it is as slow as Ruby) is most likely to be the problem.

These days the main issue why web apps are slow or fragile is because they are huge React apps that do way too much in the browser than they need too. The response time from the server is rarely the issue unless you're doing heavy analytics. High end React shops do some crazy optimization to try to compensate for this fact. Linear is the only one I've seen do it well with JS.

[AdieuToLogic]

>> When there are performance issues, 95% of the times they come from the database, not the language.

> DHH used to say that it didn't matter if Rails was slow because the database was I/O bound anyway. But that was a long time ago. ... Nowadays the language (when it is as slow as Ruby) is most likely to be the problem.

Nowadays CPU speeds, available RAM, and network speeds dwarf what was top-of-the-line "a long time ago," making the trope of "Ruby is too slow" much less believable "nowadays."

[9rx]

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

[AdieuToLogic]

You previously stated:

  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.

[9rx]

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

[vidarh]

Ruby itself has also gotten far faster, even if you stick with MRI, and even faster if you don't.