6 ms·

Parametric polymorphism is a real world issue. The fact that it wasn't checked off indicates to me that they are of the opinion that it's not as important. It'

Parametric polymorphism is a real world issue. The fact that it wasn't checked off indicates to me that they are of the opinion that it's not as important. It's ok to have this opinion, I just disagree with it. I do agree that it's important to think it through, I do not agree that the language should be brought to 1.0 without it.

nnq 7y ago
> Parametric polymorphism is a real world issue. ...what in the world makes you thing that? I love parametric polymorphism, but nothing stops you from writing the most complex computer programs you can imagine without it.
- masklinn 7y ago
  > ...what in the world makes you thing that? Go literally special-cases generic builtins because they couldn't be arsed to properly implement it but knew nobody would accept completely untyped core collections.
  - foldr 7y ago
    Go does not have generic arrays any more than C does. You cannot e.g. write a generic Go function to reverse an array. You seem to be conflating type-parameterized collections with generics. You can use generics to implement type-parameterized collections, but it doesn't really make sense to think of type-parameterized collections as a form of generics unless you can actually abstract over the type parameters (which you can't in Go).
    - masklinn 7y ago
      > Go does not have generic arrays any more than C does. Go does have generic collections, and generic functions operating on these collections. > You cannot e.g. write a generic Go function to reverse an array. You can if you're part of the core team and implement them as builtins. Go doesn't have userland generics, because users of Go are peons who can't be trusted with sharp implements. > which you can't in Go Because the core Go team assumes and asserts users of Go should not and can not be trusted with anything more complex than a wooden cube with rounded edges large enough that it can't fit in their mouths.
      - foldr 7y ago
        According to this usage, C has generic functions because you can, e.g., index into an array of ints. The whole point of generics is that the language makes available some form of abstraction over types. Go does not have this feature. It has some built-in operators that can operate on multiple types. Most languages have this. The arithmetic operators in C, for example, can take operands of many different types. This is not "generics". >Because the core Go team assumes and asserts users of Go should not and can not be trusted with anything more complex than a wooden cube with rounded edges large enough that it can't fit in their mouths. This can't really be the right explanation given that generics are now being added to the language. In any case, this kind of mean-spirited speculation about people's motives is borderline trolling, IMO. The Go team have publicly stated their reasons for not (initially) putting generics in the language. Unless you have some inside info suggesting that they're lying, I'd refrain from saying this kind of thing.
        masklinn 7y ago
        > The whole point of generics is that the language makes available some form of abstraction over types. Go does not have this feature. Go absolutely has this feature. Just not for you as a user of the language. > It has some built-in operators that can operate on multiple types. Go has multiple builtin functions which abstract over type parameters e.g. close() can operate on any chan, append() or copy() can operate on any slice. They are not operators (symbolic or keyword). > Most languages have this. The arithmetic operators in C, for example, can take operands of many different types. This is not "generics". It's overloading, +(int, int) and +(double, double) are separate functions under the same symbol. It's an orthogonal feature, so much so that there are plenty of languages which do have userland generics and don't have overloading. > This can't really be the right explanation given that generics are now being added to the language. The core team has been saying they're considering the feature / issue pretty much since the language was first released. You'll have to excuse me if I don't hold my breath.
        foldr 7y ago
        >Go absolutely has this feature. Just not for you as a user of the language. That seems like a roundabout way of saying that it doesn't have the feature. >It's overloading You could just as well regard Go's close, append, copy etc. as overloaded. > The core team has been saying they're considering the feature / issue pretty much since the language was first released. You'll have to excuse me if I don't hold my breath. They've come out with a specific generics proposal. I'm not sure why you would think that they're not serious about implementing it.
- calcifer 7y ago
  > but nothing stops you from writing the most complex computer programs you can imagine without it. Sure, you can do that with punch cards as well, but there is a reason we've collectively moved beyond them.
B-Con 7y ago
This is the general point though. Community pressure would have produced generics under a different leadership model that wants to check the box. Whether this is the right decision for this specific issue is a different story. But the fact that they aren't checking boxes for the sake of it is evidence of this style WAI.
- chrisweekly 7y ago
  WAI?
  - alach11 7y ago
    I would guess Working As Intended.
  - deleted 7y ago
    [deleted]
xyproto 7y ago
Parametric polymorphism is a tool to solve real world issues with. It is not unthinkable that there could exist other programmatic tools that would be able to solve the same real world issues.
_ph_ 7y ago
But that is exactly the point - you would have added the best proposal available to the language vs. waiting till all issues are worked out with generics. Go 1.0 has been released 7 years ago, in that time a ton of happy Go users were able to use Go as it is. All the discussions on generics clearly show, that the Go team is interested adding them, but that all proposals so far had distinct shortcomings. Personally, I am very happy with what Go offers today, I would rather keep a small and simple language, which allows me to concentrate on doing work, rather than trying to keep up with features added to the language. I am not even sure, I want generics to be added to the language, until they come up with a really great concept which maintains the simplicity of the language.
- pjmlp 7y ago
  ML (1973) and CLU (1975) introduced generics to the world, followed by a myriad of approaches to implement them across multiple languages, so plenty of time.
  - _ph_ 7y ago
    No one claimed, that languages with generics don't exist. But if you follow the discussion about generics in Go, Russ Cox did a thorough discussion of all the proposals on the table and why they would mean giving up some of the core traits of the Go language. As soon anyone suggests an implementation not colliding with the core Go goals, the Go team probably would pick it up quickly. Or phrased it in another way: with all the years of experience on generics, they still got them wrong when implementing generics for Java, e.g. with the type erasure.
    - pjmlp 7y ago
      Not at all, he focused on how Java and C++ do it, and later on the Go 2.0 proposal admited that they were a bit closed minded to look for how other language implementations work. "In retrospect, we were biased too much by experience with C++ without concepts and Java generics. We would have been well-served to spend more time with CLU and C++ concepts earlier." https://go.googlesource.com/proposal/+/master/design/go2draft-generics-overview.md https://go.googlesource.com/proposal/+/master/design/go2draf...
throwaway34241 7y ago
I'm not sure what GP meant by real world issues, but they do have some specific constraints that they want their implementation of generics to achieve, one of the core team members tried to nail down the details over a period of years but there were issues with the previous proposals before the latest one. So I don't think the issue is parametric polymorphism or not, it's more about things like keeping fast compile times, avoiding boxing value types, etc.
baby 7y ago
It would objectively have made Golang harder to read. Can we agree on that? People tend to abuse generics.
- erik_seaberg 7y ago
  Uses of https://golang.org/pkg/sync/#Map https://golang.org/pkg/sync/#Map are objectively harder to read than if they allowed a library to implement a type that conforms to builtin map[K]V. Instead you have to learn method names and cast return values, and builtin maps don't even support those methods.
  - baby 7y ago
    Let’s agree to disagree. Maybe you’re used to reading generics after years of doing it.
karmakaze 7y ago
The one thing that I do like about Go not having generics early on is that it became a language for lower-level work with many good libraries. I wouldn't quite call it a systems language like they like to say but I like its positioning which filled a void. Now when Go 2 gets generics it will be used for all kinds of applications and frameworks, which is fine but isn't really filling a void. I expect the ergonomics (e.g. wicked fast compiles to single binary) to be better than current app dev langs. I stopped using Go and look foward to trying it again. Even then I don't think it will be one of my favorites and likely used for smaller work. Long-term I want Pony to succeed. Medium term I'll take Kotlin, Elixir, or Dart.

nnq 7y ago

> Parametric polymorphism is a real world issue. ...what in the world makes you thing that? I love parametric polymorphism, but nothing stops you from writing the most complex computer programs you can imagine without it.

masklinn 7y ago
> ...what in the world makes you thing that? Go literally special-cases generic builtins because they couldn't be arsed to properly implement it but knew nobody would accept completely untyped core collections.
- foldr 7y ago
  Go does not have generic arrays any more than C does. You cannot e.g. write a generic Go function to reverse an array. You seem to be conflating type-parameterized collections with generics. You can use generics to implement type-parameterized collections, but it doesn't really make sense to think of type-parameterized collections as a form of generics unless you can actually abstract over the type parameters (which you can't in Go).
  - masklinn 7y ago
    > Go does not have generic arrays any more than C does. Go does have generic collections, and generic functions operating on these collections. > You cannot e.g. write a generic Go function to reverse an array. You can if you're part of the core team and implement them as builtins. Go doesn't have userland generics, because users of Go are peons who can't be trusted with sharp implements. > which you can't in Go Because the core Go team assumes and asserts users of Go should not and can not be trusted with anything more complex than a wooden cube with rounded edges large enough that it can't fit in their mouths.
    - foldr 7y ago
      According to this usage, C has generic functions because you can, e.g., index into an array of ints. The whole point of generics is that the language makes available some form of abstraction over types. Go does not have this feature. It has some built-in operators that can operate on multiple types. Most languages have this. The arithmetic operators in C, for example, can take operands of many different types. This is not "generics". >Because the core Go team assumes and asserts users of Go should not and can not be trusted with anything more complex than a wooden cube with rounded edges large enough that it can't fit in their mouths. This can't really be the right explanation given that generics are now being added to the language. In any case, this kind of mean-spirited speculation about people's motives is borderline trolling, IMO. The Go team have publicly stated their reasons for not (initially) putting generics in the language. Unless you have some inside info suggesting that they're lying, I'd refrain from saying this kind of thing.
      - masklinn 7y ago
        > The whole point of generics is that the language makes available some form of abstraction over types. Go does not have this feature. Go absolutely has this feature. Just not for you as a user of the language. > It has some built-in operators that can operate on multiple types. Go has multiple builtin functions which abstract over type parameters e.g. close() can operate on any chan, append() or copy() can operate on any slice. They are not operators (symbolic or keyword). > Most languages have this. The arithmetic operators in C, for example, can take operands of many different types. This is not "generics". It's overloading, +(int, int) and +(double, double) are separate functions under the same symbol. It's an orthogonal feature, so much so that there are plenty of languages which do have userland generics and don't have overloading. > This can't really be the right explanation given that generics are now being added to the language. The core team has been saying they're considering the feature / issue pretty much since the language was first released. You'll have to excuse me if I don't hold my breath.
        foldr 7y ago
        >Go absolutely has this feature. Just not for you as a user of the language. That seems like a roundabout way of saying that it doesn't have the feature. >It's overloading You could just as well regard Go's close, append, copy etc. as overloaded. > The core team has been saying they're considering the feature / issue pretty much since the language was first released. You'll have to excuse me if I don't hold my breath. They've come out with a specific generics proposal. I'm not sure why you would think that they're not serious about implementing it.
calcifer 7y ago
> but nothing stops you from writing the most complex computer programs you can imagine without it. Sure, you can do that with punch cards as well, but there is a reason we've collectively moved beyond them.

B-Con 7y ago

This is the general point though. Community pressure would have produced generics under a different leadership model that wants to check the box. Whether this is the right decision for this specific issue is a different story. But the fact that they aren't checking boxes for the sake of it is evidence of this style WAI.

chrisweekly 7y ago
WAI?
- alach11 7y ago
  I would guess Working As Intended.
- deleted 7y ago
  [deleted]

xyproto 7y ago

Parametric polymorphism is a tool to solve real world issues with. It is not unthinkable that there could exist other programmatic tools that would be able to solve the same real world issues.

_ph_ 7y ago

But that is exactly the point - you would have added the best proposal available to the language vs. waiting till all issues are worked out with generics. Go 1.0 has been released 7 years ago, in that time a ton of happy Go users were able to use Go as it is. All the discussions on generics clearly show, that the Go team is interested adding them, but that all proposals so far had distinct shortcomings. Personally, I am very happy with what Go offers today, I would rather keep a small and simple language, which allows me to concentrate on doing work, rather than trying to keep up with features added to the language. I am not even sure, I want generics to be added to the language, until they come up with a really great concept which maintains the simplicity of the language.

pjmlp 7y ago
ML (1973) and CLU (1975) introduced generics to the world, followed by a myriad of approaches to implement them across multiple languages, so plenty of time.
- _ph_ 7y ago
  No one claimed, that languages with generics don't exist. But if you follow the discussion about generics in Go, Russ Cox did a thorough discussion of all the proposals on the table and why they would mean giving up some of the core traits of the Go language. As soon anyone suggests an implementation not colliding with the core Go goals, the Go team probably would pick it up quickly. Or phrased it in another way: with all the years of experience on generics, they still got them wrong when implementing generics for Java, e.g. with the type erasure.
  - pjmlp 7y ago
    Not at all, he focused on how Java and C++ do it, and later on the Go 2.0 proposal admited that they were a bit closed minded to look for how other language implementations work. "In retrospect, we were biased too much by experience with C++ without concepts and Java generics. We would have been well-served to spend more time with CLU and C++ concepts earlier." https://go.googlesource.com/proposal/+/master/design/go2draft-generics-overview.md https://go.googlesource.com/proposal/+/master/design/go2draf...

throwaway34241 7y ago

I'm not sure what GP meant by real world issues, but they do have some specific constraints that they want their implementation of generics to achieve, one of the core team members tried to nail down the details over a period of years but there were issues with the previous proposals before the latest one. So I don't think the issue is parametric polymorphism or not, it's more about things like keeping fast compile times, avoiding boxing value types, etc.

baby 7y ago

It would objectively have made Golang harder to read. Can we agree on that? People tend to abuse generics.

erik_seaberg 7y ago
Uses of https://golang.org/pkg/sync/#Map https://golang.org/pkg/sync/#Map are objectively harder to read than if they allowed a library to implement a type that conforms to builtin map[K]V. Instead you have to learn method names and cast return values, and builtin maps don't even support those methods.
- baby 7y ago
  Let’s agree to disagree. Maybe you’re used to reading generics after years of doing it.

karmakaze 7y ago

The one thing that I do like about Go not having generics early on is that it became a language for lower-level work with many good libraries. I wouldn't quite call it a systems language like they like to say but I like its positioning which filled a void. Now when Go 2 gets generics it will be used for all kinds of applications and frameworks, which is fine but isn't really filling a void. I expect the ergonomics (e.g. wicked fast compiles to single binary) to be better than current app dev langs. I stopped using Go and look foward to trying it again. Even then I don't think it will be one of my favorites and likely used for smaller work. Long-term I want Pony to succeed. Medium term I'll take Kotlin, Elixir, or Dart.