9 ms·

Step 1: Step away from Ruby. I loove ruby, it's my first choice for scripting wherever performance doesn't matter. No way around the fact that it very slow tho

by jjav 7y ago

Step 1: Step away from Ruby. I loove ruby, it's my first choice for scripting wherever performance doesn't matter. No way around the fact that it very slow though.

pmontra 7y ago
Performance matters rarely in my experience. There is a world of low load services out there, with servers sitting idle most of the time waiting for requests. And that's not the case of Shopify which is doing well with Ruby anyway.
- danmaz74 7y ago
  Performance matters in web applications, but that is almost never determined by the speed of execution of the web framework programming language. The performance bottlenecks are almost always in the database and/or the architecture. It's also very easy to scale horizontally the execution of the web code. That's why, for most web software, programmer productivity is more important than raw language performance
  - enraged_camel 7y ago
    Horizontal scalability is not always easy, but it is always expensive. Startups especially tend to discover the latter the hard way when they receive surprise bills from AWS.
    - danmaz74 7y ago
      Scaling horizontally a Rails application where the bottleneck is the Ruby code is always very easy - just add more instances working on the same DB. It is usually more difficult because the bottleneck is in the DB, not the Ruby code. You're right about price though; if the cost of compute is relevant in your business model - which, again, usually isn't the case - then doing that computation with Ruby on AWS isn't the best choice.
    - maitredusoi 7y ago
      > surprise bills from AWS Surprise bills from AWS means it is time for refactoring ( and thus optimization time ;)
pcmoney 7y ago
Is ruby that slow? I always understood it was comparable to python? Plus if it is performant enough for Shopify and Github it seems like it would be performant for 90%+ of use cases? The speed of development and the flexibility of development is much greater than most stacks once you add rails.
- Mikeb85 7y ago
  It is comparable to Python. Which is very slow.
- jonny383 7y ago
  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?
deleted 7y ago
[deleted]
jonny383 7y ago
Couldn't agree more. "fast code" and Ruby are mutually exclusive.
jashmatthews 7y ago
> No way around the fact that it very slow though. You can run Sinatra on TruffleRuby today and it's very competitive with e.g. Go web frameworks. It's not quite production ready but has commercial support from Shopify (Chris Seaton) and Oracle Labs. It will get there soon. There's also no reason I know of that you couldn't build a simple optimizing JIT for CRuby like LuaJIT. I'm trying a proof of concept at the moment.
mjfisher 7y ago
Speaking as someone who uses Rails regularly, I agree - it is considerably slower than many other language choices. It probably isn't a good call for a performance critical bottlenecked service that can't scale horizontally. For everything else, it's great, and it's almost always a good default to choose speed of development and engineer productivity over runtime performance.
- krn 7y ago
  > For everything else, it's great, and it's almost always a good default to choose speed of development and engineer productivity over runtime performance. Doesn't Elixir on Phoenix[1] provide the elegance of Ruby on Rails without its drawbacks? [1] https://phoenixframework.org/ https://phoenixframework.org/
  - mercer 7y ago
    I'm pretty much all in on Phoenix, but I suppose a good reason to stick with RoR would be that 1) it's easier to find (experienced) devs, and 2) there are (still?) many more packages available which can make quick development easier.
    - kweinber 7y ago
      Our research has indicated that Elixir has basically stopped growing in the general market.... really only getting any growth from converted erlang devs. Have you seen anything different? Most enthusiastic vendors I’ve talked to have moved away from elixir due to low adoption and demand. Tiobe, google trends, etc tell the same story. I’d love to find evidence to the contrary but the low numbers of elixir devs seems to be both a supply AND demand problem... ie lack of traction and interest.
      - Aduket 7y ago
        What research? Can you write a blog post about this please?
      - 7y ago
pjmlp 7y ago
TruffleRuby and RubyMotion prove otherwise. But yeah, we keep mixing implementations with languages.

by jjav 7y ago

Step 1: Step away from Ruby. I loove ruby, it's my first choice for scripting wherever performance doesn't matter. No way around the fact that it very slow though.

pmontra 7y ago

Performance matters rarely in my experience. There is a world of low load services out there, with servers sitting idle most of the time waiting for requests. And that's not the case of Shopify which is doing well with Ruby anyway.

danmaz74 7y ago
Performance matters in web applications, but that is almost never determined by the speed of execution of the web framework programming language. The performance bottlenecks are almost always in the database and/or the architecture. It's also very easy to scale horizontally the execution of the web code. That's why, for most web software, programmer productivity is more important than raw language performance
- enraged_camel 7y ago
  Horizontal scalability is not always easy, but it is always expensive. Startups especially tend to discover the latter the hard way when they receive surprise bills from AWS.
  - danmaz74 7y ago
    Scaling horizontally a Rails application where the bottleneck is the Ruby code is always very easy - just add more instances working on the same DB. It is usually more difficult because the bottleneck is in the DB, not the Ruby code. You're right about price though; if the cost of compute is relevant in your business model - which, again, usually isn't the case - then doing that computation with Ruby on AWS isn't the best choice.
  - maitredusoi 7y ago
    > surprise bills from AWS Surprise bills from AWS means it is time for refactoring ( and thus optimization time ;)

pcmoney 7y ago

Is ruby that slow? I always understood it was comparable to python? Plus if it is performant enough for Shopify and Github it seems like it would be performant for 90%+ of use cases? The speed of development and the flexibility of development is much greater than most stacks once you add rails.

Mikeb85 7y ago
It is comparable to Python. Which is very slow.
jonny383 7y ago
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?

deleted 7y ago

[deleted]

jonny383 7y ago

Couldn't agree more. "fast code" and Ruby are mutually exclusive.

jashmatthews 7y ago

> No way around the fact that it very slow though. You can run Sinatra on TruffleRuby today and it's very competitive with e.g. Go web frameworks. It's not quite production ready but has commercial support from Shopify (Chris Seaton) and Oracle Labs. It will get there soon. There's also no reason I know of that you couldn't build a simple optimizing JIT for CRuby like LuaJIT. I'm trying a proof of concept at the moment.

mjfisher 7y ago

Speaking as someone who uses Rails regularly, I agree - it is considerably slower than many other language choices. It probably isn't a good call for a performance critical bottlenecked service that can't scale horizontally. For everything else, it's great, and it's almost always a good default to choose speed of development and engineer productivity over runtime performance.

krn 7y ago
> For everything else, it's great, and it's almost always a good default to choose speed of development and engineer productivity over runtime performance. Doesn't Elixir on Phoenix[1] provide the elegance of Ruby on Rails without its drawbacks? [1] https://phoenixframework.org/ https://phoenixframework.org/
- mercer 7y ago
  I'm pretty much all in on Phoenix, but I suppose a good reason to stick with RoR would be that 1) it's easier to find (experienced) devs, and 2) there are (still?) many more packages available which can make quick development easier.
  - kweinber 7y ago
    Our research has indicated that Elixir has basically stopped growing in the general market.... really only getting any growth from converted erlang devs. Have you seen anything different? Most enthusiastic vendors I’ve talked to have moved away from elixir due to low adoption and demand. Tiobe, google trends, etc tell the same story. I’d love to find evidence to the contrary but the low numbers of elixir devs seems to be both a supply AND demand problem... ie lack of traction and interest.
    - Aduket 7y ago
      What research? Can you write a blog post about this please?
    - 7y ago

pjmlp 7y ago

TruffleRuby and RubyMotion prove otherwise. But yeah, we keep mixing implementations with languages.