
Generics aren't ready for Go - kragniz
https://drewdevault.com/2019/02/18/Generics-arent-ready-for-Go.html
======
alexandercrohde
This reads like sour grapes.

Basically, this is trying to spin "Popular language missing essential feature"
into "But what if it's because they're braintstorming something EVEN
BETTER???"

Well, if they're brainstorming something better, then I'll wait to use your
language until you solve all the basic problems first.

Plus I think the language-obsession is usually cargo-culting and signaling.
All good engineers I know use and enjoy several languages. The hipster/all-
talk/buzzword engineers are the ones who insist on prototyping garbage in a
new language every 6 weeks and dropping it entirely thereafter.

~~~
emersion
>Popular language missing essential feature

But is it an essential feature? I've written a lot of Go code and I'm
perfectly fine without generics. It makes my code a lot simpler, no need to
abstract everything into Thing<OtherThing implementing Stuff,
YetOtherThing<Thingie implementing This or That>>. By the way, C doesn't have
generics.

If you really need generics that badly for your use-case, nothing stops you
from using another language.

~~~
bunderbunder
Bringing up C invokes my suspicions about this debate: It's really people with
totally different use cases talking past each other.

C doesn't have generics. Java has extremely limited generics. In both cases,
it means that it's annoying and difficult for me to write a decent math
library. I have to choose among making it support only one numeric type,
implementing many copies by hand (one for each numeric type), or using some
sort of ugly code generation tool - who knows what in Java, the preprocessor
in C - to implement all those copies.

Which might not be a problem for everyone, but, for my use case, it's
annoying.

(Deliberately avoiding the "generic library of data structures" use case
because, while generics are what brought that to most of us ( _edit - in the
world of static typing_ ), it would appear that Go's handling that case just
fine without them.)

~~~
emersion
I'd say either resort to code generation or pick another language that fits
better your use-case.

~~~
bunderbunder
Yeah, sorry if I wasn't being clear. That's pretty much the line I was
thinking along.

It's perfectly fine for Go's answer to be, "Go doesn't have generics because
generics aren't needed to solve the kinds of problems Go is designed for
solving, and we are _not_ trying to be a kitchen sink language here. If
generics are something you need, please pick a language that's designed to
solve the problems that you're trying to solve."

But that's a far cry from what TFA said. TFA read more to me as, "Go doesn't
have generics because generic programming is a half-baked idea that isn't
ready for prime time."

~~~
bunderbunder
Or, to throw a third option one out there -- "Go doesn't have generics because
they would interact poorly with some other aspect of the language." That
works, too.

For example, it's why F# continues not to have ad-hoc polymorphism, despite
many users clamoring for it. I'm inclined to agree with the project's
maintainers on the subject. As useful a thing as it is, and as glaring as it
is for a modern descendant of ML not to have it, it's hard to see how it could
be added without creating all sorts of language warts.

~~~
louthy
Both F# and C# can do ad-hoc polymorphism - I use it in my language-ext
library [1], the library is C# but the principle is the same for F#. It's not
idiomatic (or pretty), but it's possible if needed. Higher-kinds is the killer
missing feature.

[1] [https://github.com/louthy/language-ext#ad-hoc-
polymorphism](https://github.com/louthy/language-ext#ad-hoc-polymorphism)

------
spion
> 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.

This article is wrong in many ways, but I thought I'd point out this
particular one. There are many really weird warts in Go, in fact its about
average in "wartiness". Here is one example
[https://dave.cheney.net/2017/08/09/typed-nils-in-
go-2](https://dave.cheney.net/2017/08/09/typed-nils-in-go-2)

Go biggest advantage isn'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.

~~~
throwaway415415
Sucks for you, considered very good by plenty of other people who use it
daily.

~~~
rebeccaskinner
I use Go daily and I agree with the general sentiment that it's a janky
language full of warts and could really benefit from features like generics.

~~~
throwaway415415
Maybe go back to java or c++? I'd rather have less people complain about a
feature I don't want in the language.

~~~
latronic_notron
Just curious: why don't you want generics in Go?

The language already uses them for Arrays, Maps and Slices, plus a lot of code
relies on runtime-typed ad-hoc generics with interface{}.

It's not as if Go is a language without warts... there's a lot of ugly stuff,
like Iota, Reflection, the error handling, interface{} itself.

This is a legitimate question, btw. Legitimately looking for other points of
view

~~~
apta
Keep in mind that many golang programmers just parrot what the golang authors
say, without fully understanding it or even realizing the golang authors are
wrong (not saying that's the case in this specific instance).

They hear the golang authors complain about Java, that it's the only way to do
things, so they think that the only other solution is to go the extreme
opposite way, not even looking at real modern languages (which golang isn't)
like Kotlin or even C# for instance.

It's very evident that the golang authors have no experience designing
language, and didn't look in depth at what other languages did.

~~~
throwaway415415
Unfortunately I am not parroting. If you are used to read code, and you read
c++, you will see that templates are abused. No generics force devs to make
their code clearer and thus more secure.

It is evident that Go is a better language than most thanks to the creators
having deep experience in that domain.

~~~
latronic_notron
They aren't abused in C#, Java, Haskell, OCaml and other languages. Honestly,
picking C++ as an example of traditional generic usage is a bit disingenuous.

~~~
Gibbon1
I think generics in C# are really well executed and solve a lot of problems in
C#'s problem domain.

I do think you're on the right track that go's designers are pushing back hard
on what they see as feature abuse in C++ and Java. C++ abuses templates and
has dozens of ways to do anything that also don't interact with each other
well. Java abuses inheritance, abstractions, and OOP.

go uses generics under the hood, probably the designers fear that generic's
will also get abused if released into the wild. On the other hand I've never
heard anyone bitch about well designed generics in other languages. Which is a
tell since people will bitch about anything and everything.

~~~
latronic_notron
> I do think you're on the right track that go's designers are pushing back
> hard on what they see as feature abuse in C++ and Java

Now that you mention it, I can't really blame them!

> On the other hand I've never heard anyone bitch about well designed generics
> in other languages. Which is a tell since people will bitch about anything
> and everything.

That's my opinion as well. Generics are quite pleasant, simple and a great
tool to have when they're well designed.

------
cannabis_sam
It’s weird seeing all this post-hoc rationalising when there is a perfect
explanation for why go doesn’t have generics:

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.

    
    
        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'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'm a philistine about types but I'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.
    

[https://commandcenter.blogspot.com/2012/06/less-is-
exponenti...](https://commandcenter.blogspot.com/2012/06/less-is-
exponentially-more.html)

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.

Yes Rob, you are a philistine when it comes to types.. (or at least were)

~~~
jstimpfle
Or maybe the academics and type theorists are philistines about the software
that runs the world and their arguments have mostly been about hand-picked toy
examples?

Maybe Mr. Pike actually has some well-deserved reputation when it comes to
real-world software and engineering projects that are about handling large
scale data in real time?

~~~
ernst_klim
>about the software that runs the world

Software that runs the world utilizes parametric polymorphysm in C++, Java,
Ada, D, Swift, OCaml, Haskell etc, hell, even C [1].

I also tend to consider some mission critical Ada/C++ software a real
engineering, not some webshit.

[1]
[https://github.com/jiixyj/libebur128/blob/master/ebur128/ebu...](https://github.com/jiixyj/libebur128/blob/master/ebur128/ebur128.c#L610)

~~~
jstimpfle
And [1] actually makes a point that we don't need language support for every
imaginable use case (maybe not even Generics). It's not a problem to work
around a "missing" feature, sometimes.

------
orbifold
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.

~~~
bunderbunder
Just enjoy that these kinds of references give you so much latitude for
interpretation.

For example, in the absence of any practical exposition demonstrating that the
module system solves problems that other systems don't, you can quite
comfortably (and cynically, sure, but please let me have my fun) choose to
interpret the analogy along these lines: General relativity is well-
established, reasonably well-understood, and is essential to making a sizable
chunk of the modern world (e.g., GPS) work. Whereas nobody's been able to
demonstrate a working GUT yet, so currently its main practical use is as
fodder for books and TV specials.

------
whatshisface
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'd never need generics in the first
place?

~~~
kasey_junk
First go does have generics. It just doesn’t have user defined generics.

But to answer your question go has really mediocre support for a wide variety
of problems. Some that burn me a lot is support for future/promises and
support for modern lock free algorithms.

So you end up either writing non-optimal replacements, losing type safety or
in some case code generation is used.

~~~
emersion
>Some that burn me a lot is support for future/promises

This doesn't make sense in Go. Nothing is asynchronous in Go, everything is
blocking. You use goroutines to execute multiple tasks at the same time.
That's a big part of what makes Go simple: it's a lot easier to understand
sequential code than spaghetti callbacks and promises (it's somewhat similar
to async/await in the JavaScript world).

~~~
heavenlyblue
Yeah, and that's why Go code is a spaghetti of communicating via channels,
rather than callbacks.

~~~
johnydepp
Go channels are very handy and magnitude of less spaghetti than futures. And
goroutines have good performance.

I think people are used to futures etc, that's why the new concept feels
strange.

I think the goroutines and channels are the biggest features which compensates
for generics.

------
gok
> The constraints imposed by the lack of generics (and other things Go lacks)
> breed creativity

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't mean that
adding those was a bad idea.

~~~
emersion
As said in the article, solutions to these problems have now been implemented.
These solutions _feel_ very Go-ish. Modules are an elegant solution. Adding
them was a good idea.

Until we find an elegant solution for the generics issue, it's better not to
have them.

------
fauigerzigerk
_> 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._

This is the sort non-adhominem adhominem attack that makes these debates so
tedious.

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?

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.

~~~
klmr
In addition there are plenty of people who _do_ use Go yet still criticise its
lack of generics. But apparently these are not “real” Go users?

------
u320
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.

~~~
jstimpfle
You're implying that there is a better design that has generics and caters to
the same programmer folks. But you don't show what that design is. The OP
didn't imply there was one.

~~~
apta
D, Rust, C#, ML, Delphi, etc.

~~~
jstimpfle
I haven't used all the other ones, but "Delphi" really made me crack up. I
used it for 6 months before I quit my job. It's a mess, junk after junk added
on a pile of junk, only surpassing the junk-adding badness of C++ by also
having this broken standard library that's somehow required to write any type
of software (because the simplest thing, C-like pointers, exist but are really
not nice to work with).

The task that lead to my decision to quit was to write a data serialization
systems for datastructure that I didn't know in which version of junk they
were expressed, by interfacing with the broken standard library. The
serialization system was to replace another serialization system that somehow
didn't quite work. No wonder, it was broken code, and I couldn't see a way to
write non-broken code to solve an unsolveable problem.

What's nice about Delphi is that the compiler is quick and it has a beginner-
friendly IDE with a visual GUI creator (no selling point for me). That's about
it, AFAICT.

~~~
apta
I was referring to generics systems that don't suck.

------
bunderbunder
I realize I'm not the audience here, but still -- As someone who isn't
terribly familiar with Go, most of what I'm seeing in this article is the
shady corners I can't see into.

The generics one, I've seen plenty of pixels spilled on, and I've come to
accept that I won'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's so great about its module system?

~~~
throwaway415415
Exactly. If you can't get rid of your favorite paradigm (which seems to be
generics for some reason in this thread) then I guess stick with the language
you are already using and don't try to wrap your head around other languages?

------
Foober223
An algorithm or data structure may be applied to various types of data.
There'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.

Go puts it's head in the sand and and handles the problem like it's 1970 with
the "void pointer" way of thinking. That's fine if you'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.

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.

~~~
jstimpfle
I don't speak from experience with Go, but a simple type assertion at an
interface boundary should normally not be noticeable at all. Where performance
matters, there you usually do not have parameteric types or similar. Have you
measured anything?

------
alexandercrohde
I don't understand how not having generics is at all acceptable. But maybe
that's because I come from a functional programming perspective.

~~~
andy_ppp
It's because Go is a brutalist hipster language - simplicity above utility.
Forget a lack of generics, you don't even get proper error messages.

~~~
jstimpfle
Is "hipster" a label you would like to apply to e.g. Russ Cox? Maybe the
designers of Go have design goals that are different than what you have in
mind. Maybe they don't see it as "simplicity vs utility", but more as "utility
through simplicity".

~~~
andy_ppp
"Hipster: A person who follows the latest trends and fashions, especially
those regarded as being _outside the cultural mainstream_."

Yep. Go is a hipster language, even if you don't like it.

~~~
jstimpfle
"The latest trends"? To me Go is particularly conservative.

I don't feel like arguing over a word that has become essentially meaningless
over time, but I think you have seriously misunderstood what _hipster_ means
or was once supposed to mean. Either that, or you don't really know about Go
and are just judging it by its marketing's design aesthetics (Gopher, fonts
etc. following a trendy googley style).

~~~
andy_ppp
Go is trendy and Go is outside of the mainstream in it's minimalist design
choices. Are you trying to say that Go is not in fashion and has made
mainstream language choices?

I think you're just upset about the choice of the word hipster but as with all
words it's a shortcut to actual meaning. It was intended with a hint of
playfulness and not intended to make you feel bad, even if you don't agree
with the choice of word.

~~~
jstimpfle
> Are you trying to say that Go is not in fashion and has made mainstream
> language choices?

I can't even understand how you can be constructing such a statement. "In
fashion" and "mainstream" are pretty synonymous to me. In consequence, the
statement is contradictory. Hence, No, I am clearly not trying to say that.

> I think you're just upset about the choice of the word hipster

No I'm saying that the team behind Go is just really considerate and
principled. They don't follow all the latest fads, simply because those fads
are the reason why so many other languages suck and projects written in them
become giant unmaintainable hairballs.

They are _engineers_ (label them conservative if you like). Not hipsters.

------
atilaneves
> they feel that generics are a good fit for this language

Or that it's ludicrous for any statically typed language to not have generics.

> It’s small and simple, and every detail is carefully thought out > Nearly
> all of Go’s features are bulletproof > my opinion are among the best
> implementations of their concepts in our entire industry

Uh huh.

> 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

Or it could be one-liner: "easy concurrency".

> simplicity and elegance are now the principles I optimize for

Doesn't everyone who cares? The problem is that elegance and simplicity, like
beauty, are in the eye of the beholder.

To me, generics increase elegance and simplicity.

> 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

So pretend it's the 70s and use void* (interface{})?

------
smolder
The way he describes Go'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 _the one true language_.

------
tebruno99
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.

~~~
aikah
The problem is the solution is often to make the compiler ignore types all
together and use interface {} wholesale, then test interfaces with type
assertions.

If Go had a least unions, it would be a bit less painful to describe a range
of finite types while keeping things strictly typed in functions and methods.
Unions are a limited form of type polymorphism in a garbage collected
language.

~~~
weberc2
I'd be disappointed if Go went for unions instead of full-on Rust-like enums,
but I agree with your general point.

------
andy_ppp
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.

~~~
candiodari
They have macros. Sort of. Search "go generate".

~~~
aikah
This isn't a macro language. It relies on an external program that the
developer needs to write himself at first place. "go generate" just
facilitates the execution of a third party program. It does nothing more, and
doesn't even do it automatically when compiling a program.

