Generics are a basic language feature for a statically typed language. Go needs a lot more features to be usable, like better error handling, but the ultra-conservative community that opposes any changes is a drag on the language and makes developing in it a miserable experience.
I guess what I'm caught up on is the idea of "usable" is entirely subjective. To my eyes and fingers, Go has been fine without generics, and since their addition I've only used them once to clean up an odd bit of code around instantiating "module" like initializers.
> and makes developing in it a miserable experience.
Subjective or not I find this a bit harsh. I spent years in an environment where C was the only option that could be used and Go is a complete dream compared to this. You may dislike the environments, you may find fault with them, but there are many examples of both of them being used to build large and complex systems that aren't completely "miserable" to work on.
I wonder if the split is something like "batteries must be included." I don't feel this way. I'm content to mine up Zinc and Copper and forge my own batteries if needed. I'm not at all put out by this.
Please search/replace all `map[x][y]` in your Go projects with `map[sting]interface{}` in order to be honest and consistent with your opinion. And explain to all your stakeholders that you have done so because generics is bad.
You have been using a generic data-structure since Go 1.0 but did not realize this.
> in order to be honest and consistent with your opinion
Did you mean replace `map[string]string` with `map[string]interface{}`? You should take a look at Go's runtime map code. This is not a "generic" data structure. It's an unsafe data structure with some thin compiler sugar on top of it which is also something worth taking a look at.
For example see how it handles something like `m["x"]` versus `m[12]` or a map using structs as keys. Put it in Godbolt then chase down the various runtime implementations you encounter. Unless I'm misunderstanding you, then I apologize, but what else did you mean?
> explain to all your stakeholders that you have done so because generics is bad.
I also write code based upon engineering principles and not on the difficulty of explaining it to my peers or customers. I'm more concerned with the results they experience when they use the software.
> generic data-structure
What we call "go generics" has nothing to do with "typed go maps." To the extent that I've needed something "generic" up until they were formally introduced into the language careful interface design was enough to cover 90% of use cases. For the ones that weren't a map holding a function which wrapped a type-checked cast operation did the rest.
So all we're left with is the ability for the current go generics to automatically populate functions into your compiled image based upon instantiated and optionally constrained type usage rather than some explicit and planned mechanism implemented through interface.
Apologies for the stupid typo. Anyways, I think we will need to simply agree to disagree because of this statement:
> I also write code based upon engineering principles and not on the difficulty of explaining it to my peers or customers.
I believe that difficulty of explaining code to "my peers or customers" is a basic engineering principle.
Also, I consider what the compiler does behind the scenes as irrelevant as long as you have reasonable performance and usability qualities. That's one of the fundamental principles of abstraction after all.
Btw, the inventor of the C programming language also said this. Dennis Ritchie -> "Code should be written for humans first, machines second"
Interesting that they write "I don't use Go" but are still convinced that "developing in it [is] a miserable experience". So, which one is it now? I think many people would be positively surprised if they tried Go approaching it with an open mind, but all the FUD spread on HN and similar forums prevents that...
Generics are a basic language feature for a statically typed language. Go needs a lot more features to be usable, like better error handling, but the ultra-conservative community that opposes any changes is a drag on the language and makes developing in it a miserable experience.