Speaking as a monolith fan, IMO/IME the main drawback is RAM usage per instance.

You can have a "big, beautiful" Rails monolith codebase used by both Puma and Sidekiq queues etc, and that works well from most standpoints. But RAM usage will be pretty high and limit horizontal scaling.

Yep, that's a great point.

Fixing this would probably require some changes at the language level, or at the module-loader level for some languages that use one.

Does it? RAM is not particularly expensive

Sure, you can get 32GB of RAM for less than $100, but that's not the relevant thing to think about.

Think about it from another angle. RAM is expensive when you're talking about cloud infrastructure at scale.

Or, think about it this way.

For a given compute budget, I can run X instances of Rails, or X times Y instances of a framework that uses less RAM. 100 instances of Rails versus 300 instances of Express or whatever.

Now, it still might be worth it to run Rails, because developer time is more expensive than cloud infrastructure. Or maybe you don't really need to scale. Or you could skip the cloud infrastructure and go bare metal, which is what Basecamp does last I checked.

If by monolith you mean multiple processes that you can control separately, each with their own memory state, you can do anything you want with it. That's essentially multiple services.

Monolith architectures are not constrained to running as a single process or on a single machine at all.

Did you just reply to the first word?