A lot of Ruby's syntax lends itself towards cramming as much business logic on the screen as it can. I used to say it's a "semantically dense" language, but I don't actually know if that's technically accurate. Compared to Java or Rust I certainly felt like Ruby fit more "logic" into a screenful of code, but at the cost of any other context (type annotations, import notes, etc)

I strongly appreciate how much decision fatigue Rails avoids by just offering you so much batteries-included stuff. I tried getting into Django and immediately spun out fretting over what ORM or migration manager or caching system to use. (One of my coworkers who is a huge Django says I'm nuts and that Django offers those things too, so I may be misremembering.) Rails being as opinionated as it is saves so much thinking effort along those lines.

I think both of those facets make it extremely appealing to, as you say, anyone greenfielding code, and are the exact things that make it an absolute trash fire to maintain anything of appreciable size.

We're constantly fielding incidents due to something being undefined or unexpected nils or other basic typecheck failures.

> it just optimizes for a set of values that I don't happen to share anymore

That is a lovely way to put it, I'm gonna steal that

You can search for "def process" - it's inheritance and metaprogramming that make finding the underlying implementation difficult.

Well, just add "puts caller" in the function to find out. You can do this in your own code, but also you can also just briefly patch the library you're working with, if that's where the process is.

By the way, the generated identifiers are more a rails thing than a ruby thing.

> lack of static types

RBS is a thing; we use it extensively.

> Good luck finding where the `process` function is called from

I don't use it like that but I seem to recall RBS itself has a query mechanism and can answer these kind of questions.