3 ms·

I very much feel that both generics and deps were against the “spirit of Go” (trivial simplicity, stability, manageability) and a reaction to the perceived dema

I very much feel that both generics and deps were against the “spirit of Go” (trivial simplicity, stability, manageability) and a reaction to the perceived demands of “The Community” taking precedence over the opinionated, orthodox and even antisocial original design of the language. This just looks like another fluffy, friendly concession to “usability” and “what the crowd wants” at the expense of what set Go apart from the crowd. But hey, maybe I’m just being a curmudgeon and it’ll be great. As the article mentions, there was nothing stopping you from doing this sort of thing (and worse; channels as “iterators”, anyone?) in older versions of Go. But it would be silly to do, and you’d get (rightly) scolded for doing it. Now I guess that kind of thing is encouraged. :)

MarkMarine 2y ago
The way "generics" were implemented previously by code generation was just gross, new generics just accept that the standard library didn't make enough containers and probably shouldn't have to make every container type part of the stdlib. Next step to that logic is these iterators, why should the compiler magically support "for range" syntax on slice and map, but not on a map or tree you made. I don't understand the aversion to this, if you don't like it don't use it, but this cleans up the multiple different loop patterns and collapses them into a for range syntax, now you have 1 way to loop instead of multiple ways. The actual implementation of this, making an iterator, is more of a fix for the people developing custom container libraries, which the majority of the go community probably doesn't do. You can go on being a productive go dev and literally never learn this syntax, it won't change your use.