3 ms·

It's true language changes don't seem to have been prioritized until recently. But the last big thing (package management) was probably long overdue. Before t

It's true language changes don't seem to have been prioritized until recently. But the last big thing (package management) was probably long overdue. Before that it was mostly improving the compiler, runtime, and standard library. There's all sorts of interesting niche languages that aren't used because those ecosystem things aren't as robust... Also I see stuff like they should just use "perfectly fine existing paradigms from other languages" on HN all the time. But from the very beginning they said that Java-style generics were undesirable (due to overhead) and C++/Rust style were also undesirable due to code size. In the end, the proposal does not choose either system and tries to enable the compiler to make trade-offs in between. It seems most inspired by CLU and a proposed future C++ feature... I genuinely don't understand why HN views this as an easy thing to just copy in, unless they view the design goals as unnecessary to begin with... I definitely think it will be convenient to have type safety for collections that are not lists or hashmaps/sets. I also think it's convenient to have multiple return values and slices (so every list api accepts sub-lists without copying). Overall, I didn't find Go to be tremendously less convenient than Java or C#... I'm kind of curious what kind of software HN is working on, where Go is so much worse than the alternatives.

pjmlp 8y ago
As you say " It seems most inspired by CLU". Do you happen to know by chance when CLU was created?
- throwaway34241 8y ago
  To quote the entire sentence, "It seems most inspired by CLU and a proposed future C++ feature". Note that Stroustrup proposed C++ concepts in 2003, and they still don't exist in C++, but they might be standardized by 2020. Also note that CLU also didn't implement compile time specialization at all which is one of their core design requirements (for performance). I don't think this is the particular prior art most of the "generics are easy" people are referring to, anyway. It's maybe accurate to say that the Go team could have fairly easily done Java-style parameterized types (implemented via boxing everything like Java) and they chose not to do that. They chose not to do that mainly for performance reasons (and the hit would probably be worse in Go than Java since it's more value type oriented and doesn't have a JIT). A lot of people here seem to value expressiveness above everything, but I think it's unsurprising that that Go didn't want to make those performance compromises, since it's trying to be an alternative to Java and C++ at Google-scale.
  - pjmlp 8y ago
    Java-style parameterized types is not the only option and they have acknowledged that they ignored us for a long time. "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#designs-in-other-languages https://go.googlesource.com/proposal/+/master/design/go2draf... As for being an alternative to Java and C++ at Google-scale, all their major projects, with exception of Kubernetes, are mostly based on Java and C++.
    - throwaway34241 8y ago
      I'm not disputing that there's prior art for their design like C++ concepts (although C++ doesn't do run-time generics and CLU didn't do compile time). I'm just disputing the view designing and implementing it will be easy, like they could have just thrown it in there without taking substantial time away from other priorities and/or delaying the language, so anything short of providing generics day 1 is disingenuous or maybe ignorant. Take this interview with Chris Lattner (of Swift) for comparison: http://atp.fm/205-chris-lattner-interview-transcript/ http://atp.fm/205-chris-lattner-interview-transcript/. Some of the things they want in the future but just haven't had time for (more reflection, core networking libraries, etc) are things Go provided day one. If you look at the recommended way of dealing with JSON in Swift for example, it's full of boilerplate. Go also provided green threads and GC which probably adds some implementation work compared to languages that don't have them. They've also prioritized language stability to a much greater degree than Swift. I don't know to what degree Go has succeeded with its mission inside Google/Youtube (for new projects, obviously they aren't going to re-write everything), but it seems like the Go team has more resources than it did before, which might be part of why they're more comfortable tackling major changes like this now. If language designers didn't want to make nuanced trade offs in the design space between compile time, performance, code size, ease of use/complexity etc and sweat all the implementation details I'm sure they could operate a lot faster. Javascript might have already cornered that niche though.

pjmlp 8y ago

As you say " It seems most inspired by CLU". Do you happen to know by chance when CLU was created?

throwaway34241 8y ago
To quote the entire sentence, "It seems most inspired by CLU and a proposed future C++ feature". Note that Stroustrup proposed C++ concepts in 2003, and they still don't exist in C++, but they might be standardized by 2020. Also note that CLU also didn't implement compile time specialization at all which is one of their core design requirements (for performance). I don't think this is the particular prior art most of the "generics are easy" people are referring to, anyway. It's maybe accurate to say that the Go team could have fairly easily done Java-style parameterized types (implemented via boxing everything like Java) and they chose not to do that. They chose not to do that mainly for performance reasons (and the hit would probably be worse in Go than Java since it's more value type oriented and doesn't have a JIT). A lot of people here seem to value expressiveness above everything, but I think it's unsurprising that that Go didn't want to make those performance compromises, since it's trying to be an alternative to Java and C++ at Google-scale.
- pjmlp 8y ago
  Java-style parameterized types is not the only option and they have acknowledged that they ignored us for a long time. "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#designs-in-other-languages https://go.googlesource.com/proposal/+/master/design/go2draf... As for being an alternative to Java and C++ at Google-scale, all their major projects, with exception of Kubernetes, are mostly based on Java and C++.
  - throwaway34241 8y ago
    I'm not disputing that there's prior art for their design like C++ concepts (although C++ doesn't do run-time generics and CLU didn't do compile time). I'm just disputing the view designing and implementing it will be easy, like they could have just thrown it in there without taking substantial time away from other priorities and/or delaying the language, so anything short of providing generics day 1 is disingenuous or maybe ignorant. Take this interview with Chris Lattner (of Swift) for comparison: http://atp.fm/205-chris-lattner-interview-transcript/ http://atp.fm/205-chris-lattner-interview-transcript/. Some of the things they want in the future but just haven't had time for (more reflection, core networking libraries, etc) are things Go provided day one. If you look at the recommended way of dealing with JSON in Swift for example, it's full of boilerplate. Go also provided green threads and GC which probably adds some implementation work compared to languages that don't have them. They've also prioritized language stability to a much greater degree than Swift. I don't know to what degree Go has succeeded with its mission inside Google/Youtube (for new projects, obviously they aren't going to re-write everything), but it seems like the Go team has more resources than it did before, which might be part of why they're more comfortable tackling major changes like this now. If language designers didn't want to make nuanced trade offs in the design space between compile time, performance, code size, ease of use/complexity etc and sweat all the implementation details I'm sure they could operate a lot faster. Javascript might have already cornered that niche though.