[irvingprime]

Rails does not have to be written as a monolith. Typically, junior programmers who are trying to move very fast do that. Most of the places where I have talked to people who have a monolith are looking for ways to split it into services.

If you wrote a system in Go as a monolith, it would be hard to trim down, too. Architecture matters MUCH more than the implementation language.

[kenhwang]

Not sure Go is a very good example here, compiled languages have a huge maintainability advantage in monoliths (at the cost of compile time).

Ruby/Rails' culture is a huge contributor to why Rails monoliths are so much more difficult to maintain compared to other dynamic languages. Things in Rubyland just love to be global and manipulate things globally and go out of their way to make that behavior hidden.

[jaredcwhite]

"Rails monoliths are so much more difficult to maintain"

I question that assertion. I have plenty of anecdotes which are the exact opposite: a Rails monolith is much easier to maintain compared to similar approaches in other languages.

"manipulate things globally"

Not sure what you mean by that to be quite honest. If you mean monkey-patching, that's generally been frowned upon except at the framework-level in the Ruby community for quite a while now.

[irvingprime]

Global? In "Rubyland?" No. That's just not true. Not at all.

[mountainriver]

That's totally fair, it seems to trend toward a monolith though, just from what I've seen