6 ms·

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 maintai

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.

bsder 7y ago
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.
- mfer 7y ago
  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
  - coldtea 7y ago
    >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...
- jayd16 7y ago
  >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.
- coldtea 7y ago
  >To the users, if you want generics, WHY DID YOU CHOOSE GO? My employer chose it. So there's that.
pansa2 7y ago
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”.
- deleted 7y ago
  [deleted]
hinkley 7y ago
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.
- lazulicurio 7y ago
  > 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.
  - esrauch 7y ago
    > 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).
joncalhoun 7y ago
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.
- pansa2 7y ago
  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.
  - mseepgood 7y ago
    The team is actively working on it. Why would they invest work in something they don't want.
    - tandr 7y ago
      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)
      - mseepgood 7y ago
        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.
        tandr 7y ago
        People want to follow it closely. And after that fiasco with "new" error comparison handling proposal I cannot blame them.
deleted 7y ago
[deleted]

bsder 7y ago

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.

mfer 7y ago
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
- coldtea 7y ago
  >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...
jayd16 7y ago
>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.
coldtea 7y ago
>To the users, if you want generics, WHY DID YOU CHOOSE GO? My employer chose it. So there's that.

pansa2 7y ago

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

deleted 7y ago
[deleted]

hinkley 7y ago

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.

lazulicurio 7y ago
> 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.
- esrauch 7y ago
  > 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).

joncalhoun 7y ago

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.

pansa2 7y ago
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.
- mseepgood 7y ago
  The team is actively working on it. Why would they invest work in something they don't want.
  - tandr 7y ago
    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)
    - mseepgood 7y ago
      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.
      - tandr 7y ago
        People want to follow it closely. And after that fiasco with "new" error comparison handling proposal I cannot blame them.

deleted 7y ago

[deleted]