"Go as a language is very opinionated... Go engineers are an anti-magic crowd."
Great so far. But why does this always end up as....
"This tool... auto-generates the code for you"
Great so far. But why does this always end up as....
"This tool... auto-generates the code for you"
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/ )
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.
You can auto-generated code as long as the programmers know the what and why for.
I hate to say that , but at this point, C macros looks better than what the go team decided to do.And I hate C macros.