Ruby's entire programming model was based on the premise that language speed does not matter since most of the time you are waiting on IO / Network. Well now, both on Node.js and JVM we have programming models which say that - while I wait for IO / Network let me do some other work or service more requests (Async / Webflux / Coroutines).
IMHO - using Ruby/Rails in 2024 can be wasteful, but of-couse for the right situation it can be a good choice. (Just) For example an enterprise app where you know the number of users will be limited, or when you know the development speed is paramount or where you want to build a quick proptype to test the market out. Rails is a great framework and the productivity is unmatched, but with time a 2-3 years old Rails project is always tricky to maintain.
Ruby now has Fibers and other constructs for async like Ractor.
> Rails is a great framework and the productivity is unmatched, but with time a 2-3 years old Rails project is always tricky to maintain.
It isn’t any less tricky than a Django or Express project. With any codebase discipline and regular tending to the garden of code is important to prevent weeds from growing.
If anything that Ruby (and Rails) has going against it is still the raw language performance and higher memory requirements/usage than its counterparts, which makes it less desirable for workloads that require low latency or small memory footprint
I guess it depends on how one defines "productivity:" is it spitting out code as fast as your keyboard works, or is is not having features do weirdo things because who can reasonably say what the code does at any given time?
I have more than once tried to contribute fixes to GitLab's codebase, and every time I open the thing in RubyMine it hurpdurps having no earthly idea where symbols come from or what completions are legal in any given context. I trust JetBrains analysis deeply, so if they can't deduce what's going on, then it must take an impressive amount of glucose to memorize every single surface area one needs to implement a feature. That or, hear me out, maybe "it works on my machine" is a close to correct as the language is going to get without explicit type hints as a pseudo static typing
Bugs exist in all code written in all programming languages and you will find bugs in programs written in statically typed languages too as you know. Programming languages are rarely chosen for the absense of bugs alone though or we'd all be using SPARK Ada or something.
> spitting out code as fast as your keyboard works, or is is not having features do weirdo things
This is a straw man. No-one has suggested that "spitting out code as fast as your keyboard works" is what Rails allows you to do, or that Ruby code results in features that "do weirdo things".
In reality engineer productivity is important and Rails enables it in a web environment.
> I have more than once tried to contribute fixes to GitLab's codebase, and every time I open the thing in RubyMine it hurpdurps having no earthly idea where symbols come from or what completions are legal in any given context.
Yes, I prefer writing statically typed languages and I would /greatly/ prefer Ruby to be statically typed for a number of reasons, but it will likely never be so in a way I consider to be usable (see https://github.com/ruby/rbs). Not being able to definitively tell what a method returns or where one is defined is a total PITA, but it's one of the array of up and downsides to Ruby, with each language having a different set.
> I trust JetBrains analysis deeply, so if they can't deduce what's going on, then it must take an impressive amount of glucose to memorize every single surface area one needs to implement a feature.
You don't need to know how all of Rails works to write a Rails app, as I'm sure you know, so this seems like another mis-representation of the truth, just as you don't need to know how the compiler or CPUs work to do a lot of (most?) programming.
> That or, hear me out, maybe "it works on my machine" is a close to correct as the language is going to get without explicit type hints as a pseudo static typing
You seem to be suggesting that Ruby on Rails applications behave unpredictably on a machine to machine basis but that's not really how Ruby works in practice, or matching on my experience.
Meh, it's fine for 99% of use cases. Rails only becomes a pain in my experience if you have random, huge swings in traffic or a ton of active users with websocket stuff (mostly solved by anycable). But very few products are going to reach those limits and if they do those problems can be solved too.
Stripe, GitHub, and Shopify are the shining examples of Rails scaling in all kinds of ways without problem.
Not sure how long you were there nor which team you were on, but as someone who's still working on Shopify infra after a decade, I disagree with you.
Scaling problems at Shopify are rarely if ever directly Rails related.
The biggest challenge was always scaling the database layer, and to some extend the deploy pipeline of the monolith given the amount of people working on it.
Perhaps we can debate whether this is really a Rails-specific problem per se, but we definitely had lots of problems scaling to prevent long-running IO from saturating web/job worker pools for things like taxes, shipping rates, syncing external inventory, ad syndication, etc -- anything where we had to make multiple network calls to the outside world from a Rails thread was a big pain.
Stripe doesn't use Rails. Stripe's application of Ruby is far removed from your typical Rails app. A lot of custom stuff was built into Ruby to make the multi-million line codebase work as well as it does.
I believe Github still use Rails for their main application. Spinning services out into microservices, even ones that are other languages, isn't really a sign that Rails isn't working for them, it's just what happens when companies scale. The company I work for is a Rails backend (React frontend) and we have some services split out into Go based microservices (eg. Twilio webhook handling has been offloaded to Go in Lambda), but it's still very much a Rails app.
> Even their frontend I think is now just react
It remains to be seen how successful this is and what the reasons were for the change. Personally I don't like it, it's less reliable and slower than before.
> Ruby's entire programming model was based on the premise that language speed does not matter since most of the time you are waiting on IO / Network.
Couple of points. 1) You probably mean Ruby on Rails and not Ruby and 2) that's not true of either. Ruby or Rails "entire programming model" was not based on thoughts around I/O at all, a huge about of the driving force behind Rails was DHHs ideas about developer happiness, which is intrinsically linked with speed of development.
Discussions about I/O /do/ happen in the Rails community because it's important when you're running a web server which is a lot of the use Ruby/Rails is involved in, but it's not the sole (or even a major) focus of the decisions made for the language or framework.
> Well now, both on Node.js and JVM we have programming models which say that - while I wait for IO / Network let me do some other work or service more requests (Async / Webflux / Coroutines).
Right, but if the goal is to maximise CPU usage of your web servers then you can completely do that using Rails, and have historically been able to do so by spinning up multiple processes in the same way you'd spin up multiple threads in, say, the JVM. Not as convenient perhaps, but a model that's been in use since at least the 90s when I started out. Luckily it turns out that web requests can generally be run in isolation so IPC isn't usually an issue (the same reason why multiple physical web servers is simple, just as multiple processes is).
> IMHO - using Ruby/Rails in 2024 can be wasteful, but of-couse for the right situation it can be a good choice. (Just) For example an enterprise app where you know the number of users will be limited, or when you know the development speed is paramount or where you want to build a quick proptype to test the market out. Rails is a great framework and the productivity is unmatched, but with time a 2-3 years old Rails project is always tricky to maintain.
Wasteful as a generalisation is blunt. Of course it can be wasteful, but so can writing your app in rust, it just depends where the pressures are. I'd suggest that not launching is a far bigger concern to most people at an early stage, and even mid to late stages developer speed is one of the most difficult things to scale.
Personally I'm the CTO of a company that uses Rails (backend, React frontend) and developer speed is /hugely/ important to us. We're always constrained by engineering resources and the speed of Rails development continues to be a huge win for us. We do have scaling issues, but 99% of the time they're not Rails issues, they're in the database.
IMHO - using Ruby/Rails in 2024 can be wasteful, but of-couse for the right situation it can be a good choice. (Just) For example an enterprise app where you know the number of users will be limited, or when you know the development speed is paramount or where you want to build a quick proptype to test the market out. Rails is a great framework and the productivity is unmatched, but with time a 2-3 years old Rails project is always tricky to maintain.