5 ms·

I couldn't agree more. There is also a technology aspect to it. Rails is objectively veeeeeery slow. Concurrency support is nonexistent. This is not a good fit

by jupp0r 3y ago

I couldn't agree more. There is also a technology aspect to it. Rails is objectively veeeeeery slow. Concurrency support is nonexistent. This is not a good fit for all problems. It also to some degree prevents you from breaking out the parts that would benefit from a different language into their own services (Rails needs to call them, but it's really not good at IO).

claudiug 3y ago
compare with what, in what load?
- jupp0r 3y ago
  From my day job: Stateless API gateway making HTTP calls to other services, which have response times in seconds for various reasons. Rails throughput ~20 requests per second. Golang rewrite throughput: 200k requests per second. Same hardware.
  - jakswa 3y ago
    I helped write what might be a similar API gateway prototype in rails (made a DB query and decorated downstream requests with auth/role/etc headers). You might have threadpool/process/concurrency tuning to do. Even then, I don't think rails is a good solution for what is essentially an HTTP proxy, and I would've pushed for a different tool if time wasn't an issue. Rails was fast to build, I'll give it that. We ended up getting downstream service to $1M ARR so rails wins out against my "let me write it in XYZ language/framework" again somehow.
    - jupp0r 3y ago
      This is the point I wanted to make. Rails is great for some problems, not great at others. I can tell you for example that it's not great at transforming 2MB of JSON into a differently structured 2MB of JSON.
DoesntMatter22 3y ago
Is there a comparable framework that does what Rails does but is somehow 10x faster? I wouldn't use Rails for everything but the fact that plenty of companies like Shopify are serving millions of requests per second with it shows that it's probably acceptably fast for mega scale apps.
- claudiug 3y ago
  and gitlab, github :)
  - jupp0r 3y ago
    These two have lots of backend code that's not Ruby. Rails is great at what it does and it's not optimal for many other use cases.
    - AlchemistCamp 3y ago
      I'm sure things have changed post-acquisition, but for a very long time Github's back-end languages were just Ruby and C.
      - jupp0r 3y ago
        Turns out C is better at some problems than Ruby after all? This was my point.
        AlchemistCamp 3y ago
        Agreed on that. My point was just that even at massive scale, the vast majority of the backend was written in Ruby.
- jupp0r 3y ago
  Rails does everything. You can build a stateless API gateway with it. Is it great for that particular use case? No. Your question about frameworks with similar capabilities is pointless because my point was that there are use cases where the capabilities of Rails are not a good fit.
ericb 3y ago
What in the world are you talking about? This reads like someone who doesn't understand how to use a tool so they think it is broken. I've worked on Rails apps that outperformed Spring/Java apps routinely and node apps routinely at very large scale. You're very rarely bottlenecked on CPU in a modern CRUD app, much more often, it is the database. It sounds naive to call the framework that runs github, that almost everyone in the world pushes their code to "veeeeery slow" and I don't know what you mean by "bad at io" in any context where that is a problem for Rails.
- berkes 3y ago
  It's possible to make Rails relatively fast. But Ruby is one of the slowest languages around. And Rails adds a lot of runtime overhead to that. It really is very slow out of the box. And that matters for virtually no-one¹, because almost no-one is running their rails app at that scale. That something would outperform Spring is really due to technical choices, the stack, suboptimal use or libraries. Because Java is undeniably multitudes faster than Rails; in everything. ¹ This used to be my strongly held opinion. But I'm shifting around since we're in a the middle of an unprecedented energy/climate crisis and a slow rails app is gobbling up electricity much more than a highly tuned one. Or the same service rewritten in Go or Rust or Java will.

by jupp0r 3y ago

claudiug 3y ago

compare with what, in what load?

jupp0r 3y ago
From my day job: Stateless API gateway making HTTP calls to other services, which have response times in seconds for various reasons. Rails throughput ~20 requests per second. Golang rewrite throughput: 200k requests per second. Same hardware.
- jakswa 3y ago
  I helped write what might be a similar API gateway prototype in rails (made a DB query and decorated downstream requests with auth/role/etc headers). You might have threadpool/process/concurrency tuning to do. Even then, I don't think rails is a good solution for what is essentially an HTTP proxy, and I would've pushed for a different tool if time wasn't an issue. Rails was fast to build, I'll give it that. We ended up getting downstream service to $1M ARR so rails wins out against my "let me write it in XYZ language/framework" again somehow.
  - jupp0r 3y ago
    This is the point I wanted to make. Rails is great for some problems, not great at others. I can tell you for example that it's not great at transforming 2MB of JSON into a differently structured 2MB of JSON.

DoesntMatter22 3y ago

Is there a comparable framework that does what Rails does but is somehow 10x faster? I wouldn't use Rails for everything but the fact that plenty of companies like Shopify are serving millions of requests per second with it shows that it's probably acceptably fast for mega scale apps.

claudiug 3y ago
and gitlab, github :)
- jupp0r 3y ago
  These two have lots of backend code that's not Ruby. Rails is great at what it does and it's not optimal for many other use cases.
  - AlchemistCamp 3y ago
    I'm sure things have changed post-acquisition, but for a very long time Github's back-end languages were just Ruby and C.
    - jupp0r 3y ago
      Turns out C is better at some problems than Ruby after all? This was my point.
      - AlchemistCamp 3y ago
        Agreed on that. My point was just that even at massive scale, the vast majority of the backend was written in Ruby.
jupp0r 3y ago
Rails does everything. You can build a stateless API gateway with it. Is it great for that particular use case? No. Your question about frameworks with similar capabilities is pointless because my point was that there are use cases where the capabilities of Rails are not a good fit.

ericb 3y ago

What in the world are you talking about? This reads like someone who doesn't understand how to use a tool so they think it is broken. I've worked on Rails apps that outperformed Spring/Java apps routinely and node apps routinely at very large scale. You're very rarely bottlenecked on CPU in a modern CRUD app, much more often, it is the database. It sounds naive to call the framework that runs github, that almost everyone in the world pushes their code to "veeeeery slow" and I don't know what you mean by "bad at io" in any context where that is a problem for Rails.

berkes 3y ago
It's possible to make Rails relatively fast. But Ruby is one of the slowest languages around. And Rails adds a lot of runtime overhead to that. It really is very slow out of the box. And that matters for virtually no-one¹, because almost no-one is running their rails app at that scale. That something would outperform Spring is really due to technical choices, the stack, suboptimal use or libraries. Because Java is undeniably multitudes faster than Rails; in everything. ¹ This used to be my strongly held opinion. But I'm shifting around since we're in a the middle of an unprecedented energy/climate crisis and a slow rails app is gobbling up electricity much more than a highly tuned one. Or the same service rewritten in Go or Rust or Java will.