4 ms·

If ruby was performant enough for Shopify, this article would not have been written.

jrochkind1 7y ago
Hm, a lot of the article focuses on optimizing your interaction with a database (rdbms/sql), which has nothing to do with the performance of ruby (some of it arguably has to do with _Rails_). Even more of the article has to do with Rails, and not ruby in general. But the larger point, are you suggesting that in a language that is "performant enough", developers need no performance advice, they can write however they want and get adequate performance, for any performance needs? Maybe, although I'm dubious. The existence of advice for programming does not mean a language/platform isn't "something enough" until we have AI writing code. At any rate, if such a language exists it is not ruby. But I disagree with that suggestion. The existence of optimization advice does not mean that a language "is not performant enough". If Shoppify is still happily using ruby/rails, I would say it indeed demonstrates they are performant enough for them.
- jonny383 7y ago
  Nope I'm not. But Shopify is large enough to have a first-class engineering team that would (presumably) be writing efficient code, which is nothing special. So if this first-class engineering team is still writing about _fast code in Ruby_, doesn't that imply Ruby isn't fast?
  - jrochkind1 7y ago
    Shopify's engineering team is obviously writing code congruent with the advice they give here, that's why they give the advice! I'm not following you at all.
dbattaglia 7y ago
I don’t know, I think most of the high level points made in the article (caching, know your SQL/ORM, memory management and algorithm complexity) apply to almost any web application and framework once you hit some level of scale.
Lio 7y ago
This is an article about the Ruby on Rails framework not the ruby language. Most of the discussion is about SQL and query optimisation. Also describing common performance pitfalls does not imply that something is or isn’t “performant enough”. Only that you can make mistakes that will affect performance. That, I’m afraid, is true for every language or framework.

Hm, a lot of the article focuses on optimizing your interaction with a database (rdbms/sql), which has nothing to do with the performance of ruby (some of it arguably has to do with _Rails_). Even more of the article has to do with Rails, and not ruby in general. But the larger point, are you suggesting that in a language that is "performant enough", developers need no performance advice, they can write however they want and get adequate performance, for any performance needs? Maybe, although I'm dubious. The existence of advice for programming does not mean a language/platform isn't "something enough" until we have AI writing code. At any rate, if such a language exists it is not ruby. But I disagree with that suggestion. The existence of optimization advice does not mean that a language "is not performant enough". If Shoppify is still happily using ruby/rails, I would say it indeed demonstrates they are performant enough for them.

jonny383 7y ago
Nope I'm not. But Shopify is large enough to have a first-class engineering team that would (presumably) be writing efficient code, which is nothing special. So if this first-class engineering team is still writing about _fast code in Ruby_, doesn't that imply Ruby isn't fast?
- jrochkind1 7y ago
  Shopify's engineering team is obviously writing code congruent with the advice they give here, that's why they give the advice! I'm not following you at all.

dbattaglia 7y ago

I don’t know, I think most of the high level points made in the article (caching, know your SQL/ORM, memory management and algorithm complexity) apply to almost any web application and framework once you hit some level of scale.

Lio 7y ago

This is an article about the Ruby on Rails framework not the ruby language. Most of the discussion is about SQL and query optimisation. Also describing common performance pitfalls does not imply that something is or isn’t “performant enough”. Only that you can make mistakes that will affect performance. That, I’m afraid, is true for every language or framework.