I've worked with Rails at two companies: 500px and Shopify. The former was what I take to be typical use of gems and monkeypatching magic. I didn't like it, tho

I've worked with Rails at two companies: 500px and Shopify. The former was what I take to be typical use of gems and monkeypatching magic. I didn't like it, though I ended up doing myself to get other issues under control. (And luckily much new development were as separate services in Go.) The Ruby/Rails at Shopify is much more sane (by my definition) looking much more like regular API made using a statically typed language (lots of Sorbet type info). There is of course dynamic magic, but tends to be limited rather than preferred, and where feasible static Sorbet type info is generated to match what the magic produces so users of magic can operate as if it was just a static typed library with a bit of DSL. There's enough in-house specifics that I wouldn't even call it Ruby on Rails, but rather Shopify Ruby/Rails and it's constantly evolving. There can be 3 ways of doing something: the old way (being phased out), the current way, and perhaps a new one being tested out in some part of the codebase.