7 ms·

Go really should have learned 2 lessons from Java 5: 1. People will eventually want generics 2. Retrofitting generics onto an existing language is hard and lea

Go really should have learned 2 lessons from Java 5: 1. People will eventually want generics 2. Retrofitting generics onto an existing language is hard and leads to unusual problems (edit: I'm glad Go is doing this, but...Java learned this in 2004.)

mikelward 6y ago
If this follows the monomorphic approach described in Featherweight Go [1][2], they will at least avoid problems caused by type erasure and avoid too much runtime overhead. 1. https://arxiv.org/abs/2005.11710 https://arxiv.org/abs/2005.11710 2. https://news.ycombinator.com/item?id=23368453 https://news.ycombinator.com/item?id=23368453
- jasonhansel 6y ago
  But then you have compile time overhead (an issue Rust and C++ have faced). One of Go's design goals was to have very fast compile times, which might be in doubt if they take the monomorphization approach.
  - deleted 6y ago
    [deleted]
  - entha_saava 6y ago
    Is rust's slow compile time because of poor LLVM IR generation or just because monomorphization? D has generics and compiles fast. I guess Nim compile times are okay, too..
gowld 6y ago
Are you saying Go should have not launched in 2009, but shout have waited 10 years until generics were ready?
- jeremyjh 6y ago
  If they made it a priority they could have shipped in 2010 with generics. There is no new art in this design.
  - AaronFriel 6y ago
    Go has the unfortunate circumstances of its birth being before widespread recognition of the value of generics and better type systems. Those ideas existed in many languages, and in the PL community, and they were starting to take hold in other languages, but the consensus for most software engineers was that "sum types" are hard and "generics" aren't necessary and the type system should stay out of the way. I think TypeScript, Scala, Kotlin, C#, and various others I forget now proved that these things weren't a fad and could yield significant gains in productivity and code correctness. Had Rob Pike been more forward looking (or hired Anders Hejlsberg or Guy Steele to design the language) or dipped further into the PL research, he might have been so bold himself. I don't think anyone can fault him for it, these were niche and minority views in 2010 and may not even be in the majority today. I think at the same time, we see what happens when a new language has large corporate backing in more recent years. Swift more closely resembles Rust than Go in terms of its type system.
    - plorkyeran 6y ago
      "Generics are useful" was not even remotely a niche view in 2010. That was already 6 years after Java got them, and the lack of generics in Go was a common criticism from day one.
      - fooster 6y ago
        This is such a bullshit argument. Why is it that any go post on hacker news pulls out all the tropes. Lack of exceptions. Lack of generics. Would generics make go a better a language? Maybe. Does the lack of generics make go objectively bad? Hell no! I've had a long career coding in C, C++, Java, Lisp, Python, Ruby... you name it I've done it. Go is my favorite most productive language by far for solving typical backend issues. My least favorite? Java by a HUGE mile.
kjksf 6y ago
There's is a design document for Go generics. If you see "unusual problems" with the design, then tell us what they are. Otherwise it's just shallow pattern matching "Java added generics late, they had problems, Go added generics late therefore they'll have problems too". Counterexample: C# added generics late and it's perfectly fine design. The reason Go team is not rushing to implement generics is precisely so that the design makes sense, in the context of Go. Over the years Ian Taylor wrote several designs for generics, all of which were found to not be good enough. They are doing it the right way: not shipping until they have a good design and they didn't have good design when Go launched.
Ericson2314 6y ago
Go is just Java repeated as farce. The histories are almost identical with ~10 years lag. We all called this when Go was created, too.
- cies 6y ago
  Just without the "VM".
  - Ericson2314 6y ago
    JAVA -> Go + WASM is conservation of MEMEs? :D (Not to disparage WASM, which has some nice ideas both on the technical and ecosystem level.)
neop1x 6y ago
Thanks but I don't need another Java. Enjoy your full Java and keep Go doing things go-way. :)

mikelward 6y ago

If this follows the monomorphic approach described in Featherweight Go [1][2], they will at least avoid problems caused by type erasure and avoid too much runtime overhead. 1. https://arxiv.org/abs/2005.11710 https://arxiv.org/abs/2005.11710 2. https://news.ycombinator.com/item?id=23368453 https://news.ycombinator.com/item?id=23368453

jasonhansel 6y ago
But then you have compile time overhead (an issue Rust and C++ have faced). One of Go's design goals was to have very fast compile times, which might be in doubt if they take the monomorphization approach.
- deleted 6y ago
  [deleted]
- entha_saava 6y ago
  Is rust's slow compile time because of poor LLVM IR generation or just because monomorphization? D has generics and compiles fast. I guess Nim compile times are okay, too..

gowld 6y ago

Are you saying Go should have not launched in 2009, but shout have waited 10 years until generics were ready?

jeremyjh 6y ago
If they made it a priority they could have shipped in 2010 with generics. There is no new art in this design.
- AaronFriel 6y ago
  Go has the unfortunate circumstances of its birth being before widespread recognition of the value of generics and better type systems. Those ideas existed in many languages, and in the PL community, and they were starting to take hold in other languages, but the consensus for most software engineers was that "sum types" are hard and "generics" aren't necessary and the type system should stay out of the way. I think TypeScript, Scala, Kotlin, C#, and various others I forget now proved that these things weren't a fad and could yield significant gains in productivity and code correctness. Had Rob Pike been more forward looking (or hired Anders Hejlsberg or Guy Steele to design the language) or dipped further into the PL research, he might have been so bold himself. I don't think anyone can fault him for it, these were niche and minority views in 2010 and may not even be in the majority today. I think at the same time, we see what happens when a new language has large corporate backing in more recent years. Swift more closely resembles Rust than Go in terms of its type system.
  - plorkyeran 6y ago
    "Generics are useful" was not even remotely a niche view in 2010. That was already 6 years after Java got them, and the lack of generics in Go was a common criticism from day one.
    - fooster 6y ago
      This is such a bullshit argument. Why is it that any go post on hacker news pulls out all the tropes. Lack of exceptions. Lack of generics. Would generics make go a better a language? Maybe. Does the lack of generics make go objectively bad? Hell no! I've had a long career coding in C, C++, Java, Lisp, Python, Ruby... you name it I've done it. Go is my favorite most productive language by far for solving typical backend issues. My least favorite? Java by a HUGE mile.

kjksf 6y ago

There's is a design document for Go generics. If you see "unusual problems" with the design, then tell us what they are. Otherwise it's just shallow pattern matching "Java added generics late, they had problems, Go added generics late therefore they'll have problems too". Counterexample: C# added generics late and it's perfectly fine design. The reason Go team is not rushing to implement generics is precisely so that the design makes sense, in the context of Go. Over the years Ian Taylor wrote several designs for generics, all of which were found to not be good enough. They are doing it the right way: not shipping until they have a good design and they didn't have good design when Go launched.

Ericson2314 6y ago

Go is just Java repeated as farce. The histories are almost identical with ~10 years lag. We all called this when Go was created, too.

cies 6y ago
Just without the "VM".
- Ericson2314 6y ago
  JAVA -> Go + WASM is conservation of MEMEs? :D (Not to disparage WASM, which has some nice ideas both on the technical and ecosystem level.)

neop1x 6y ago

Thanks but I don't need another Java. Enjoy your full Java and keep Go doing things go-way. :)