I'm gonna play devil's advocate here: Ruby sucks in large codebases where conventions aren't well defined (unlike Rails, which has well understood concepts and abstractions).
Having no ability to do any kind of static analysis means a large legacy codebase will contain giant rabbit holes for you to fall into any and everywhere you look -- unless, of course, the architect(s) responsible for the codebase thought very carefully about this and limited the number of abstractions. If they didn't, you're left stepping through all the metaprogramming and one-off abstraction implementations.
Obviously, my experience is anecdotal, but I've decided my current job is the last Ruby job I'll take. I don't see any reason to pick Ruby over Typescript if you're not using a popular framework. Types save an incredible amount of time when you're ramping up.
I think the issue is with, what GP calls "boring CRUD".
This is where Rails truly shines! It's a near perfect fit. But that means anything that isn't a CRUD-setup, but e.g. command or event driven, or leaning on (complex) domain-logic or heavy in workflows, it lacks.
It lacks features to deal with it. It lacks structure to isolate a domain-model. It makes it easy to spread logic all over, but hard to put that logic in a bounded context. It is all about HTTP, when that really should be a detail in many apps. It is all about the database (as I write in my article "Rails is all about The Sacred Dictating Database") which should really be a boring detail.
"Large codebases" often fall in this category of nog being very cruddy. And therefore probably should eschew Rails. I won't choose it for these cases.
> Ruby sucks in large codebases where conventions aren't well defined
The community is working to improve the outside-Rails ecosystem with efforts like dry-rb or ROM. So you can find plenty of useful non-Rails conventions if you look for them, but if you're doing typical web stuff it is hard to compete with the productivity monster that Rails has become.
> I don't see any reason to pick Ruby over Typescript if you're not using a popular framework. Types save an incredible amount of time when you're ramping up.
I guess RBS and Sorbet are trying to cover this point. I don't know how well they scratch that particular itch of yours as I haven't worked with Ruby for quite some time.
When I was still doing Ruby, dry-rb was one of the projects I was excited about, but it didn't ever seem to gain a lot of momentum, and in my experience, Ruby means Rails (or at the very least something like Sinatra + gems originating from Rails) in almost all companies.
I was also left wondering, at some point, why solnica didn't just abandon Ruby for a statically typed functional programming language, as that seemed where he was headed with his efforts. It's what I ended up doing, at least.
Having no ability to do any kind of static analysis means a large legacy codebase will contain giant rabbit holes for you to fall into any and everywhere you look -- unless, of course, the architect(s) responsible for the codebase thought very carefully about this and limited the number of abstractions. If they didn't, you're left stepping through all the metaprogramming and one-off abstraction implementations.
Obviously, my experience is anecdotal, but I've decided my current job is the last Ruby job I'll take. I don't see any reason to pick Ruby over Typescript if you're not using a popular framework. Types save an incredible amount of time when you're ramping up.