Got it. It's not impossible but I've been at multiple jobs involving Rails monolithic apps, they all really sucked from a maintenance and development perspective.
P.S would have been happier if you had a better choice of words than "knocking myself out".
Yes, I’m at one of those companies now, spaghetti code galore, and the project is becoming increasingly harder to maintain.
As the company scales they really need to break things into more services to distribute work and satiate work happening in other languages, but now that’s nearly impossible because of the mess they’ve created
Rails is great if your building a basic “dumb” web app, but rails folks seem to think it’s more than that and need to get their heads out of the clouds
I've worked on a lot of legacy Rails apps. Most of the problems of "spaghetti code" occur because people write bucketloads of un-Ruby-like code that betrays a serious lack of understanding around how Rails really works. Whenever I hear "aw man, Rails sucks. I switched to writing (X) in Rust/Go/Haskell/TypeScript/whatever…"
Let me stop you right there. If you tell me Rails wasn't meeting your needs so you rewrote (X) in a different manner using Ruby + something else, I'd totally understand. Otherwise, all it tells me is that there was a tragic lack of deep Ruby knowledge, respect even, to begin with as the project unfolded. Often I muse on how in some ways it was unfortunate that Rails became such a darling in the startup community early on. It meant that a ton of people jumped into Rails web dev thinking they were writing "Rails". No, you're writing Ruby, and Rails just provides a nice set of base classes and some decent defaults and assumptions. If you end up with a giant wad of spaghetti mess, that's on you. It's totally feasible not to end up there, and plenty of projects end up in far better shape.
P.S would have been happier if you had a better choice of words than "knocking myself out".