I've used Go on both infrastructure and web projects. "The simplicity of Go" entirely depends on architecture and code quality. Go will force you into some desi

I've used Go on both infrastructure and web projects. "The simplicity of Go" entirely depends on architecture and code quality. Go will force you into some design patterns that are not too favorable if you're not familiar with them. When I was helping people with Go I would see it a lot when people first start using interfaces. I would never claim, as you have, that Go cannot be used on the web or that it won't be just as effective as Java + Spring. Generally I've found most tasks between Java and Go to be similar in complexity (and requiring different approaches), as it seems you found. Where there is a massive difference is tooling and dependency management. That absolutely contributes to developer ergonomics and is a fairly weighty point that is not mentioned in your analysis. Personally speaking, choosing between languages is a non-starter conversation for me. At this point, since my childhood, I have rotated through 10+ languages. Languages are certainly tools and picking the right tool for the job is important. That said, I don't want to work at another company that mandates one language (as is commonly the case with Java) across the entire enterprise. We need solutions that bridge tooling language gaps for enterprises more than we need archaic mandates about what I'm allowed to write in for a given purpose.