4 ms·

Because it's far from basic stuff when you have to consider stability guarantees.

pjmlp 5y ago
You know how to avoid those problems? By having them since the begining, it is not as other languages haven't gone through the path of bolting on generics after the fact, as an example for others to learn from.
- rubenv 5y ago
  I for one like not having things rushed in which then cannot be changed later on. Does this mean Go is perfect? Not at all. It just means I'd rather have generics late than fundamentally broken.
  - pjmlp 5y ago
    For the time we have waited already, what is a couple of years more, right? Now if that would have been part of Go 1.0....
    - can3p 5y ago
      So far I prefer this approach to any other. I know this type of discussion happens under any go submission, but still - need in generics is overrated, there a ton of code written for all sorts and purposes and scales and it works just fine. And all that without a gigantic marketing push which means that developers simply like it that way it is. Go is about compatibility, being able to control your code base and being confident about results and I'd really prefer them to take their time thinking through a non-critical feature rather then rushing it and exploring all sorts of unexpected side effects down the road.
      - pjmlp 5y ago
        Indeed, only Google paychecks, and two historical figures of UNIX and Plan 9 history, no marketing at all.
  - grumpyprole 5y ago
    "Generics" or parametric polymorphism, first appeared in the 70's. So I don't think including this with Go 1.0 would have been rushing!
    - arghwhat 5y ago
      Yeah, about that: just because the theory exists doesn't make it less work to design new elegant typesystems around them. Go actively decided against generics in the beginning to make a small and simple language. We will lose that now.
      - grumpyprole 5y ago
        As they will need to be retrofitted just like Java had to do, yes I'm sure there'll be warts. Had they been considered from the start, I'm sure it could have been much simpler.
- arghwhat 5y ago
  You mean like how Rust had async from the beginning? Oh wait. I guess we'll have to wait till 2040 for these languages to be complete before we can have a release then. The massive success Go has been suggest that their decision to start simple, without generics, was objectively a good one, even if unpopular to.somr. Heck, not even sure if it'll really be Go anymore when it ships...
  - pjmlp 5y ago
    Good idea to bring Rust into the table, async is also not fully backed and there are several use cases that will only be taken care in years to come, if at all. With incompatible runtimes. So another good example of what happens when things aren't baked on 1.0 release. If Go did not had UNIX/Plan 9 key persons and Google money attached to it, or killer projects like Docker and Kubernetes, it would have fizzled away. As it is, even those that would rather not use it, must do so, specially when we use DevOps hats from time to time.
    - tialaramex 5y ago
      But it seems like this type of "replacing stdlib features" discussion mostly evaporates for Rust. In Rust an edition changes the prelude and new code that looks the same now gets the desirable new behaviour, even though backwards compatibility is undiminished for old code. It feels like several of the Golang proposals are in the same spirit (I noticed one explicitly invoking Rust) but as hacks rather than a built-in language feature.
      - pjmlp 5y ago
        It only evaporates, because most people aren't language geeks that waste part of their life reading SIGPLAN and IEEE papers. :) Currently in Rust async/await generators discussion has been put on hold as being a hot topic, and as library writer one can't still be sure the library will properly work across all async runtimes. https://rust-lang.github.io/async-book/01_getting_started/03_state_of_async_rust.html https://rust-lang.github.io/async-book/01_getting_started/03... Same kind of 1.0 issues apply to Java, D, C#, C++,.... and they are specially bad in guest languages that take decisions on syntactic sugar for missing platform features, and when the platform adds those features, they usually end up with two ways of doing the same thing.
brabel 5y ago
I mean basic in that it's like the feature can't even be added if you don't solve that.
- arghwhat 5y ago
  Of course it can, the problem isn't writing APIs, it's rewriting old APIs that have static types to also be generic without breaking old code that rely on the static types. E.g., if you write the number constant "1" as arg to a method taking "float64", it's implicitly converted to that. If the method takes a T, you instead have an int.

You know how to avoid those problems? By having them since the begining, it is not as other languages haven't gone through the path of bolting on generics after the fact, as an example for others to learn from.

rubenv 5y ago
I for one like not having things rushed in which then cannot be changed later on. Does this mean Go is perfect? Not at all. It just means I'd rather have generics late than fundamentally broken.
- pjmlp 5y ago
  For the time we have waited already, what is a couple of years more, right? Now if that would have been part of Go 1.0....
  - can3p 5y ago
    So far I prefer this approach to any other. I know this type of discussion happens under any go submission, but still - need in generics is overrated, there a ton of code written for all sorts and purposes and scales and it works just fine. And all that without a gigantic marketing push which means that developers simply like it that way it is. Go is about compatibility, being able to control your code base and being confident about results and I'd really prefer them to take their time thinking through a non-critical feature rather then rushing it and exploring all sorts of unexpected side effects down the road.
    - pjmlp 5y ago
      Indeed, only Google paychecks, and two historical figures of UNIX and Plan 9 history, no marketing at all.
- grumpyprole 5y ago
  "Generics" or parametric polymorphism, first appeared in the 70's. So I don't think including this with Go 1.0 would have been rushing!
  - arghwhat 5y ago
    Yeah, about that: just because the theory exists doesn't make it less work to design new elegant typesystems around them. Go actively decided against generics in the beginning to make a small and simple language. We will lose that now.
    - grumpyprole 5y ago
      As they will need to be retrofitted just like Java had to do, yes I'm sure there'll be warts. Had they been considered from the start, I'm sure it could have been much simpler.
arghwhat 5y ago
You mean like how Rust had async from the beginning? Oh wait. I guess we'll have to wait till 2040 for these languages to be complete before we can have a release then. The massive success Go has been suggest that their decision to start simple, without generics, was objectively a good one, even if unpopular to.somr. Heck, not even sure if it'll really be Go anymore when it ships...
- pjmlp 5y ago
  Good idea to bring Rust into the table, async is also not fully backed and there are several use cases that will only be taken care in years to come, if at all. With incompatible runtimes. So another good example of what happens when things aren't baked on 1.0 release. If Go did not had UNIX/Plan 9 key persons and Google money attached to it, or killer projects like Docker and Kubernetes, it would have fizzled away. As it is, even those that would rather not use it, must do so, specially when we use DevOps hats from time to time.
  - tialaramex 5y ago
    But it seems like this type of "replacing stdlib features" discussion mostly evaporates for Rust. In Rust an edition changes the prelude and new code that looks the same now gets the desirable new behaviour, even though backwards compatibility is undiminished for old code. It feels like several of the Golang proposals are in the same spirit (I noticed one explicitly invoking Rust) but as hacks rather than a built-in language feature.
    - pjmlp 5y ago
      It only evaporates, because most people aren't language geeks that waste part of their life reading SIGPLAN and IEEE papers. :) Currently in Rust async/await generators discussion has been put on hold as being a hot topic, and as library writer one can't still be sure the library will properly work across all async runtimes. https://rust-lang.github.io/async-book/01_getting_started/03_state_of_async_rust.html https://rust-lang.github.io/async-book/01_getting_started/03... Same kind of 1.0 issues apply to Java, D, C#, C++,.... and they are specially bad in guest languages that take decisions on syntactic sugar for missing platform features, and when the platform adds those features, they usually end up with two ways of doing the same thing.

brabel 5y ago

I mean basic in that it's like the feature can't even be added if you don't solve that.

arghwhat 5y ago
Of course it can, the problem isn't writing APIs, it's rewriting old APIs that have static types to also be generic without breaking old code that rely on the static types. E.g., if you write the number constant "1" as arg to a method taking "float64", it's implicitly converted to that. If the method takes a T, you instead have an int.