Comment by bpodgursky | Hacker News Reader

Comment by bpodgursky | Hacker News Reader

I just don't want to hear about Golang generics any more, until they are in a usable beta. It's been years, and while I'm confident that there are some maintainers who really for real want to add it... it's hard to shake the feeling that the talk is going to go around in circles, hoping devs give up and forget about it.

It's like sending a project into an environmental review. It sounds constructive, until you realize it's a nice way of black-holeing the project.

I really apologize if I'm being unfair to the (team?) working on this, but... it's been years. Generics have been around for decades. It's important to get it right, but Golang is by design _not that complicated_. There really doesn't need to be wild new R&D to figure out how to pack generics into a programming language.

</salt> rant over. For now.

Edit: And seriously, it's 100% fine if the answer is "we thought about it, and decided not to do it." It's just frustrating being strung along with constant design proposals, iterating on syntax, and then... back to more design proposals. Just make a choice (or a veto), and go with it.

I suspect the problem is that Generics bring you face to face with the Liskov Substitution Principle. For most of us it's just a good idea, and then you try to do generics and all of a sudden it begins to become the law.

So you try to layer it onto a language like Java and you discover that an ArrayList of Integer is not interchangeable with an ArrayList of Number because you can stick a Double in one of them and blow up everyone expecting only whole numbers.

I've long suspected that you either have to put Generics in at the beginning or prepare for decades of complaints about your workarounds. And getting stuck in committee for a very, very, very long time.

> So [...] you discover that an ArrayList of Integer is not interchangeable with an ArrayList of Number because you can stick a Double in one of them and blow up everyone expecting only whole numbers.

Is this really an issue with Java's type system though? If you get an ArrayList<Number> and you assume that it contains only whole numbers, that's on you.

FWIW, my personal opinion is that erasure is better than templated generics for most use cases. Even when it comes to performance: a good JIT should be able to specialize generic code that end up on a hot path. Erasure does cause some issues with reflection and value types, but I think that it provides a better foundation to start from when designing a type system.

Then again, I am quite a fan of Rust's generics and dyn/impl {Trait}. Might be worth doing something similar where you have two separate generic systems: one for boxed values, and one for unboxed values.

> Is this really an issue with Java's type system though? If you get an ArrayList<Number> and you assume that it contains only whole numbers, that's on you.

The point is that you have an List<Integer> are you allowed to call a function that takes an List<Number>? The answer is effectively "yes it should be allowed" if its not mutating the List (all Integers can be safely read as Numbers) but no if the List is mutable (you can't handle the fact that it might insert a non-Integer number into the Integer-only List).

This is less LSP and more the co/contravariance of container types, which is its own special hell.

The hell stems from inheritance, which is just syntactic sugar over composition. And a very unhealthy kind of sugar as that: problems with co- and contravariance, problems with copying, the need for redundant type declarations. And inheritance doesn't guarantee autofulfillment of the Liskov principle, either. One might even wonder why inheritance is needed at all in a language. Go and Rust are certainly fine without it.

One of the humblest smart guys I worked with years ago would try to convince me over lunch that the Next Big Language would have syntactic sugar to make composition as easy as inheritance. I think in part because I had intimated that I was trying to create a language (narrator: he didn't. It went nowhere)

There are a couple languages that have added something like this in the interim, but nobody seems to have made it an idiomatic thing. Which is a shame, because I still think I might like to work in the world he dreamed up.

You get a little more composition in languages like NodeJS for the very pragmatic reason that inheritance, at least historically, was not seamless and hence had a high degree of friction.

Ah, just like VB did with COM....

With the possible exception of a couple of convenience methods, you can model collections (independently) as a source and sink for elements and avoid having to rely on variance at all. But we treat them as a storehouse of shared state... which ought to be our first warning that things are about to go sideways.

Lots of people get confused by variance. They shouldn’t, but insisting in what people should or shouldn’t do rather than working with how they are is a sure route to frustration.

It isn't a problem if you design an API by following the rules (PECS). Use wildcards for method parameters when this is the desired behavior. It is not hard to do things right.

https://howtodoinjava.com/java/generics/java-generics-what-i...

void doThings(List<? extends Number> values){ ... }

This is catered for.

> because you can stick a Double in one of them and blow up everyone expecting only whole numbers.

Generics in Java are invariant, so what you're describing will not work.

Now imagine being the dev who keeps making proposals and working diligently at the problem only to have countless ideas and proposals shot down for one reason or another. Ian Lance Taylor is persistent if nothing else and I'm hoping his hard work pays off with this proposal.

This is why we’re going round in circles. There’s been significant effort invested in generics for Go, so the team aren’t willing to veto the idea. But they’re not willing to accept a proposal either.

The team is actively working on it. Why would they invest work in something they don't want.

Working on it _internally_, in depths of google sea. There is not much to follow that progress other than following small bubbles from that submarine raising to the surface here and there... (imho, ymmv)

Not everything has to be followed at every step. When they have a relevant update on the draft design they publish it, gather feedback, improve, and so on.

People want to follow it closely. And after that fiasco with "new" error comparison handling proposal I cannot blame them.

Go is an opinionated language, IMO its developers need to make a decision about this. Either get on and add generics (as in one of the existing proposals), or (given the language’s success in its current form) explicitly say “no generics, the fundamentals of the language are frozen”.

At this point, I tend to agree. The original creators are quite fine with "Me but not for Thee" so generics simply aren't in scope. The only way generics will come in scope is if Go starts losing enough popularity that the creators need to do something. That isn't likely to happen for a while.

To the users, if you want generics, WHY DID YOU CHOOSE GO? There are plenty of other options nowadays.

Ken Thompson and Rob Pike are mostly our not at all involved with Go anymore. They are 2/3 of the original creators. It’s different people making the decisions now

>Ken Thompson and Rob Pike are mostly our not at all involved with Go anymore.

I'm fine with Ken, but if Rob is not involved, things might progress faster. I have a big impression he was the impediment in most cases...

>To the users, if you want generics, WHY DID YOU CHOOSE GO? There are plenty of other options nowadays.

But I didn't choose Go and I do want generics.

>To the users, if you want generics, WHY DID YOU CHOOSE GO?

My employer chose it. So there's that.

Reply on news.ycombinator.com