How generics are implemented in Go 1.18
So maybe 7-8 years ago, I got into a bunch of arguments with people on Hacker News because I said that Go&#x27;s type system was ineffective without generics. At that time, Gophers leaped to defend it, going so far as to say that it&#x27;s better because it&#x27;s simple. Oh and it was really important to Gophers that Go compiles in a single pass (which I argued is only relevant for truly enormous codebases like Google&#x27;s).<p>A few years later we had go generate. Which I argued was a glorified C macro system to get around the lack of generics. Oh and everybody forgot about the single-pass thing, I guess.<p>Now in this thread there are a bunch of people commenting that they can&#x27;t wait to combine all their <i>copy pasted code</i> using a generics which are implemented via a tree traversal that actually kind of complicated the idea of what a pass even is (I think memoization could make this linear, but at the cost of memory?).<p>This is a language that seemingly insists on breaking the wheel. Notice I didn&#x27;t say <i>reinventing</i>, because in over a decade they haven&#x27;t actually gotten a working version of the wheel out yet. I mean seriously, Go was released in 2009: if I&#x27;m not mistaken, C# had a pretty good generic system already, and there were a bunch of other workable options to copy from less-mainstream languages. Not that copying has helped: they copied coroutines from other languages, but failed to present a coherent memory sharing model (just copy Erlang FFS), which severely limits the usefulness of coroutines.<p>Every few years someone gets me to try Go out again and I discover, yet again, that it&#x27;s still struggling with problems that were solved before it existed. It&#x27;s a shame that this language has stolen so much mind share from more deserving languages.