What would you say Go does objectively better? I think you might say threading. Maybe? The JVM can be tuned to get similar performance. Where it fails to get s

What would you say Go does objectively better? I think you might say threading. Maybe? The JVM can be tuned to get similar performance. Where it fails to get similar threading performance, it has better tuning in general. Simplicity of the language? Maybe? It's simple, but I think it's too simple. One of my issues with Go is that it's hard to tell what implements what. VSC support is a little hit or miss. The fact that I have to use an IDE, or extension pack in VIM/Emacs, to figure this out is terrible. I like that in C++, Java, Python, C#, and Typescript I can clearly see which things a current struct implements. It makes code navigation easier. The lack of generics makes certain natural, and I mean natural as in how the majority of other languages do things, solutions to problems hard. Do you want a set, i.e. a unique collection of things? Use a map, but keep in mind that equality is at the whole struct level so one field being off and you have logical duplicates. You can't make structs immutable. Community lead structural design? Most Go apps appear to be transaction scripts where the database connection is created at the handler and explicitly passed down or perhaps buried in a Context. This makes testing hard. You have to mock/stub the DB interface to test business logical. If I want to introduce interfaces that wrap the DB away, I'm told by the community that I'm "overthinking things" or I'm not a true gopher. Produces a binary? I agree.