And they were right. The generics in Go have turned out dogshite... I try to avoid them at all costs because besides simple data structures like Trees and so on, they're just more trouble. Go was not meant to have generics.

It literally had generics from the very first day. They were just gate kept from the "smelly, lowest common denominator code monkey morons", because noone could match the genius of their creators, or ever have the same issues to solve as the creators (because their little brains are too tiny).

It's lists, and maps.

Self imposed fault, by ignoring computing history since 1976.

Static typing prevents reusing functions unless they're generic. The other option is to give up static typing and pass "all" everywhere, like a dynamic language.

> that the Go team exhibits engineering genius, taste, and particularity that is rare to find in our industry

> The generics in Go have turned out dogshite

Pick one.

I guess it's fine for what it enables, Tree[T] of some kind basically. But we had that with codegen already.. People who really needed trees, could do that forever. However, the issue is the "unwashed"—like they said in adjacent comment—putting them everywhere now, where an interface would be more fitting. Hopefully I'm explaining in terms that you can comprehend.

This is dogshite because I have to fork a bunch of stuff to actually use it!

I used go for about 3 years, so yeah I understand... but I can't believe you actually like copy-paste/codegen more than actual native language facilities. Mind blowing to be honest.