Generics aren't ready for Go

This reads like sour grapes.<p>Basically, this is trying to spin &quot;Popular language missing essential feature&quot; into &quot;But what if it&#x27;s because they&#x27;re braintstorming something EVEN BETTER???&quot;<p>Well, if they&#x27;re brainstorming something better, then I&#x27;ll wait to use your language until you solve all the basic problems first.<p>Plus I think the language-obsession is usually cargo-culting and signaling. All good engineers I know use and enjoy several languages. The hipster&#x2F;all-talk&#x2F;buzzword engineers are the ones who insist on prototyping garbage in a new language every 6 weeks and dropping it entirely thereafter.

&gt; Go strikes me as one of the most conservative programming languages available today. It’s small and simple, and every detail is carefully thought out.<p>This article is wrong in many ways, but I thought I&#x27;d point out this particular one. There are many really weird warts in Go, in fact its about average in &quot;wartiness&quot;. Here is one example <a href="https:&#x2F;&#x2F;dave.cheney.net&#x2F;2017&#x2F;08&#x2F;09&#x2F;typed-nils-in-go-2" rel="nofollow">https:&#x2F;&#x2F;dave.cheney.net&#x2F;2017&#x2F;08&#x2F;09&#x2F;typed-nils-in-go-2</a><p>Go biggest advantage isn&#x27;t the language, its the decent documentation and standard library design. The language is a bit mediocre. I wish the Go community accepted this and moved on - a mediocre language with good documentation and well done standard library is still an acceptable contender since so many other languages get those two wrong.

It’s weird seeing all this post-hoc rationalising when there is a perfect explanation for why go doesn’t have generics:<p>Rob Pike didn’t bother to look into any of the research into type theory and programming language technology. Hence his understanding of types were restricted to Java and C++ and similar (whose type systems are an abomination), and he could not separate subclass polymorhism with inhertance from parametric polymorhism.<p><pre><code> But more important, what it says is that types are the way to lift that burden. Types. Not polymorphic functions or language primitives or helpers of other kinds, but types. That&#x27;s the detail that sticks with me. Programmers who come to Go from C++ and Java miss the idea of programming with types, particularly inheritance and subclassing and all that. Perhaps I&#x27;m a philistine about types but I&#x27;ve never found that model particularly expressive. My late friend Alain Fournier once told me that he considered the lowest form of academic work to be taxonomy. And you know what? Type hierarchies are just that. </code></pre> <a href="https:&#x2F;&#x2F;commandcenter.blogspot.com&#x2F;2012&#x2F;06&#x2F;less-is-exponentially-more.html" rel="nofollow">https:&#x2F;&#x2F;commandcenter.blogspot.com&#x2F;2012&#x2F;06&#x2F;less-is-exponenti...</a><p>I mean he’s openly contemptous of the academics who do research in his field, while wildly mistepresenting their work. But people eat that shit up, because ”OMG it’s Rob Pike” instead of actually discussing the underlying issues.<p>Yes Rob, you are a philistine when it comes to types.. (or at least were)

As a physicist I find out of context references to physics pretty annoying. No go modules are not like a grand unified theory, nor is any other go package management solution like general relativity.

Maybe a Go programmer can enlighten me - without generics, how can you have data structures implementations that can contain more than one type? Do you have to have one linked list implementation for every type in your program? Do you have to abandon type checking by using an equivalent of void pointers? Or is the type system smart enough that you&#x27;d never need generics in the first place?

&gt; The constraints imposed by the lack of generics (and other things Go lacks) breed creativity<p>Uhg such programming language Stockholm syndrome. You could apply this fallacy to any feature. The lack of modules and a performant garbage collector also bred creative solutions in previous Go releases, but that doesn&#x27;t mean that adding those was a bad idea.

<i>&gt;Have you ever seen someone write something to the effect of “I would use Go, but I need generics”? Perhaps we can infer from this that many of the people who are pining after generics in Go are not, in fact, Go users.</i><p>This is the sort non-adhominem adhominem attack that makes these debates so tedious.<p>Obviously, someone deciding not to use Go for lack of generics after giving it a serious try would end up not being a Go user. Does that invalidate their opinion?<p>The logic of this argument is strikingly cult-like. Any criticism coming from non-adherents is automatically disregarded on the basis of it coming from non-adherents.

This article highlights very well why designing a programming language without generics is a mistake. Adding it after the fact is not trivial, especially if you have high standards wrt simplicity and non-redundancy.

I realize I&#x27;m not the audience here, but still -- As someone who isn&#x27;t terribly familiar with Go, most of what I&#x27;m seeing in this article is the shady corners I can&#x27;t see into.<p>The generics one, I&#x27;ve seen plenty of pixels spilled on, and I&#x27;ve come to accept that I won&#x27;t really grok the debate unless I spend some serious time programming in Go. What about the module system, though? Can anyone explain or share an article on what&#x27;s so great about its module system?

An algorithm or data structure may be applied to various types of data. There&#x27;s various ways to handle this. Macro expansion, generics (basically equivalent of macro expansion but as a language syntax), or losing types: void pointers, duck typing, interfaces.<p>Go puts it&#x27;s head in the sand and and handles the problem like it&#x27;s 1970 with the &quot;void pointer&quot; way of thinking. That&#x27;s fine if you&#x27;re using a dynamic language (ie python, lisp) and firmly decided your trade offs with regards to types and performance. But if you elect to use a statically typed language, it would be nice to reap the benefits.<p>Modern C++ is still the only way to go for serious software. Rust maybe in the future as the compilers improve. Go is a no no-go.

I don&#x27;t understand how not having generics is at all acceptable. But maybe that&#x27;s because I come from a functional programming perspective.

&gt; they feel that generics are a good fit for this language<p>Or that it&#x27;s ludicrous for any statically typed language to not have generics.<p>&gt; It’s small and simple, and every detail is carefully thought out &gt; Nearly all of Go’s features are bulletproof &gt; my opinion are among the best implementations of their concepts in our entire industry<p>Uh huh.<p>&gt; You could write a book called “C++: the good parts”, but consider that such a book about Go would just be a book about Go<p>Or it could be one-liner: &quot;easy concurrency&quot;.<p>&gt; simplicity and elegance are now the principles I optimize for<p>Doesn&#x27;t everyone who cares? The problem is that elegance and simplicity, like beauty, are in the eye of the beholder.<p>To me, generics increase elegance and simplicity.<p>&gt; If you’re fighting Go’s lack of generics trying to do something Your Way, you might want to step back and consider a solution to the problem which embraces the limitations of Go instead<p>So pretend it&#x27;s the 70s and use void* (interface{})?

The way he describes Go&#x27;s existing feature set as unwavering perfection is disappointing. No language is perfect except in heavily constrained context. They all make trade offs. GC is itself a compromise and so it follows that Go is not <i>the one true language</i>.

Been using Go for 4 years. I totally agree. It sucks to have to use your brain to think about alternative ideas on how to do something. However, I’ve come across much much better solutions to my problems than I would have if Go offered a crutch to my flawed thinking.

I keep thinking they could add macros instead but I guess the C++ version is too much history for them to be associated with. It would basically be like code generation at compile time, except much cleaner than the current, version-specific mess of tools.