[boboroshi]

Monoliths can be great or a disaster, as can total services setups. We took a monolith built by a small team into scores of services across 4 teams of 150 engineers, even implementing some of them in Scala (this was 2012ish). On the internal tools side, we created a gem and later a bower package (so vintage) that was a bootstrap-derived design system that worked across almost all 30 internal tools apps & services. I know other teams did the same (at least consumer and merchant), but I didn't work on those projects so I can't speak to them.

I've seen great ruby/rails code and I've seen abysmal ruby/rails code. A lot comes down to who wrote it and if they ever refactored the smelly parts.

After 20+ years, I often see that no one likes to refactor the smelly stuff until they're forced to, and we often end up working with a cool racketball of code covered in 2' of duct tape patches.

Go is the new hotness, as was Rails at one point, and in the near future it will be something else. There's a strong neophillic bent to most developers. It's a lot more fun to work in something that's new and evolving and solving crazy problems than something that is stable.

These are all tools in the tool kit. Use what lets you ship.

[mountainriver]

> n great ruby/rails code and I've seen abysmal ruby/rails code. A lot comes down to who wrote it and if they ever refactored the smelly parts.

This is largely the problem, Go enforces good dev behavior, Ruby leaves it up to the dev

[postmodern_mod3]

How so? Go does not prevent you from writing a monolith. Furthermore, Go does not actually require that you check the err return value of functions.