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"
You have been using a generic data-structure since Go 1.0 but did not realize this.