6 ms·

> I don't really see how that is at all praiseworthy: C# and Java already did that exact thing. You know, in sports, when someone manages to do something only

> I don't really see how that is at all praiseworthy: C# and Java already did that exact thing. You know, in sports, when someone manages to do something only two other athletes have managed before they usually still get praised for it. I don't know if this situation is comparable to that, but my point is that I also don't see how C# and Java doing this before inherently would make this less of an achievement. Perhaps we haven't been giving those languages the praise they deserve for doing that too.

shakow 5y ago
You know, in sports, if you finally can complete the basics known for 5 decades after years of training, no one will praise you.
- shakezula 5y ago
  Arguing that generics are in "the basics" is a little disingenuous, don't you think? Go has been wildly successful without generics, and the designers of the language were quite intentional and opinionated in leaving them out.
  - pjmlp 5y ago
    The basics appeared into the scene via CLI and ML in 1976/78. Plenty of time. There were also plenty of successful languages without generics in the last century, that doesn't mean we should keep designing them.
    - xh-dude 5y ago
      What frustrates me a bit about this argument is that interfaces really do offer a tool to solve problems around dispatch and polymorphism. Like a lot of things in Go there are lots of opinions and tradeoffs that can’t or can’t easily be revisited by someone using the language, but it’s a very different argument to say “I don’t like the tools the language provides” than “the language doesn’t provide x, y, z”. IMHO there are convincing arguments that Go needs x, y, z (or: prefer another language if you need x, y, z). A good example of one of these that is being addressed would be priority queues. Doing them via interfaces was always possible - there’s a whole std lib package for them. Generics will be better. But looking at the pre-/post-generic ways of doing priority queues confirms and emphasizes, rather than negates, the utility of interfaces as a way of structuring code. It’s still opinionated and I think it’s fair to argue about alternatives but it’s absolutely not the case that some large class of reasonable problems was entirely ignored or forgotten.
      - pjmlp 5y ago
        Java pre-1.5, or Oberon derived languages, Objective-C pre-generics, C++ARM, we oldies know how it was.
  - shakow 5y ago
    > Arguing that generics are in "the basics" is a little disingenuous, don't you think? Not really. Type polymorphism exists since the 70's, it still blows my mind that people consider that they are ‶too hard to understand for developers″, or that ‶their implementation is not very clear to language designers″. > Go has been wildly successful without generics JS have been wildly successful despite its many fundamental flaws, success is not an indicator of intrinsic quality.
Zababa 5y ago
> You know, in sports, when someone manages to do something only two other athletes have managed before they usually still get praised for it. You're talking about it like it's a time in 100m or something, while many people seem to see it as "taking less than 30 seconds to get 5 apple out of a barrel of water with your mouth, hands tied behind the back, blindfolded". Cool, but why didn't you release the generics from the beginning, especially when Java and C# added them?
masklinn 5y ago
> You know, in sports, when someone manages to do something only two other athletes have managed before they usually still get praised for it. You know, in sports, if you kept straddle-jumping until the 80s before finally transitioning to the fosbury like everyone told you for more than a decade, you wouldn't get praised for it. > I don't know if this situation is comparable to that, but my point is that I also don't see how C# and Java doing this before inherently would make this less of an achievement. Because they demonstrated it was quite reasonably feasible before Go even existed. And also because, again, Go's situation was entirely predictable and self-inflicted, and C# and Java's own transitions demonstrated it plainly.
eitland 5y ago
> You know, in sports, when someone manages to do something only two other athletes have managed before they usually still get praised for it. This is more like solving a puzzle years after others proved it solvable and after having told everyone multiple times that it didn't matter, isn't it?
- wbl 5y ago
  The Go team never said it didn't matter. They said they wanted to think through the right design.
  - eitland 5y ago
    Waiting for half a decade is a fairly effective way to tell me at least that they didn't exactly care very much about it, but it could of course be that they cared so deeply about it that they had to wait until recently before they felt it was good enough. I don't think so however and here is what Russ Cox wrote about it in 2017: > For example, I’ve been examining generics recently, but I don’t have in my mind a clear picture of the detailed, concrete problems that Go users need generics to solve. As a result, I can’t answer a design question like whether to support generic methods, which is to say methods that are parameterized separately from the receiver. (from https://go.dev/blog/toward-go2 https://go.dev/blog/toward-go2) At least the way I read the above it comes off as "doesn't matter".

shakow 5y ago

You know, in sports, if you finally can complete the basics known for 5 decades after years of training, no one will praise you.

shakezula 5y ago
Arguing that generics are in "the basics" is a little disingenuous, don't you think? Go has been wildly successful without generics, and the designers of the language were quite intentional and opinionated in leaving them out.
- pjmlp 5y ago
  The basics appeared into the scene via CLI and ML in 1976/78. Plenty of time. There were also plenty of successful languages without generics in the last century, that doesn't mean we should keep designing them.
  - xh-dude 5y ago
    What frustrates me a bit about this argument is that interfaces really do offer a tool to solve problems around dispatch and polymorphism. Like a lot of things in Go there are lots of opinions and tradeoffs that can’t or can’t easily be revisited by someone using the language, but it’s a very different argument to say “I don’t like the tools the language provides” than “the language doesn’t provide x, y, z”. IMHO there are convincing arguments that Go needs x, y, z (or: prefer another language if you need x, y, z). A good example of one of these that is being addressed would be priority queues. Doing them via interfaces was always possible - there’s a whole std lib package for them. Generics will be better. But looking at the pre-/post-generic ways of doing priority queues confirms and emphasizes, rather than negates, the utility of interfaces as a way of structuring code. It’s still opinionated and I think it’s fair to argue about alternatives but it’s absolutely not the case that some large class of reasonable problems was entirely ignored or forgotten.
    - pjmlp 5y ago
      Java pre-1.5, or Oberon derived languages, Objective-C pre-generics, C++ARM, we oldies know how it was.
- shakow 5y ago
  > Arguing that generics are in "the basics" is a little disingenuous, don't you think? Not really. Type polymorphism exists since the 70's, it still blows my mind that people consider that they are ‶too hard to understand for developers″, or that ‶their implementation is not very clear to language designers″. > Go has been wildly successful without generics JS have been wildly successful despite its many fundamental flaws, success is not an indicator of intrinsic quality.

Zababa 5y ago

> You know, in sports, when someone manages to do something only two other athletes have managed before they usually still get praised for it. You're talking about it like it's a time in 100m or something, while many people seem to see it as "taking less than 30 seconds to get 5 apple out of a barrel of water with your mouth, hands tied behind the back, blindfolded". Cool, but why didn't you release the generics from the beginning, especially when Java and C# added them?

masklinn 5y ago

> You know, in sports, when someone manages to do something only two other athletes have managed before they usually still get praised for it. You know, in sports, if you kept straddle-jumping until the 80s before finally transitioning to the fosbury like everyone told you for more than a decade, you wouldn't get praised for it. > I don't know if this situation is comparable to that, but my point is that I also don't see how C# and Java doing this before inherently would make this less of an achievement. Because they demonstrated it was quite reasonably feasible before Go even existed. And also because, again, Go's situation was entirely predictable and self-inflicted, and C# and Java's own transitions demonstrated it plainly.

eitland 5y ago

> You know, in sports, when someone manages to do something only two other athletes have managed before they usually still get praised for it. This is more like solving a puzzle years after others proved it solvable and after having told everyone multiple times that it didn't matter, isn't it?

wbl 5y ago
The Go team never said it didn't matter. They said they wanted to think through the right design.
- eitland 5y ago
  Waiting for half a decade is a fairly effective way to tell me at least that they didn't exactly care very much about it, but it could of course be that they cared so deeply about it that they had to wait until recently before they felt it was good enough. I don't think so however and here is what Russ Cox wrote about it in 2017: > For example, I’ve been examining generics recently, but I don’t have in my mind a clear picture of the detailed, concrete problems that Go users need generics to solve. As a result, I can’t answer a design question like whether to support generic methods, which is to say methods that are parameterized separately from the receiver. (from https://go.dev/blog/toward-go2 https://go.dev/blog/toward-go2) At least the way I read the above it comes off as "doesn't matter".