4 ms·

I used to work with Ruby and Rails and I really found Ruby to be a very comfortable, terse, and expressive language, but I found it very slow after trying some

I used to work with Ruby and Rails and I really found Ruby to be a very comfortable, terse, and expressive language, but I found it very slow after trying some compiled languages (I think I compared service startup and some simple computationally heavy stuff like Advent of Code or Project Euler solutions) and I just couldn’t go back to Ruby after that. Also I found the Rails (framework) stacktraces and source code very hard to follow. However, that was quite some time ago. Does anyone have any more recent opinions? How is it to work on a large modern Ruby or Rails codebase? Also, I saw some type annotations examples a few years back and thought they looked pretty ugly - is that how I would feel after some months using them, too?

culi 3y ago
> Also, I saw some type annotations examples a few years back You probably saw the third party tool Sorbet. I agree it's ugly and extremely limited. Ruby's native typing solution, RBS, is written in a separate file. It's a bit better but... it's written in a separate file... Most major companies seem to still primarily rely on Sorbet. Yeah I'd say the typing scene in Ruby is still one of it's greatest limitations
jweir 3y ago
Since Ruby 3 I would recommend trying again. It is much faster now. Back in the Ruby 2 days we had tools like Zeus to preload our development application because loading was so slow (10-20 seconds). These days we just load the whole app (2 seconds) These benchmarks show a 2x speed up. While I haven't see that, I have seen at least a 50% increase in performance for our applications.
ecshafer 3y ago
I work at Shopify (not the team that does YJIT) so I am working on a very large, modern Rails codebase. (my opinions are my own) I think rails code is the easiest code to follow in any code base that I have ever worked on. The enforcement in the framework of the code structure, models containing the object and schema relationships, focus on message passing, skinny controllers. Its very very easy to debug rails code and work in code that is relatively foreign due to the consistency across the code base. Some of this might be discipline at Shopify, I do think we have a very good code review culture. But I have been places that rest controllers just led to a spaghetti of "Operations" and "Processors" that just change state everywhere and a bunch of microservice network calls. Ruby speed hasn't been an issue. We focus on latency and speed quite a bit and work on keeping request times low. The speed of ruby running is a good trade off for the speed of development I think. And most slow running requests really seem to end up due to network io or database calls that I see. Sorbet uses a kind of type annotation, its very ugly and I do not like it. I really would prefer something more built into the language. Like def foo(Integer x) -> Integer. The big issue is method arguments I think since Ruby already uses :x, x:, x =, and a lot of the other symbols that indicate types so its hard to add it in an optional fashion.
- graypegg 3y ago
  Just curious, what's your opinion on YARD comments for typing? I have a little more experience with that, than I do Sorbet (or RBS as well) and I found it to be at least tolerable. Though something like your `-> Integer` would be amazing though if there was somehow a way to make it work with the syntax of Ruby.
  - ecshafer 3y ago
    The RBS syntax I like, I don't like how its a separate file though. I haven't used YARD but I think it would have similar issues to Sorbet. I much prefer things to be inline in programming languages in general. YARD looking at it, makes me think of Javadoc, which I always saw the issue with it being that it drifted from implementation over time as people don't update it. Sorbet does enforce it to be updated, and will throw an exception so your build will fail. Does YARD do that?
why-el 3y ago
In my experience most Ruby apps (Rails in particular) develop this idea that Ruby is the bottleneck when in reality most of the time it's something else entirely (mostly DB or network IO). Of course you found compiled languages faster! that's by definition. You also tried Ruby on CPU sensitive code bases ("Advent of Code or Project Euler solutions"), that's textbook "ruby is slower than C". Rails pays dividends in the web and in large code bases with many engineers.
- byroot 3y ago
  Weird, because if anything I keep hearing people say Ruby performance and GVL don't matter because it's all IO anyway. Which is true to a certain extent only. When you first start optimizing a Rails app, it's true that bad queries and N+1 is where most time is wasted, but from my experience once you clear these out, the IO/CPU ratio really isn't that high, generally in the 40-60% IOs range.
  - why-el 3y ago
    I didn't mean to say it's all IO, that would be wrong. Rails is feature-rich, ActiveRecord for instance spends plenty of time in the CPU (manipulating its internal state). But the idea that Rails/Ruby is slow is outdated and does not jive with any monitoring and metrics we collected even in extremely busy environments. Of course one would gain some percentage of speed if say your backend is some compiled language, but that would mean possibly slower development cycles, hiring, and so on. Billion dollar companies run Rails, and, crucially, show relentless speed in execution (for instance, Stripe). If anything, Rails has the strongest case yet for performance / feature set.
dcchambers 3y ago
Obviously as an interpreted language, it's never going to be as fast as something like C, Rust, or Go. Traditionally the ruby maintainers have not designed or optimized for pure speed, but that is changing, and the language is definitely faster these days compared to a decade ago. If you like the ruby syntax/language but want the speed of a compiled language, it's also worth checking out Crystal[^1]. It's mostly ruby-like in syntax, style, and developer ergonomics.[^2] Although it's an entirely different language. Also a tiny community. [1]: https://crystal-lang.org/ https://crystal-lang.org/ [2]: https://crystal-lang.org/reference/1.10/crystal_for_rubyists/index.html https://crystal-lang.org/reference/1.10/crystal_for_rubyists...
- Lio 3y ago
  > Obviously as an interpreted language Isn't the point of YJIT that it's a ruby compiler.
jbverschoor 3y ago
Try Crystal if that's a concern https://crystal-lang.org/ https://crystal-lang.org/

culi 3y ago

> Also, I saw some type annotations examples a few years back You probably saw the third party tool Sorbet. I agree it's ugly and extremely limited. Ruby's native typing solution, RBS, is written in a separate file. It's a bit better but... it's written in a separate file... Most major companies seem to still primarily rely on Sorbet. Yeah I'd say the typing scene in Ruby is still one of it's greatest limitations

jweir 3y ago

Since Ruby 3 I would recommend trying again. It is much faster now. Back in the Ruby 2 days we had tools like Zeus to preload our development application because loading was so slow (10-20 seconds). These days we just load the whole app (2 seconds) These benchmarks show a 2x speed up. While I haven't see that, I have seen at least a 50% increase in performance for our applications.

ecshafer 3y ago

I work at Shopify (not the team that does YJIT) so I am working on a very large, modern Rails codebase. (my opinions are my own) I think rails code is the easiest code to follow in any code base that I have ever worked on. The enforcement in the framework of the code structure, models containing the object and schema relationships, focus on message passing, skinny controllers. Its very very easy to debug rails code and work in code that is relatively foreign due to the consistency across the code base. Some of this might be discipline at Shopify, I do think we have a very good code review culture. But I have been places that rest controllers just led to a spaghetti of "Operations" and "Processors" that just change state everywhere and a bunch of microservice network calls. Ruby speed hasn't been an issue. We focus on latency and speed quite a bit and work on keeping request times low. The speed of ruby running is a good trade off for the speed of development I think. And most slow running requests really seem to end up due to network io or database calls that I see. Sorbet uses a kind of type annotation, its very ugly and I do not like it. I really would prefer something more built into the language. Like def foo(Integer x) -> Integer. The big issue is method arguments I think since Ruby already uses :x, x:, x =, and a lot of the other symbols that indicate types so its hard to add it in an optional fashion.

graypegg 3y ago
Just curious, what's your opinion on YARD comments for typing? I have a little more experience with that, than I do Sorbet (or RBS as well) and I found it to be at least tolerable. Though something like your `-> Integer` would be amazing though if there was somehow a way to make it work with the syntax of Ruby.
- ecshafer 3y ago
  The RBS syntax I like, I don't like how its a separate file though. I haven't used YARD but I think it would have similar issues to Sorbet. I much prefer things to be inline in programming languages in general. YARD looking at it, makes me think of Javadoc, which I always saw the issue with it being that it drifted from implementation over time as people don't update it. Sorbet does enforce it to be updated, and will throw an exception so your build will fail. Does YARD do that?

why-el 3y ago

In my experience most Ruby apps (Rails in particular) develop this idea that Ruby is the bottleneck when in reality most of the time it's something else entirely (mostly DB or network IO). Of course you found compiled languages faster! that's by definition. You also tried Ruby on CPU sensitive code bases ("Advent of Code or Project Euler solutions"), that's textbook "ruby is slower than C". Rails pays dividends in the web and in large code bases with many engineers.

byroot 3y ago
Weird, because if anything I keep hearing people say Ruby performance and GVL don't matter because it's all IO anyway. Which is true to a certain extent only. When you first start optimizing a Rails app, it's true that bad queries and N+1 is where most time is wasted, but from my experience once you clear these out, the IO/CPU ratio really isn't that high, generally in the 40-60% IOs range.
- why-el 3y ago
  I didn't mean to say it's all IO, that would be wrong. Rails is feature-rich, ActiveRecord for instance spends plenty of time in the CPU (manipulating its internal state). But the idea that Rails/Ruby is slow is outdated and does not jive with any monitoring and metrics we collected even in extremely busy environments. Of course one would gain some percentage of speed if say your backend is some compiled language, but that would mean possibly slower development cycles, hiring, and so on. Billion dollar companies run Rails, and, crucially, show relentless speed in execution (for instance, Stripe). If anything, Rails has the strongest case yet for performance / feature set.

dcchambers 3y ago

Obviously as an interpreted language, it's never going to be as fast as something like C, Rust, or Go. Traditionally the ruby maintainers have not designed or optimized for pure speed, but that is changing, and the language is definitely faster these days compared to a decade ago. If you like the ruby syntax/language but want the speed of a compiled language, it's also worth checking out Crystal[^1]. It's mostly ruby-like in syntax, style, and developer ergonomics.[^2] Although it's an entirely different language. Also a tiny community. [1]: https://crystal-lang.org/ https://crystal-lang.org/ [2]: https://crystal-lang.org/reference/1.10/crystal_for_rubyists/index.html https://crystal-lang.org/reference/1.10/crystal_for_rubyists...

Lio 3y ago
> Obviously as an interpreted language Isn't the point of YJIT that it's a ruby compiler.

jbverschoor 3y ago

Try Crystal if that's a concern https://crystal-lang.org/ https://crystal-lang.org/