> it's a language for the person who has to come along and take over their codebase after they leave. Hard disagree. I'll grant that in the trivial case , bas

> it's a language for the person who has to come along and take over their codebase after they leave. Hard disagree. I'll grant that in the trivial case , basic cli apps that have to do one thing, the maintainability of go is high, maybe even a very simple microservice. But once you get something more inherently complex, especially if it must do concurrency in all but the most trivial of things (especially as you get concurrent requests that must handle faults, say from a crappy network or a 3rd party system) the language is far, far less easy to get a mental model of, much less debug in anger (or with a system in prod), or even write tests. In my experience, go tests are terribly illegible, often my go coworkers just don't write them, which is worse. Maybe I've just been spoiled by elixir (relevant given the OP topic). And for the record, I've inherited a codebase that has gone through three-ish teams. I work on my corner and I can be fairly sure that the changes I make, features I build are isolated and safe. And this is even with parts of the codebase that I cringe at (and over time I gradually refactor them, with confidence). I have all the tools to ameliorate the team code, and even for the crap parts, reading isn't hellish, and refactoring feels good.