[latronic_notron]

> "You can't ship software in a language without generics!"

Isn't this is a strawman? Most arguments in favor of generics in this thread and elsewhere are well informed and people just want safer code...

As you said, you can already have generics using unsafe solutions. Some built-in types have generics. Most people just want this type safety.

interface{} does feel like a temporary and clunky solution for people used to generics.

> And lastly, one thing that you can't really appreciate without trying Go--the lack of generics/expressiveness and general simplicity of the language largely means everyone writes the same boring, predictable code, which means you can pretty much pick up any project on GitHub or your own code from years ago and understand it almost immediately.

I don't get this argument. Why are generics more complicated than other features? Has this hypothesis been tested?

I personally find that using generics is way easier and faster than interface{}, Reflection or code generation. Also simpler and less error-prone than features from other languages like inheritance, operator overloading and unbounded coroutines.

[zeveb]

People always go on about type safety, but in practice it normally doesn't matter. I have an instance of a data structure; I put in items of type Foo; I remove items of type interface{} and immediately cast them to type Foo, and life goes on. Sometimes, I might need to put in items of different types, and then I use a type switch. It's not a big deal, nothing panics, I get on with my life.

Yes, there's a class of programs for which this is not the case, and for which I might want some sort of fancier guarantees. But those don't tend to be the sort of programs I write. My hobby projects are in Common Lisp; I used to professionally program in Python and JavaScript (for my sins) — Go is strictly better than those in the static-typing department.

Would I like generics? Sure, I can see how they'd be nice. But I remember how templates in C++ turned into something nasty, and I've written Java professionally too: I like how clean & simple Go is. I can write code, then be done with it, and come back a year or two later and not be mystified. It's a decent little language for getting stuff done.

[je42]

You should read the typescript threads, where people want types to make their code more bug free.

[weberc2]

> Isn't this is a strawman? Most arguments in favor of generics in this thread and elsewhere are well informed and people just want safer code... > As you said, you can already have generics using unsafe solutions. Some built-in types have generics. Most people just want this type safety. > interface{} does feel like a temporary and clunky solution for people used to generics.

It's not a strawman; I run into this tired argument too often, so I wanted to call it out to avoid the predictable digression. There is a strong case for generics and I empathize with "`interface{}` is clunky..."; I just want a debate that recognizes the tradeoffs.

> I don't get this argument. Why are generics more complicated than other features? Has this hypothesis been tested?

I don't think I made the argument that "generics are more complicated than other features". My argument was that Go code is boring and predictable (consistent). It stands to reason that boring, consistent code is easier to read and understand than novel and/or mixed-paradigm code. Generics increase expressiveness, which pretty much by definition means fewer rails to keep code consistent. I'm not arguing that Go's current feature set strikes an optimal balance between expressiveness and consistency for all problems; however, it does do a pretty good job and we should count the costs as well as the gains when considering a new feature.

[latronic_notron]

I personally find most implementations of generics to be in the class of "boring and predictable".

I agree that C++ template meta programming might be a bit too much for Go (or for any language, for that matter), but generics as they are implemented in C# and Java are pretty cool and simple.

IMO, if generics were to be ever added in Go they should just be a simple replacement for some uses of interface{} and code generation. I mean, the complexity is already there... why wouldn't generics simplify those use cases?

[weberc2]

I'm talking about code written in Go, not the implementation of any particular feature. Generics would simplify those cases, but they also remove the rails that keeps Go code pretty consistent relative to Java or C#.

For example, in Go, there is no functional-vs-imperative conundrum; it's only imperative. And I appreciate that there are multi-paradigm languages like C# and Java that allow for both (better for experimenting with new patterns and paradigms); however, I also appreciate that there are languages like Go that take a more conservative opinion, and I think this is more practical for software development.

[latronic_notron]

> they also remove the rails that keeps Go code pretty consistent

But why? There's nothing in generics that would make Go non-consistent. In fact, there's already generics in Go in Array/Map/Slice, and they're not inconsistent with the rest of the language at all.

> For example, in Go, there is no functional-vs-imperative conundrum; it's only imperative

Why would generics break that? Funcional programming and type-safety/polymorphism are orthogonal concepts. IIRC, generics were introduced in Barbara Liskov's CLU language, which is imperative.

It sounds to me that most people advocating generics in Go are having a pragmatic/utilitarian approach, while people against it are opposing it from a purely ideological standpoint not grounded in either theory or pragmatism.

[weberc2]

> It sounds to me that most people advocating generics in Go are having a pragmatic/utilitarian approach, while people against it are opposing it from a purely ideological standpoint not grounded in either theory or pragmatism.

And it sounds to me like you're working rather hard to misunderstand me/my-opinion and paint me an idealogue. :)

Even if I were making a positive assertion like "generics costs more than it gains", that would be a pragmatic viewpoint even if it's incorrect. But I'm not even making that assertion, I'm merely unsure and would like to be persuaded otherwise (and I find people with experience on both sides of the fence to be more credible than those without that experience).

> Why would generics break that?

Because "generics" as a feature suffices to support multi-paradigm programming. It explodes the solution space, creating many solutions for problems that Go's type system is perfectly capable of dealing with (~97% of the problem space in practice according to my experience) while permitting new solutions that Go's type system must currently punt on (~3%). We should be able to roughly agree on this even if we disagree about the degree to which multiple solutions is a problem relative to the advantage of the additional type safety.

[latronic_notron]

> And it sounds to me like you're working rather hard to misunderstand me/my-opinion and paint me an idealogue. :)

That's fair! I'm really sorry I typed that, it was completely uncalled for and I wasn't referring to you specifically!

> Because "generics" as a feature suffices to support multi-paradigm programming.

I don't really agree with that. Despite being widely used in functional languages, they aren't really a "functional" thing, as much as static typing is.

In fact, I'd argue that Go already has a feature that is much more important and representative of funcional programming than anything else: higher order functions. [1] With higher order functions (and recursion!) you can implement pretty much anything functional.

Generics don't really allow for much more than something like interface{} can already give. The problem is that interface{} comes with both runtime performance and type-safety penalties. Generics could fix that and help programmers arrive at better/safer practices, IMO.

My point is: with generics the language could be much simpler and we'd have to rely less on (IMO) complicated/unsafe features like Reflection and interface{}.

[1] http://aquaraga.github.io/functional-programming/golang/2016...

[j16sdiz]

Go use a duck typing system, many of the generic use case can be solved using interface elegantly..

For the rest... Yes, it is very ugly. But the standard generic does not fit very well with go type system, so....

Luckily, go is very simple. Even ugly bit are not hard to understand.

[latronic_notron]

> But the standard generic does not fit very well with go type system, so....

Why not? Generics in Arrays/Maps/Slices fit perfectly in the language, and don't feel weird at all in Go.

[jstimpfle]

> Arrays/Maps/Slices

They are widely used data structures and so, in the opinion of the Go creators, justified separate specialized implementations in the Go compiler. In other words, there isn't actually a Generics system in the language (I don't actually know this, correct me if I'm wrong). For various reasons. There are quite a few talks and design docs from Rob Pike and Russ Cox if you look for them.

[latronic_notron]

Nope. They are generics, aka parametric polymorphism. And they fit perfectly within Go.

And generics aren't just for abstract data structures, there are other uses as well.

[jstimpfle]

I think you've misunderstood what I said. For example here: https://golang.org/src/go/parser/parser.go you can clearly see how e.g. token.MAP is a special case.

    func (p *parser) tryIdentOrType() ast.Expr {
        ....
        case token.MAP:
            return p.parseMapType()

There is a special-cased function parseMapType() function in the Go parser. This isn't generic at all. I mean even the syntax (as in func foo(bar map[String]int) ...) does not seem to be generic at all.

Yes, you can use any type as keys and values. But that's a far cry from an abstract system that lets the user define any parameterizable data type. And that's for good reason: By hardcoding just the most important parameterizable data types, the problems that an abstract system would bring can be avoided.

[latronic_notron]

Yes, I'm aware that they're a special case. What I mean is that this is exactly what is traditionally called "generics" or "parametric polymorphism" in PL literature. Go's Map/Array/Slice called "predefined generic types" in some literature.

[jstimpfle]

> Isn't this is a strawman? Most arguments in favor of generics in this thread and elsewhere are well informed and people just want safer code...

As a C programmer (which doesn't have generics either) I can't recall the last time where that additional safety was being missed. Whenever I fed the wrong argument in for a void* parameter (which is rare enough), the program crashed on the first try and the problem is obvious. Plus, Go even has runtime type checking to catch this sort of problem with 100% probability at runtime (I think - I'm not a Go programmer).

So I don't think there's a valid problem here.

Maybe the more serious problem is that people want to be able to quickly say "I want a Fibonacci-Tree<K,V> for types K and V"?

[latronic_notron]

> Whenever I fed the wrong argument in for a void* parameter (which is rare enough), the program crashed on the first try and the problem is obvious.

Except when it isn't. Except when it crashes in production. I believe this is the kind of situation people are trying to avoid with type safety...

> Maybe the more serious problem is that people want to be able to quickly say "I want a Fibonacci-Tree<K,V> for types K and V"?

That's uncalled for, isn't it? There's a lot of non-toy problems solved elegantly and pragmatically using generics. I personally enjoy how Entity Framework uses it.

[jstimpfle]

> Except when it isn't.

Yes, but by far more important are bounds checks. Go has bounds checks. As a C programmer I don't get to enjoy them (I get to write simpler, non-GCed, object-cruft-free software in exchange). Out of bounds reads and writes consume far far more of my time compared to void pointers. (And even OOB are not that time consuming).

> That's uncalled for, isn't it? There's a lot of non-toy problems...

Yes, the Fibonacci was a bad example (couldn't use Map because Go has that). It wasn't meant in a mean way.

[latronic_notron]

> Yes, but by far more important are bounds checks.

Sure, but I'm failing to see why having other checks isn't important. I mean, generics aren't hard to use... They're way easier to grasp than Channels (a great feature), and easier to use daily than go generate. I dunno.

[jstimpfle]

Many things are important, and most things require making tradeoffs. When a thing that is only a little bit important prevents something else that is more important (albeit more subtle and requiring experience to see), it's probably better not to choose the first thing.

Generics are abstract. They lead to bad error messages. They make the language more complex. They require syntactical support as well as special magic under the hood. Look for various resources by Russ Cox and Rob Pike (and maybe other Go designers). For example https://go.googlesource.com/proposal/+/master/design/go2draf...

[latronic_notron]

I'm familiar with that article, and it got me excited for a while, but it's about compiler implementation, and it doesn't really have much to do with the current discussion, other than rationalizing the opposition for the feature.

About your other points: nope, generics wouldn't remove simplicity in the language itself. They would mostly legitimize with type-safety certain idioms that are already present in current Golang code. And the terrible error messages of C++ templates are not really a good example. There are much better languages now when it comes to generics.

I suggest that maybe you try looking into other legitimate uses of generics? The Fibonacci-Tree<K,V> example you gave earlier is unrealistic, and the other example being thrown around here, STL, is too complex... There are lots of legitimate reasons for someone wanting generics in a language, and nobody is advocating for them out of bad faith, or wishing to kill a nice language with feature bloat :(