4 ms·

Ruby trades away quite a few things for readability. It's beautiful but a lot is being hidden. Some of those languages would have you deal with the problem of

by dlisboa 11mo ago

Ruby trades away quite a few things for readability. It's beautiful but a lot is being hidden. Some of those languages would have you deal with the problem of allocating multiple arrays in the heap just to compare three numbers. Or give you tools to outlaw passing invalid strings to AppVersion.new (quick: what is the comparison between AppVersions "foo" and "bar"?). Plus you have very few tools to ensure code remains beautiful. I've worked with Ruby for close to two decades, almost nothing in the real world looks that clean. Take a look at the Gem::Version#<=> implementation that the article talks about: https://github.com/ruby/ruby/blob/master/lib/rubygems/version.rb#L360-L406 https://github.com/ruby/ruby/blob/master/lib/rubygems/versio...

jimbokun 11mo ago
Wow I wonder why it's so verbose. Performance optimizations? Seems like this wouldn't be called often enough to show up in any performance profiling exercise.
- dlisboa 11mo ago
  Ruby is very slow so you gotta squeeze everything you can everywhere. Even a seemingly simple method will have to be scrutinized so that overall performance isn't impacted. It's death by a thousand cuts. See the commit that made it complex: https://github.com/ruby/ruby/commit/9b49ba5a68486e42afd83db49a48edf2bfc00105 https://github.com/ruby/ruby/commit/9b49ba5a68486e42afd83db4... It claims 20-50% speedups in some cases. There's churn that comes with that. Ruby will have code that is ever changing to gain 5%, 10% performance every now and then. You gotta put that on balance: in a language like Go this method would've been ugly from the start but no one would've needed to touch it in 100 years.
  - jfabre 11mo ago
    There are plenty of businesses that have under 10k users and can live perfectly well with http requests around 500-1000 ms. When there are performance issues, 95% of the times they come from the database, not the language.
    - dlisboa 11mo ago
      I somewhat agree. In general most apps are small where the language choice doesn’t really matter. Caching is also vastly underutilized, most apps are read-heavy and could serve a significant portion of their requests from some form of caching. > When there are performance issues, 95% of the times they come from the database, not the language. Eh, statements like these are always too hand wavy. Resource usage has to do with performance, the DB has no fault in it but the runtime does. Having worked with Rails a ton there’s a very large overhead. Most apps would see a significant speed up if rewritten in a faster language and framework, with no changes to the DB whatsoever. The amount of memory and CPU expended to the app servers is always significant, often outweighing the DB.
      - deleted 11mo ago
        [deleted]
      - jfabre 11mo ago
        But what do you mean, give me a real example. You loaded too many active_records in memory and it's using a ton of ram? Did you try pluck, batches or even skipping active_record and using a raw query? Unless you really need to scale for a ton of users, you don't have to go crazy to get decent performances out of rails/ruby. How many requests/sec are we even talking about here?
    - 9rx 11mo ago
      > 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 11mo ago
        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.
  - BurningFrog 11mo ago
    You never gotta squeeze everything you can everywhere! Regardless of how slow the language is, the 90/10 rule applies: 90% of the time is spent in 10% of the code. Optimize that 10%! Making the rest of the code faster isn't worth the code quality cost.
    - ben-schaaf 11mo ago
      That's a rule that might hold for applications and services. It does not hold for languages and libraries, where any and every aspect is going to be the bottleneck in someone else's code. It's a different 10% for each user.
    - nikanj 11mo ago
      You can’t build a Ford Pinto and then swap the piston heads and rear differential to get a Formula 1 car.
  - deleted 11mo ago
    [deleted]
  - jbverschoor 11mo ago
    lol.. yet we have no problems running webviews on chromes on electron on VMs on later. You can use Crystal which is faster that Go
- deleted 11mo ago
  [deleted]

by dlisboa 11mo ago

jimbokun 11mo ago

Wow I wonder why it's so verbose. Performance optimizations? Seems like this wouldn't be called often enough to show up in any performance profiling exercise.

dlisboa 11mo ago
Ruby is very slow so you gotta squeeze everything you can everywhere. Even a seemingly simple method will have to be scrutinized so that overall performance isn't impacted. It's death by a thousand cuts. See the commit that made it complex: https://github.com/ruby/ruby/commit/9b49ba5a68486e42afd83db49a48edf2bfc00105 https://github.com/ruby/ruby/commit/9b49ba5a68486e42afd83db4... It claims 20-50% speedups in some cases. There's churn that comes with that. Ruby will have code that is ever changing to gain 5%, 10% performance every now and then. You gotta put that on balance: in a language like Go this method would've been ugly from the start but no one would've needed to touch it in 100 years.
- jfabre 11mo ago
  There are plenty of businesses that have under 10k users and can live perfectly well with http requests around 500-1000 ms. When there are performance issues, 95% of the times they come from the database, not the language.
  - dlisboa 11mo ago
    I somewhat agree. In general most apps are small where the language choice doesn’t really matter. Caching is also vastly underutilized, most apps are read-heavy and could serve a significant portion of their requests from some form of caching. > When there are performance issues, 95% of the times they come from the database, not the language. Eh, statements like these are always too hand wavy. Resource usage has to do with performance, the DB has no fault in it but the runtime does. Having worked with Rails a ton there’s a very large overhead. Most apps would see a significant speed up if rewritten in a faster language and framework, with no changes to the DB whatsoever. The amount of memory and CPU expended to the app servers is always significant, often outweighing the DB.
    - deleted 11mo ago
      [deleted]
    - jfabre 11mo ago
      But what do you mean, give me a real example. You loaded too many active_records in memory and it's using a ton of ram? Did you try pluck, batches or even skipping active_record and using a raw query? Unless you really need to scale for a ton of users, you don't have to go crazy to get decent performances out of rails/ruby. How many requests/sec are we even talking about here?
  - 9rx 11mo ago
    > 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 11mo ago
      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.
- BurningFrog 11mo ago
  You never gotta squeeze everything you can everywhere! Regardless of how slow the language is, the 90/10 rule applies: 90% of the time is spent in 10% of the code. Optimize that 10%! Making the rest of the code faster isn't worth the code quality cost.
  - ben-schaaf 11mo ago
    That's a rule that might hold for applications and services. It does not hold for languages and libraries, where any and every aspect is going to be the bottleneck in someone else's code. It's a different 10% for each user.
  - nikanj 11mo ago
    You can’t build a Ford Pinto and then swap the piston heads and rear differential to get a Formula 1 car.
- deleted 11mo ago
  [deleted]
- jbverschoor 11mo ago
  lol.. yet we have no problems running webviews on chromes on electron on VMs on later. You can use Crystal which is faster that Go
deleted 11mo ago
[deleted]