Don't get me wrong, I enjoy writing code in Go, Rust, and TS. But my god, Go literally is a pain in the ass every time I want to do something that isn't a map reduce problem. And even for map reduce problems it's annoying due to lack of generics.
Maybe generics will finally give Go something that every other language has. A strong, useful, standard library for collections.
> This is one of the reasons so many people are calling for Go to get generics.
Even if it gets them at some point, the language still needs support for algebraic types, which not surprisingly, the golang authors "don't see it as useful".
>"Oh, I need a vector of maps from a pair of Foo to a set of Bar"
This is a fun example since you can do that in Go now, as it comes with a generic vector (essentially) and map :D
I think that was the design decision, 95% of generics use cases are covered by having growable arrays and maps, so why clutter the language with generics.
I like generics, I think most people who dislike them are coming from C++ templates, which has downsides that don't exist in newer generics systems (such as in C# or F#)
> However, without generics, Go’s type system can only offer so much
I was reading the whole article waiting to see this line, and the article did not disappoint. This is still the main reason I will stick with Rust or Crystal (depending on the use-case) and avoid Go if I can for the foreseeable future. Generics are just a must these days for non-trivial software projects. It's a shame too because Go has so much promise in other respects.
> [...] but because its authors and community is incapable of admitting problems when they see them.
What evidence did you see to make this conclusion? I can only find from their FAQ[0]:
"Generics may well be added at some point. We don't feel an urgency for them, although we understand some programmers do.
Generics are convenient but they come at a cost in complexity in the type system and run-time. We haven't yet found a design that gives value proportionate to the complexity, although we continue to think about it. Meanwhile, Go's built-in maps and slices, plus the ability to use the empty interface to construct containers (with explicit unboxing) mean in many cases it is possible to write code that does what generics would enable, if less smoothly.
> Basically they dismissed every implemented approach, despite generics obviously working in other systems.
But working at a price. And Go isn't willing to pay the price (especially in terms of compile time). If Go ever adds generics, it will be with a new approach that doesn't blow up compile times.
> The Golang team was not extolling the lack of generics in Go as a point of pride.
Indeed, they're extolling the simplicity one gets. To quote their FAQ:
> Why does Go not have generic types?
> Generics are convenient but they come at a cost in complexity in the type system and run-time. We haven't yet found a design that gives value proportionate to the complexity, although we continue to think about it.
If they can find a way to add it that doesn't take away the simplicity they enjoy, all the better.
> As far as it being "simpler" that Go doesn't have generics, I've never understood this conclusion.
That's if you require generic objects. There are reasonable ways to write code that largely avoids them (namely, by specializing your code on specific, standard types for the given problem). Whether this is reasonable for your circumstance depends on your circumstance and the way you like to solve problems.
> So far despite all the people lamenting the lack of generics in Go I've yet to have seen someone propose a viable (eg: backwards compatible, realistic to achieve with the current compilers and runtime, etc.) way to implement, nevermind someone who's produced a prototype.
I clearly stated that Go is lacking on the generics front. The cliff is forced, rigid OOP and complicated tool-chains.
> Personally I couldn't live without generics, and would never choose a language that doesn't have them
I'm kind of confused here. Yes, Go needs generics, but are generics even that key a feature? I mean how often do you have to define a generic type, and how much copying does it really take? Is it a hassle? Of course. But at the end of the matter, Go much, much better when it comes to combining expressibility, efficiency, and simplicity then many of the other options available today.
> Go's opinion about generics has always been that it should have them, but finding the right expertise to implement them in a non-ridiculous way has been a struggle. They are marked for inclusion in coming versions (2.0).
The fact that people can claim that C#, Java, Scala, Kotlin, Haskell, Rust, Swift have "ridiculous" implementations of generics sounds like a very bad excuse.
What? One of the reasons I love Go is it doesn't have generics, and I say that after 7 years spent in Java. People don't like to be forced to think differently because they're lazy and can't motivate themself to change the way they think and program.
Go is different, Rust is different, people throw shit on Go because it's not Java or C# or Python, because it doesn't do what they would like it to do, not because it doesn't have generics. Sure, occasionally generics would be useful, but it's not a reason to hate a language.
>A huge variety of other languages have successfully implemented generics
Completely irrelevant; the argument isn't "generics are hard [full stop]". The argument is "generics are hard" AND "we don't know Go's niche well enough to commit to any specific approach".
>Generics is the single biggest language feature absent in Go. It’s often missed by newcomers to Go. But it’s more of a type-system mechanism. It’s unclear if it’s an essential language feature.
Oh, it's clear by now. Though "essential" is a weasel word -- in a way nothing is essential in the sense you can do it all with assembler too.
>Generics are incredibly complex in both semantics and implementation. There are considerable trade-offs to consider, such as do you want a larger binary vs. slower binary vs. larger source code.
Unless I use them, I get none of those downsides. And when I need them, I now have to implement support for my types manually, which results in larger source code anyway.
And "larger source code" hasn't been a problem since 1980.
>Language features without competition: goroutines, interfaces, defer (now in Swift)
Those have been around in several other languages... Hardly "without competition".
>Tools without competition: fast compiler
It's fast because it's not doing much. And there are several compilers that are fast too.
> There's a lot of cognitive overhead in pervasively-parameterized codebases
The lack of generics leads to occasional excesses in code generation (-cough- k8s/client-go -cough-) which can be even worse. I suspect that observing this in practice lead the Go core team to be more receptive to generics proposals.
Generics nothing more or less than a safety feature. Right now code that would use generics instead use the empty interface instead, which is effectively opting out of the type system entirely.
I'm personally ambivalent on whether go adds generics or not but framing a lack of generics as a safety feature is the most absurd thing I've heard today.
Well put. Though I would add that though generics are convenient, they are not as needed nearly often enough to be a crucial missing feature in a language. Yes, it's uncanny to copy here and there, and certainly, the Go team should try and resolve this. But from where I'm standing this (i.e. generics) is one of the very few fair criticisms of Go which can be leveled from the Java, C++ or C# communities.
So simple it can't do Object.keys()
Don't get me wrong, I enjoy writing code in Go, Rust, and TS. But my god, Go literally is a pain in the ass every time I want to do something that isn't a map reduce problem. And even for map reduce problems it's annoying due to lack of generics.
Maybe generics will finally give Go something that every other language has. A strong, useful, standard library for collections.
reply