Hacker News Reader

Comment by shadowmint | Hacker News Reader

> My point is that if Go is not going to have a story for templated types, then we need to own it, just like Haskell programmers own their decisions.

> This isn’t simply a case of saying “nope, sorry, no generics for Go 2.0, maybe in another 5 years”, but a more fundamental statement that they are not something that will be implemented in Go because we believe there is a better way to solve the underlying problem.

ffs. tldr; yes. Add generics.

Come on, the feedback from the community has been overwhelming.

If we were going to 'own' not having generics, we wouldn't be having this conversation.

There's a disconnect here, clearly, between the community and what the community wants, and what the language makers and designers want.

I think what Dave is advocating here is basically the 'status quo' from golang 1.0 (ie. we'll never have generics).

That hasn't worked.

Lets not do it again.

View on HN

Is it what the Go community wants or is it what a lot of people who don't actually write much Go want?

It can be hard to tell, which is why they came up with a process and are asking for experience reports:

https://github.com/golang/go/wiki/ExperienceReports

so, they're asking people who didn't use go because of generics to provide experience reports on the specific kind of problems they encountered when writing go ???

I write or use generic code in every single of my projects. i don't need to start coding in go ( which i did) to understand what i'll miss. i did my share of void* casting in C and i know how much it sucks.

This is an old problem. Everybody knows what the use is and what the benefits are. They tried to show the world that they were wrong and they failed to convince that people could get away without this feature. Now all they need is to get over it and start implementing something to fill that gap.

They are asking people who extensively use Go to help collecting cases where generics would be useful in the context of real world Go programs. So instead of cargo-culting a random generics design from a different language or some theoretical reasoning, they want to make sure to enhance the language in a way that actually solve real-world problems in programs written in Go.

Wouldn't it imply that they're happy with the current audience of the language, and don't wish to extend it ?

nothing wrong with that, though.

> Wouldn't it imply that they're happy with the current audience of the language, and don't wish to extend it ?

You're assuming that people who have some degree of interest in generics and aren't Go users right now will somehow and for some reason decide to avoid Go just because it lacks generics.

It's a silly assumption.

well not really. I'm saying it could be interesting to ask people that decided not to use go , the reason they choose not to, in order to expand their user base.

> well not really. I'm saying it could be interesting to ask people that decided not to use go

You're assuming that these people have anything relevant to say, particularly as they present irrational arguments to justify their fatwa on a programming language.

Meanwhile, those who are interested in exploring the language and are interested in putting it to work aren't wasting their time with irrational stances on a minor technical detail.

I use Go quite a lot, and I agree with their "irrational arguments". It seems quite dishonest to pretend that anyone who doesn't use Go because they found it too restrictive to be "wasting their time with irrational stances". It's also quite close-minded.

You're right that most Go developers aren't going to go out of their way to write a 5-page dissertation about how generics would help solve a problem they worked around, but that's not a justification for not including generics. The fact you have to write orders of magnitude more code in order to work around a lack of generics is ridiculous, and I find it frustrating every time I have to do it. Will I eventually crack and write a series of blog posts that just rant about every single fucking problem I have with Go? Maybe. But it seems quite unreasonable to only want reviews which effectively must be of the form of a coherent rant.

To offer a counter point: I dislike the idea of "I write generic code". I say this because it is one of the prime calling-cards of the over-abstraction, which IMO is one of the biggest (and most harmful) self-inflicted injuries in programming right now.

Honestly, IMO, 9 times out of 10 the places that developers use templated-types in order to "write generic code", it is an over-abstraction. The generics end up adding nothing but source-code complexity. I often wonder if the only reason generics get used in some situations is because the standard lib uses them.

end-user code probably doesn't need generic. The issue is much more relevant for librairie and framework developpers though.

I'm not going to speak for the whole Go community, but most people I've talked to in the community has eventually agreed that a lack of generics make code harder to write (after giving them some examples and showing them how other languages made this problem much simpler). That wiki page is quite a bad way of asking for feedback for two reasons:

1. It ignores the fact that most people who encounter a language problem will rather just work around it and make uglier code "because they have to" than to write a several-page dissertation on why generics would've solved their problem. Heck, some programmers haven't used generics before and don't realise that your code can become much simpler if you use them correctly. When I first found out that I could define a trait on a generic container type in Rust, I was massively surprised and realised how much unnecessary Go code I'd written recently because this one feature was missing.

2. It assumes that the programmers who complained about all of these issues in Go 1.0 several years ago are still sticking around, and can be bothered to reiterate the same arguments they made all that time ago (and were ignored all that time ago). Asking for more comments may sound like a "nice thing to do", but if you already burned the goodwill of the larger programming community with similar stalling tactics, then people are going to be less likely to be willing to help again.

I will give you some examples that have personally bitten me. The most frustrating part is that Go _does_ have generics, except that they are restricted to only be used by builtin types. make, new, len, cap, etc are all generic functions for the builtin collection types. But here are some examples:

1. Collection types are effectively impossible to implement usefully. []T will not be promoted to []I if T is a type that implements an interface I. This requires creating a new slice in memory and doing a noop cast (the same applies to arrays and maps). As a result, creating a generic sort implementation won't work. Yes, Go has a "sort implementation"[1] but rather than requiring something like []Ordinal you have have the _slice type_ implement Swap and Compare. Just look at how bare the container package is (and note that they require you to implement all of the core features of the container yourself). In a language with generics such as Rust (or even Java) this interface would be considered ridiculous, but in Go it's the only way of giving some kind of generic functionality (even though it's not actually generic in any sense of the word -- you have to implement all of the common code manually even if it is structurally identical).

2. Everything that wants to be generic in some sense devolves into using interface{} to represent "something that I will use reflection to introspect". However, the reflection API is far from good, and there are cases where because there is an interface{} type in the way, you cannot mutate something that you would be able to mutate if you didn't have define things as interface{} (an *interface{} doesn't allow you to modify the underlying type through reflection as far as I could tell). Admittedly, I have done some very dodgy stuff with Go's reflection API, but that doesn't mean it's a good API.

3. The workarounds for generics have reached the point where some people created tools that generate code that implements a "generic type" by manually generating the code for each type. This is something that compilers for languages that have generics do _automatically_, but in the Go universe you have people so desperate for generics that they are re-implementing something that should be a compiler feature as part of their build pipeline. I personally don't use any of those tools, because after trying several of them I realised that they make your code even harder to understand because all of the type information is generated in a way that obscures what you're actually trying to do.

The only reason I write Go code is because (for some misguided and other justified-at-the-time reasons), the majority of the container ecosystem is written in Go and it's not reasonable to switch to anything else. A bunch of other developers and I have been looking at switching over to Rust, but there is a lot of inertia in keeping everything in one language. But if you saw what fairly horrific shit Kubernetes had to do in order to emulate generics with reflection, you would likely want to run for the hills.

[1]: https://golang.org/pkg/sort/ [2]: https://golang.org/pkg/container/

Reply on news.ycombinator.com