My thought exactly. And now Go even has a code generator tool bundled with it ... I don't understand Go designers. This goes against everything they said Go was

My thought exactly. And now Go even has a code generator tool bundled with it ... I don't understand Go designers. This goes against everything they said Go was. But 2 problems illustrate in my opinion the Go team mindset. People want a package manager, the Go team says vendor deps.Well except vendoring has nothing to do with managing lib dependencies.So there will be multiple incompatible package managers. People want generics(Go has generics,you just can't define your own generics) , the Go team answers use "go generate", so people come up with their own "generate generics from Go source files" tools which of course use incompatible systems. People want a spec for struct tags, the Go team says no.Why the hell would you want to use struct tags if different libraries parse them different ways ? What if a user wants to use 2 libs that use struct tags in an incompatible way? So basically the Go team isn't interested in 3rd party input,which is a choice I respect,even if I don't agree. the reason of all this is that the Go team isn't interested in adding new features to the language, period, so they could care less about user input,which IMHO will lead to language FRAGMENTATION eventually. (source : changelog podcast : https://thechangelog.com/148/ https://thechangelog.com/148/ ) It's terrible because Go is this close to be the language most developers would need and has great concurrency primitives unlike D or others.