4 ms·

My recollection of the timeline is a bit different: 1. The current proposals for generics are bloated and don't fit properly with our vision for Go. 2. We wil

My recollection of the timeline is a bit different: 1. The current proposals for generics are bloated and don't fit properly with our vision for Go. 2. We will do heaps and heaps of work over many years until we get something we like. 3. Go has generics! Also, AFAIK Go is not a single-pass compiler, at least not in the way I learned about compilers.

kerkeslager 3y ago
> 1. The current proposals for generics are bloated and don't fit properly with our vision for Go. > 2. We will do heaps and heaps of work over many years until we get something we like. I suppose repeatedly suffering the pain of not having generics until you finally get enough of your community to admit generics aren't just bloat can be described as "heaps and heaps of work". ;) I'd love to hear what meaningful differences you think exist between early proposals for Go generics, and later proposals for Go generics. Or Go generics and generics which had existed in other languages for decades, for that matter. The result of this silly delay will be felt basically forever, because millions of lines of go were written with error codes, which could have been much-less error-prone option types. I'm not sure it would even be a good idea to start using option types at this point because it would create such inconsistencies in codebases. > Also, AFAIK Go is not a single-pass compiler, at least not in the way I learned about compilers. Correct! But it was single pass and that was very important because multiple passes were bloat. But multiple passes aren't bloat any more, because now Go has multiple passes and Go doesn't have the bloat of other languages. See how that works? "The past was alterable. The past never had been altered. Oceania was at war with Eurasia. Oceania had always been at war with Eurasia."
- 2h 3y ago
  > option types Go couldn't have Option before, and it cant have option now. Option is not only generic, but its also an Enum, which Go still doesn't have: https://doc.rust-lang.org/std/option/enum.Option.html https://doc.rust-lang.org/std/option/enum.Option.html so its not really clear what you mean by this.
  - alex_lav 3y ago
    Option is an enum _in Rust_. This is not universally true (or even common).
  - kerkeslager 3y ago
    https://gprivate.com/651x2 https://gprivate.com/651x2
- doctor_eval 3y ago
  Quoting 1984 when discussing the history of a programming language really detracts from any point you’re trying to make. It’s not like we’ve seen some massive regression in compiler performance. Circumstances changed, and the Go developers changed their minds. What would you do?
  - kerkeslager 3y ago
    > It’s not like we’ve seen some massive regression in compiler performance. Circumstances changed, and the Go developers changed their minds. What would you do? 1. Yes, we didn't see a massive regression in compiler performance. Which begs the question why they didn't benchmark the options to see that might be the case. 2. Circumstances didn't change. The options for how to implement generics are roughly now what they were in 2009. What we need from languages in Go's sphere, is roughly the same as well. 3. What would I have done? a) Benchmark before making claims about speed. b) Assess features from other languages to see what works and what hasn't (literally nothing about the problems with lacking generics was unforseeable--I was talking about them early on and I'm not some sort of prophet). c) Admit rejecting generics was a mistake instead of pretending they were part of the plan all along.
    - doctor_eval 3y ago
      This conversation feels like it’s in bad faith. Pike wrote in 2013 that generics were a “weakness” in Go [0]. In terms of changed circumstances, obviously something caused them to spend the time and effort to get it done. Maybe they thought modules were more important? Features don’t just magically appear, they need resourcing. The rest of your points are asinine. You mention benchmarking twice which begs the question, how did they maintain good compiler performance for all these years? Was it just luck? This feels a lot like those conversations where the winners get what they ostensibly wanted, but then they want a pound of flesh to go with it. If you don’t like Go then use something else. The world is full of wonderful programming languages. [0] https://go.dev/blog/slices https://go.dev/blog/slices
      - kerkeslager 3y ago

kerkeslager 3y ago

> 1. The current proposals for generics are bloated and don't fit properly with our vision for Go. > 2. We will do heaps and heaps of work over many years until we get something we like. I suppose repeatedly suffering the pain of not having generics until you finally get enough of your community to admit generics aren't just bloat can be described as "heaps and heaps of work". ;) I'd love to hear what meaningful differences you think exist between early proposals for Go generics, and later proposals for Go generics. Or Go generics and generics which had existed in other languages for decades, for that matter. The result of this silly delay will be felt basically forever, because millions of lines of go were written with error codes, which could have been much-less error-prone option types. I'm not sure it would even be a good idea to start using option types at this point because it would create such inconsistencies in codebases. > Also, AFAIK Go is not a single-pass compiler, at least not in the way I learned about compilers. Correct! But it was single pass and that was very important because multiple passes were bloat. But multiple passes aren't bloat any more, because now Go has multiple passes and Go doesn't have the bloat of other languages. See how that works? "The past was alterable. The past never had been altered. Oceania was at war with Eurasia. Oceania had always been at war with Eurasia."

2h 3y ago
> option types Go couldn't have Option before, and it cant have option now. Option is not only generic, but its also an Enum, which Go still doesn't have: https://doc.rust-lang.org/std/option/enum.Option.html https://doc.rust-lang.org/std/option/enum.Option.html so its not really clear what you mean by this.
- alex_lav 3y ago
  Option is an enum _in Rust_. This is not universally true (or even common).
- kerkeslager 3y ago
  https://gprivate.com/651x2 https://gprivate.com/651x2
doctor_eval 3y ago
Quoting 1984 when discussing the history of a programming language really detracts from any point you’re trying to make. It’s not like we’ve seen some massive regression in compiler performance. Circumstances changed, and the Go developers changed their minds. What would you do?
- kerkeslager 3y ago
  > It’s not like we’ve seen some massive regression in compiler performance. Circumstances changed, and the Go developers changed their minds. What would you do? 1. Yes, we didn't see a massive regression in compiler performance. Which begs the question why they didn't benchmark the options to see that might be the case. 2. Circumstances didn't change. The options for how to implement generics are roughly now what they were in 2009. What we need from languages in Go's sphere, is roughly the same as well. 3. What would I have done? a) Benchmark before making claims about speed. b) Assess features from other languages to see what works and what hasn't (literally nothing about the problems with lacking generics was unforseeable--I was talking about them early on and I'm not some sort of prophet). c) Admit rejecting generics was a mistake instead of pretending they were part of the plan all along.
  - doctor_eval 3y ago
    This conversation feels like it’s in bad faith. Pike wrote in 2013 that generics were a “weakness” in Go [0]. In terms of changed circumstances, obviously something caused them to spend the time and effort to get it done. Maybe they thought modules were more important? Features don’t just magically appear, they need resourcing. The rest of your points are asinine. You mention benchmarking twice which begs the question, how did they maintain good compiler performance for all these years? Was it just luck? This feels a lot like those conversations where the winners get what they ostensibly wanted, but then they want a pound of flesh to go with it. If you don’t like Go then use something else. The world is full of wonderful programming languages. [0] https://go.dev/blog/slices https://go.dev/blog/slices
    - kerkeslager 3y ago