> 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.
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.