3 ms·

I think you're making my case for me here :) Yes, Go reached maturity faster than Rust (despite its first release occurring later – one of the many benefits of

by foldr 3y ago

I think you're making my case for me here :) Yes, Go reached maturity faster than Rust (despite its first release occurring later – one of the many benefits of simplicity), and the lack of generics doesn't seem to have hurt its adoption. Another victory for Worse is Better.

littlestymaar 3y ago
> Go reached maturity faster than Rust (despite its first release occurring later – one of the many benefits of simplicity) Rust started as a research language by a PL guy working on his free time, he wasn't even suspecting his work would end up becoming mainstream. Rust only became somewhat serious several years after Go was released and used in production at Google. If you count Graydon's first Rust publication, you may as well count all of plan9 as part of Go's history! (Or how about using Go's repository first commit[0] if we're being facetious) Also, implementing proper generics should have been straightforward from the start for Go, given that it was already mainstream in multiple programming languages back then (including the super mainstream Java and C#, with different approach). But Go was made by people who believe syntax highlighting is useless, of course they decided against generics… [0] https://github.com/golang/go/commit/7d7c6a97f815e9279d08cfaea7d5efb5e90695a8 https://github.com/golang/go/commit/7d7c6a97f815e9279d08cfae...
- foldr 3y ago
  It would have been straightforward to copy an existing approach to generics (though I suspect that this is a usage of the word ‘straightforward’ that has currency only among people who’ve never written a compiler), but I’m glad they waited and did something better that had a proper theoretical foundation. If they’d naively added generic types to Go from the beginning, you can bet there would have been all kinds of interesting unintended consequences, as there were in the case of Java.
  - pjmlp 3y ago
    "They are likely the two most difficult parts of any design for parametric polymorphism. 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... CLU was invented in 1976, C++ concepts were proposed in 2005!
    - foldr 3y ago
      If you take a step back here, the Go team acknowledged their biases and lack of in-depth knowledge in the domain, consulted with domain experts, and eventually settled on exactly the kind of generics system that you apparently approve of. Could they have done this earlier, in principle? Sure. But at what cost? What other balls would have been dropped? I think they were absolutely right to focus on aspects of the language design and tooling that they were confident about. Go is all the better for it. It's the polar opposite of a language designed to appeal to programming language enthusiasts; and well, that shows in the reactions. By all means use Rust. I use Rust sometimes too, and it has its advantages over Go. Personally, I find generics in Go an occasional convenience and missed them only a little before 1.18.

by foldr 3y ago

littlestymaar 3y ago

> Go reached maturity faster than Rust (despite its first release occurring later – one of the many benefits of simplicity) Rust started as a research language by a PL guy working on his free time, he wasn't even suspecting his work would end up becoming mainstream. Rust only became somewhat serious several years after Go was released and used in production at Google. If you count Graydon's first Rust publication, you may as well count all of plan9 as part of Go's history! (Or how about using Go's repository first commit[0] if we're being facetious) Also, implementing proper generics should have been straightforward from the start for Go, given that it was already mainstream in multiple programming languages back then (including the super mainstream Java and C#, with different approach). But Go was made by people who believe syntax highlighting is useless, of course they decided against generics… [0] https://github.com/golang/go/commit/7d7c6a97f815e9279d08cfaea7d5efb5e90695a8 https://github.com/golang/go/commit/7d7c6a97f815e9279d08cfae...

foldr 3y ago
It would have been straightforward to copy an existing approach to generics (though I suspect that this is a usage of the word ‘straightforward’ that has currency only among people who’ve never written a compiler), but I’m glad they waited and did something better that had a proper theoretical foundation. If they’d naively added generic types to Go from the beginning, you can bet there would have been all kinds of interesting unintended consequences, as there were in the case of Java.
- pjmlp 3y ago
  "They are likely the two most difficult parts of any design for parametric polymorphism. 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... CLU was invented in 1976, C++ concepts were proposed in 2005!
  - foldr 3y ago
    If you take a step back here, the Go team acknowledged their biases and lack of in-depth knowledge in the domain, consulted with domain experts, and eventually settled on exactly the kind of generics system that you apparently approve of. Could they have done this earlier, in principle? Sure. But at what cost? What other balls would have been dropped? I think they were absolutely right to focus on aspects of the language design and tooling that they were confident about. Go is all the better for it. It's the polar opposite of a language designed to appeal to programming language enthusiasts; and well, that shows in the reactions. By all means use Rust. I use Rust sometimes too, and it has its advantages over Go. Personally, I find generics in Go an occasional convenience and missed them only a little before 1.18.