On: Ruby 3.2’s YJIT is Production-Ready

[byroot]

If you look at the breakdown per service, EC2 (assuming mostly Ruby) seem to be at best 20% of the bill: https://twitter.com/dhh/status/1613508201953038337

So if you are to make Ruby ~10% faster, you might reduce Basecamp hosting bill by 2% at best.

[DoctorOW → byroot]

> Remember, this excludes the current Basecamp and Basecamp 2, which use our own hardware for this

https://dev.37signals.com/our-cloud-spend-in-2022/

[pantulis → byroot]

Thanks for spotting that, I had missed it! This goes to show (again) that the "Ruby/Rails does not scale" myth is fictional.

[earthnail → pantulis]

There are organisational scaling issues that you may hit with a language like Ruby that strongly typed languages like Java can solve.

And so Ruby may scale in cpu performance, but not with your number of teams.

That’s why Spotify switched to Java (I think they were a heavy Python user before that, not Ruby, but not sure anymore - but the organisational problem is the same for those two).

Note that I still choose Rails for all my projects, but my company is small.

[gtirloni → earthnail]

> There are organisational scaling issues that you may hit with a language like Ruby that strongly typed languages like Java can solve.

Such as?

[pantulis → gtirloni]

This also interested me.

I'd guess that the idea parent is trying to convey is that for a given size of a Ruby codebase the engineering organization needs to be structured like successful cases like Github, Shopify or whatever, but I'd be interested in the technical aspect to this. I agree with this idea when reasoning about microservices, but this is the first time I've seen it applied to the choice of language. It's intriguing.

[gtirloni → pantulis]

Judging by parent poster's comments everywhere, they have an habit of saying such facts without much substance. I wouldn't hold my breath but I'm interested as well.