6 ms·

No, Ruby is slow. Its GC is ungodly slow. And you can’t truly multithread, thus you can’t properly parallelize or maximize concurrency.

joshmn 4y ago
How many developers will really need it though? It's fast enough for Stripe's API, it's fast enough for Shopify; hardware in exchange for productivity is a pretty fair trade.
- likeabbas 4y ago
  Stripe’s API is one of the slowest of any payment processor, and it’s a major source of contention within the company
- favorited 4y ago
  Except most companies won't attract the same top-tier Ruby/Rails talent. For example, it looks like 1/3 of the current Rails Core Team work at Shopify, including the person who is the #1 all-time Rails contributor.
  - JohnBooty 4y ago
    I may be misunderstanding you, but can you elaborate on why you believe you need "top-tier" Ruby/Rails talent to run a performant Rails application? In my experience, you need no more than mid-level talent. You need a certain % of people who are strong at working with databases to ensure good (normalized, indexed, etc) database design. You also need a certain level of organizational will to avoid letting a Rails monolith get absolutely out of control, but this is less "a need for top-level talent" and more "just stick to boring old Ruby/Rails best practices." Those are, of course, things you need when working with any stack. I don't find them to be Ruby/Rails specific.
  - byroot 4y ago
    Rails Core team member working at Shopify here. You seem to be misinterpreting what we’re doing at Shopify. We pretty much never work on the product or anything like that, and we don’t go around the app chasing perf issues either. At best we work on the infra or dev tools to encourage or enforce better patterns, or sometimes in some kind of support capacity for teams having Ruby or Rails specific issues, but Shopify would do fine without us. We’re mostly here to ensure Rails and the Ruby ecosystem Shopify heavily depends on is maintained and healthy. Now maybe you need to tier talent to scale a Rails infra (I don’t think so), but Shopify’s presence in the Rails or Ruby core teams is no indication of that.
- clintonb 4y ago
  > It's fast enough for Stripe's API... Stripe is moving to Java.
  - Mikeb85 4y ago
    Every large enough organisation eventually moves to Java (or C++, or Rust). When you have more bodies than things to do you just optimize... But how did all these startups get so big?
  - JohnBooty 4y ago
    If you need maximum requests per second for sufficiently high volumes of traffic - ie, Stripe/Twitter/FB/whatever stuff - then yeah Ruby/Python/etc doesn't cut it. If your needs get extreme enough (high frequency trading?) then Java doesn't cut it either. Most (I suspect > 99%) use cases don't fit these criteria. I know this is skewed a perception is skewed a little by the HN crowd, where many folks legitimately are trying to build the next Stripe or Twitter, but I think the world of modern software development is somewhat poisoned by this belief that we all need to follow FAANG-scale practices and architectures.
    - kaba0 4y ago
      Java is used in HFT, and for the variant where it is not fast enough, general purpose CPUs are not fast enough so not even hand-written assembly can compete anymore. They use FPGAs for that kind.
      - likeabbas 4y ago
        Java is used in HFT for markets that have a time window, but only because they tune the GC to never kick in during market hours
- drogus 4y ago
  Both Stripe and Shopify have more resources than an average small startup
treeman79 4y ago
Ruby web guy for 15 years. 95% of the time the problem is poor database choices. Usually to much contention / locks. On the rare projects where I need something like rabbitmq performance. I don’t use ruby.
- KptMarchewa 4y ago
  Just use optimistic locking on all the things bro
marginalia_nu 4y ago
It can be argued that if it's mostly a glue language translating requests into db queries and db responses into HTML it doesn't need to be blazingly fast. Although that does rather define the shape of the application to look a certain way. You can certainly do a lot more with a faster backend language. Not everything translates well to a database query. Throwing more hardware at the problem doesn't get around this.
gedy 4y ago
Yeah antidotal, but I was doing some tests of an existing Rails app API compared to Hasura (erlang GraphQL server) talking to same DB, and querying same data was like 100x faster in Hasura..
- knodi123 4y ago
  anecdotal: based on personal experience antidotal: based on curing a deadly poison
  - gedy 4y ago
    Thanks, love what autocorrect comes up with..
- thom 4y ago
  Hasura is Haskell, not Erlang, I thought.
  - gedy 4y ago
    You are correct, my bad
mberning 4y ago
It depends on the workload. You absolutely can parallelize many processes using tools like Sidekiq. My single threaded ruby app might take hours to query data sequentially from an API. But with sidekiq suddenly you have to throttle your concurrent processes because the API is breaking under the stress.
Mikeb85 4y ago
> No, Ruby is slow. Its GC is ungodly slow. Ruby is quicker than Python and that's the most popular programming language there is at the moment. > And you can’t truly multithread, thus you can’t properly parallelize or maximize concurrency You definitely can. You've been able to fork processes for longer than I can remember. Ractors just became a thing, making multithreading cheaper and easier. Ruby's also had multithreaded servers for at least a decade. Not that it even matters that much, most people are using on-demand cloud servers that just spin up more servers when needed, making multi-threading less useful anyway. Even if you forget Ractors exist, it's like saying C can't do multithreading because it's not in the language definition...
- likeabbas 4y ago
  > Ruby is quicker than Python Python is slow as shit too. I would never use either language in a user path production environment. > fork processes Forking a process takes upwards of 50ms vs forking a thread is in microseconds. That might not seem like a lot, but a use will be able to tell the difference between a 50ms page load time and a 150ms page load time. Also, multi processing is not optimal for sharing memory like a local cache. My ultimate point is there’s truly no reason to use these languages when Java, Go, and Rust are around
- BeefWellington 4y ago
  Ruby is quicker than Python and that's the most popular programming language there is at the moment. Do you have any reputable sources for this? All I can find are benchmarks run by companies with clear vested interests in showing one language is faster than the other. Also, this isn't quite the strongest argument for its performance; popularity hasn't been tied to performance for a long time (see: all those years NodeJS was leading language popularity lists, or Java).
  - Mikeb85 4y ago
    https://benchmarksgame-team.pages.debian.net/benchmarksgame/fastest/ruby-python3.html https://benchmarksgame-team.pages.debian.net/benchmarksgame/... Of course, in the real world it doesn't really matter. Both are used in places where performance doesn't really matter as long as they're fast enough. But anyone with experience with both knows they're both slow (well, some Python fanboys try to pretend otherwise).
pdntspa 4y ago
JRuby does not have GIL and offers true multithreading
- thom 4y ago
  I feel bad that I’ve forever tarred JRuby with the atrociously slow performance of ThoughtWorks’ Mingle. If you think Jura’s sluggish…
berkes 4y ago
I deliberately startd my article with a few paragraphs showing that Ruby indeed is very slow. > Let's be clear: ruby is slow. The garbage collector, JIT compiler, its highly dynamic nature, the ability to change the code runtime and so on, all add up to a sluggish language. There's no argument there. The main point, however, is that in many cases (where Ruby is used) this hardly matters, because other stuff than Ruby is the bottleneck. The database being the most obvious culprit.

joshmn 4y ago

How many developers will really need it though? It's fast enough for Stripe's API, it's fast enough for Shopify; hardware in exchange for productivity is a pretty fair trade.

likeabbas 4y ago
Stripe’s API is one of the slowest of any payment processor, and it’s a major source of contention within the company
favorited 4y ago
Except most companies won't attract the same top-tier Ruby/Rails talent. For example, it looks like 1/3 of the current Rails Core Team work at Shopify, including the person who is the #1 all-time Rails contributor.
- JohnBooty 4y ago
  I may be misunderstanding you, but can you elaborate on why you believe you need "top-tier" Ruby/Rails talent to run a performant Rails application? In my experience, you need no more than mid-level talent. You need a certain % of people who are strong at working with databases to ensure good (normalized, indexed, etc) database design. You also need a certain level of organizational will to avoid letting a Rails monolith get absolutely out of control, but this is less "a need for top-level talent" and more "just stick to boring old Ruby/Rails best practices." Those are, of course, things you need when working with any stack. I don't find them to be Ruby/Rails specific.
- byroot 4y ago
  Rails Core team member working at Shopify here. You seem to be misinterpreting what we’re doing at Shopify. We pretty much never work on the product or anything like that, and we don’t go around the app chasing perf issues either. At best we work on the infra or dev tools to encourage or enforce better patterns, or sometimes in some kind of support capacity for teams having Ruby or Rails specific issues, but Shopify would do fine without us. We’re mostly here to ensure Rails and the Ruby ecosystem Shopify heavily depends on is maintained and healthy. Now maybe you need to tier talent to scale a Rails infra (I don’t think so), but Shopify’s presence in the Rails or Ruby core teams is no indication of that.
clintonb 4y ago
> It's fast enough for Stripe's API... Stripe is moving to Java.
- Mikeb85 4y ago
  Every large enough organisation eventually moves to Java (or C++, or Rust). When you have more bodies than things to do you just optimize... But how did all these startups get so big?
- JohnBooty 4y ago
  If you need maximum requests per second for sufficiently high volumes of traffic - ie, Stripe/Twitter/FB/whatever stuff - then yeah Ruby/Python/etc doesn't cut it. If your needs get extreme enough (high frequency trading?) then Java doesn't cut it either. Most (I suspect > 99%) use cases don't fit these criteria. I know this is skewed a perception is skewed a little by the HN crowd, where many folks legitimately are trying to build the next Stripe or Twitter, but I think the world of modern software development is somewhat poisoned by this belief that we all need to follow FAANG-scale practices and architectures.
  - kaba0 4y ago
    Java is used in HFT, and for the variant where it is not fast enough, general purpose CPUs are not fast enough so not even hand-written assembly can compete anymore. They use FPGAs for that kind.
    - likeabbas 4y ago
      Java is used in HFT for markets that have a time window, but only because they tune the GC to never kick in during market hours
drogus 4y ago
Both Stripe and Shopify have more resources than an average small startup

treeman79 4y ago

Ruby web guy for 15 years. 95% of the time the problem is poor database choices. Usually to much contention / locks. On the rare projects where I need something like rabbitmq performance. I don’t use ruby.

KptMarchewa 4y ago
Just use optimistic locking on all the things bro

marginalia_nu 4y ago

It can be argued that if it's mostly a glue language translating requests into db queries and db responses into HTML it doesn't need to be blazingly fast. Although that does rather define the shape of the application to look a certain way. You can certainly do a lot more with a faster backend language. Not everything translates well to a database query. Throwing more hardware at the problem doesn't get around this.

gedy 4y ago

Yeah antidotal, but I was doing some tests of an existing Rails app API compared to Hasura (erlang GraphQL server) talking to same DB, and querying same data was like 100x faster in Hasura..

knodi123 4y ago
anecdotal: based on personal experience antidotal: based on curing a deadly poison
- gedy 4y ago
  Thanks, love what autocorrect comes up with..
thom 4y ago
Hasura is Haskell, not Erlang, I thought.
- gedy 4y ago
  You are correct, my bad

mberning 4y ago

It depends on the workload. You absolutely can parallelize many processes using tools like Sidekiq. My single threaded ruby app might take hours to query data sequentially from an API. But with sidekiq suddenly you have to throttle your concurrent processes because the API is breaking under the stress.

Mikeb85 4y ago

> No, Ruby is slow. Its GC is ungodly slow. Ruby is quicker than Python and that's the most popular programming language there is at the moment. > And you can’t truly multithread, thus you can’t properly parallelize or maximize concurrency You definitely can. You've been able to fork processes for longer than I can remember. Ractors just became a thing, making multithreading cheaper and easier. Ruby's also had multithreaded servers for at least a decade. Not that it even matters that much, most people are using on-demand cloud servers that just spin up more servers when needed, making multi-threading less useful anyway. Even if you forget Ractors exist, it's like saying C can't do multithreading because it's not in the language definition...

likeabbas 4y ago
> Ruby is quicker than Python Python is slow as shit too. I would never use either language in a user path production environment. > fork processes Forking a process takes upwards of 50ms vs forking a thread is in microseconds. That might not seem like a lot, but a use will be able to tell the difference between a 50ms page load time and a 150ms page load time. Also, multi processing is not optimal for sharing memory like a local cache. My ultimate point is there’s truly no reason to use these languages when Java, Go, and Rust are around
BeefWellington 4y ago
Ruby is quicker than Python and that's the most popular programming language there is at the moment. Do you have any reputable sources for this? All I can find are benchmarks run by companies with clear vested interests in showing one language is faster than the other. Also, this isn't quite the strongest argument for its performance; popularity hasn't been tied to performance for a long time (see: all those years NodeJS was leading language popularity lists, or Java).
- Mikeb85 4y ago
  https://benchmarksgame-team.pages.debian.net/benchmarksgame/fastest/ruby-python3.html https://benchmarksgame-team.pages.debian.net/benchmarksgame/... Of course, in the real world it doesn't really matter. Both are used in places where performance doesn't really matter as long as they're fast enough. But anyone with experience with both knows they're both slow (well, some Python fanboys try to pretend otherwise).

pdntspa 4y ago

JRuby does not have GIL and offers true multithreading

thom 4y ago
I feel bad that I’ve forever tarred JRuby with the atrociously slow performance of ThoughtWorks’ Mingle. If you think Jura’s sluggish…

berkes 4y ago

I deliberately startd my article with a few paragraphs showing that Ruby indeed is very slow. > Let's be clear: ruby is slow. The garbage collector, JIT compiler, its highly dynamic nature, the ability to change the code runtime and so on, all add up to a sluggish language. There's no argument there. The main point, however, is that in many cases (where Ruby is used) this hardly matters, because other stuff than Ruby is the bottleneck. The database being the most obvious culprit.