5 ms·

It's just not worth using interface. And, I think, by the way, that has always been the intent from a syntax point of view. The fact that it's slow on the CPU

It's just not worth using interface. And, I think, by the way, that has always been the intent from a syntax point of view. The fact that it's slow on the CPU side is not great, but I don't think it's a major problem in the eyes of the core dev team: as far as I can tell, they do not believe that generics support as commonly envisioned is in line with go's mission. Go is the anti-lisp / anti-unix of languages; designed to not give a team of junior devs enough rope to hang themselves. If we'd like a generics proposal that would get buy-in, I think we need to adhere to that dream while we imagine working generics and propose something; I bet it would be accepted.

edgyswingset 11y ago
> designed to not give a team of junior devs enough rope to hang themselves I find this to be an utterly silly goal.
- pjmlp 11y ago
  Not really. Go doesn't fit Google hiring process "we only want CS Phds". It is also not one language that one can use on the interview exercises. So given Rob Pike's statement about an easy language for newly hires, one has to wonder where they are coming from.
timmytokyo 11y ago
Isn't that sort of like saying it's not worth using data structures other than maps and slices? In go, if you want a complex data structure you either use interfaces -- as the authors of this library did -- or you rely on some sort of code generation approach. I've followed the go team's discussion of generics for a long time now. They've always claimed they're open to proposals that fit the philosophy of the language, but they're seemingly not in any hurry to address the issue. And that's fine. But I won't pretend it isn't frustrating every time I want to build something with a non-trivial data structure. Sometimes a map or a slice just doesn't cut it.
- jshen 11y ago
  > or you rely on some sort of code generation approach. Exactly.
  - fauigerzigerk 11y ago
    Here's an idea: How about a code generator that interprets special syntax we put into source files? The code generator would run before every compile and its output would be fed straight into the compiler. An apt name might be CPP -- compile preprocessor. It might be a bit difficult to predict what the input to the compiler actually looks like after CPP has done its job. So we could restrict the kinds of things that CPP can do to make it more predictable. Let's say CPP can only substitute symbols in places where types are asked for...
    - enneff 11y ago
      So do it. If it's a great success, it might end up in the language. (Seriously.)
    - jshen 11y ago
      There are languages that have what you want. Why not use them?
- yoklov 11y ago
  Never used Go, but I've written a lot of C in the past and I think the point you're missing is that they probably intend for you to use a special purpose data structure when a map or slice doesn't fit your needs. When it's special purpose, there's no need to use generics. When I needed a generic data structure in C, I would do code generation (but only after I'd have a use for it in more than one place). The number of times I ever needed to do this for anything other than an array or hashtable is (not really surprisingly) vanishingly small. So, coming from the perspective of Go is a better C (that avoids the mistakes of C++), this choice makes sense to me. I don't necessarily think it's the right choice -- I think generally generics are useful, but tend to use generic functions in my C++ code more than generic types or containers. Might be worth noting that I work in game development, where using a library data structure isn't really considered for most things, because a special purpose one is likely able to be higher performance, due to assumptions it's able to make, operations it doesn't need to implement, etc. I guess I can see the situation where not being able to find an off the shelf generic data structure is frustrating, but I think it might be a bit overblown.
TheHydroImpulse 11y ago
sigh. Then you're back at using a more complex solution by copying and pasting generic structures and algorithms. Moreover, the idea that generics allows junior devs enough rope to "hang themselves" is preposterous. There are more than one type of generic system out there, we don't need to replicate C++ templates here. Let's not fool ourselves here. There's a difference between "we just haven't figured it out yet" and "generics doesn't fit into the vision of Go". The former attitude is perfectly acceptable. The latter is really annoying and misleading because Go does use generics -- internally.
- djhworld 11y ago
  > Let's not fool ourselves here. There's a difference between "we just haven't figured it out yet" and "generics doesn't fit into the vision of Go". The former attitude is perfectly acceptable. The latter is really annoying and misleading because Go does use generics -- internally. I think there's some misconception here, Russ Cox (one of the core Go team) posted this on HN a few weeks ago https://news.ycombinator.com/item?id=9622417 https://news.ycombinator.com/item?id=9622417
  - sambeau 11y ago
    I wonder if they've spoken to Phil Wadler. Having done Haskell and Java maybe he could get it right for Go?
threeseed 11y ago
> Go is the anti-lisp / anti-unix of languages; designed to not give a team of junior devs enough rope to hang themselves. Sounding more like a patronising, holier than thou language to me. And given that Java implemented generics (sort of) and the world didn't collapse indicates to me junior developers could handle it.
mc808 11y ago
As an outsider who has only tinkered with Go and watched most of Rob Pike's talks, my impression is "C is to Go as Java is to JavaScript" in the sense that both have a thin veneer of a familiar language on top of a fundamentally different, esoteric language. For JavaScript it's Self (prototype inheritance) and for Go it's NewSqueak (CSP). I don't think Go is really about catering to hordes of cheap junior devs or rebelling against Lisp or Unix, etc. It's (in my interpretation) a way to use channels and goroutines without overwhelming people with academic syntax. As a tool, "the right job" is small and focused on throughput and concurrency - not wiring up webs of generic abstractions. Obviously some people are also finding the language general enough to do the latter, but not without a bit of frustration. If my understanding is reasonable, people shouldn't be asking "why doesn't Go have generics," but rather "should I be using Go for this? Does this program even have one 'chan' in it?"
- justthistime_ 11y ago
  > I don't think Go is really about catering to hordes of cheap junior devs Rob Pike disagrees with you.
aikah 11y ago
> they do not believe that generics support as commonly envisioned is in line with go's mission. More like they can't add generics without breaking the backward compatibility of their mediocre type system.
- danieldk 11y ago
  More like they can't add generics without breaking the backward compatibility of their mediocre type system. Reference? Proof? (Genuinely interested.)
  - aikah 11y ago
    https://news.ycombinator.com/item?id=9622417 https://news.ycombinator.com/item?id=9622417
    - danieldk 11y ago
      I don't see anything in Russ Cox's answer that proves your statement. If there is any conclusion to that post, it is 'We can probably do it. But we are not doing it now because we are too afraid that we do it wrong, like Java.' My problem with the Go team's line of reasoning is that they always cite Java (erasure gives problems) and C++ (too long compile times), but there are many languages that have implemented parametric polymorphism nicely ages ago (C#, ML, Haskell). Sometimes I wonder if it is the lack of a person like Philip Wadler on the Go team who can hash out how to best fit generics into Go's type system.
eternalban 11y ago
> .. anti-lisp .. So is Scala. Meaningless. > .. anti-unix Actually, the issue is precisely that Rob and team are entirely too comfortable on _nix, so there is a (typical for Go) duality where (L) language is syntactically light and semantically small, (R) *nix is your IDE and piping source through source level transformers are assumed to be 2nd nature to the user. [p.s.]: (L) is motivated by making another work-day tool for the broadest range of developers and experience levels, and (R) possibly emerged as a de-facto approach given the zippy compiler and source level parsers built into the Std. lib, and comfort at that level is a virtue of a much smaller set of developers that map into (L).
aikah 11y ago
> Go is the anti-lisp / anti-unix of languages Strange, I thought Go was all about the unix philosophy ? > It's possible to use these ideas to construct something analogous to type-safe Unix pipes. https://golang.org/doc/faq https://golang.org/doc/faq > designed to not give a team of junior devs enough rope to hang themselves yeah, I thought Google only hires PhDs ... if a noob from a code bootcamp can understand generics within 6 weeks, certainly a guy from a prestigious university hand picked by google can ... please stop being insulting.

edgyswingset 11y ago

> designed to not give a team of junior devs enough rope to hang themselves I find this to be an utterly silly goal.

pjmlp 11y ago
Not really. Go doesn't fit Google hiring process "we only want CS Phds". It is also not one language that one can use on the interview exercises. So given Rob Pike's statement about an easy language for newly hires, one has to wonder where they are coming from.

timmytokyo 11y ago

Isn't that sort of like saying it's not worth using data structures other than maps and slices? In go, if you want a complex data structure you either use interfaces -- as the authors of this library did -- or you rely on some sort of code generation approach. I've followed the go team's discussion of generics for a long time now. They've always claimed they're open to proposals that fit the philosophy of the language, but they're seemingly not in any hurry to address the issue. And that's fine. But I won't pretend it isn't frustrating every time I want to build something with a non-trivial data structure. Sometimes a map or a slice just doesn't cut it.

jshen 11y ago
> or you rely on some sort of code generation approach. Exactly.
- fauigerzigerk 11y ago
  Here's an idea: How about a code generator that interprets special syntax we put into source files? The code generator would run before every compile and its output would be fed straight into the compiler. An apt name might be CPP -- compile preprocessor. It might be a bit difficult to predict what the input to the compiler actually looks like after CPP has done its job. So we could restrict the kinds of things that CPP can do to make it more predictable. Let's say CPP can only substitute symbols in places where types are asked for...
  - enneff 11y ago
    So do it. If it's a great success, it might end up in the language. (Seriously.)
  - jshen 11y ago
    There are languages that have what you want. Why not use them?
yoklov 11y ago
Never used Go, but I've written a lot of C in the past and I think the point you're missing is that they probably intend for you to use a special purpose data structure when a map or slice doesn't fit your needs. When it's special purpose, there's no need to use generics. When I needed a generic data structure in C, I would do code generation (but only after I'd have a use for it in more than one place). The number of times I ever needed to do this for anything other than an array or hashtable is (not really surprisingly) vanishingly small. So, coming from the perspective of Go is a better C (that avoids the mistakes of C++), this choice makes sense to me. I don't necessarily think it's the right choice -- I think generally generics are useful, but tend to use generic functions in my C++ code more than generic types or containers. Might be worth noting that I work in game development, where using a library data structure isn't really considered for most things, because a special purpose one is likely able to be higher performance, due to assumptions it's able to make, operations it doesn't need to implement, etc. I guess I can see the situation where not being able to find an off the shelf generic data structure is frustrating, but I think it might be a bit overblown.

TheHydroImpulse 11y ago

sigh. Then you're back at using a more complex solution by copying and pasting generic structures and algorithms. Moreover, the idea that generics allows junior devs enough rope to "hang themselves" is preposterous. There are more than one type of generic system out there, we don't need to replicate C++ templates here. Let's not fool ourselves here. There's a difference between "we just haven't figured it out yet" and "generics doesn't fit into the vision of Go". The former attitude is perfectly acceptable. The latter is really annoying and misleading because Go does use generics -- internally.

djhworld 11y ago
> Let's not fool ourselves here. There's a difference between "we just haven't figured it out yet" and "generics doesn't fit into the vision of Go". The former attitude is perfectly acceptable. The latter is really annoying and misleading because Go does use generics -- internally. I think there's some misconception here, Russ Cox (one of the core Go team) posted this on HN a few weeks ago https://news.ycombinator.com/item?id=9622417 https://news.ycombinator.com/item?id=9622417
- sambeau 11y ago
  I wonder if they've spoken to Phil Wadler. Having done Haskell and Java maybe he could get it right for Go?

threeseed 11y ago

> Go is the anti-lisp / anti-unix of languages; designed to not give a team of junior devs enough rope to hang themselves. Sounding more like a patronising, holier than thou language to me. And given that Java implemented generics (sort of) and the world didn't collapse indicates to me junior developers could handle it.

mc808 11y ago

As an outsider who has only tinkered with Go and watched most of Rob Pike's talks, my impression is "C is to Go as Java is to JavaScript" in the sense that both have a thin veneer of a familiar language on top of a fundamentally different, esoteric language. For JavaScript it's Self (prototype inheritance) and for Go it's NewSqueak (CSP). I don't think Go is really about catering to hordes of cheap junior devs or rebelling against Lisp or Unix, etc. It's (in my interpretation) a way to use channels and goroutines without overwhelming people with academic syntax. As a tool, "the right job" is small and focused on throughput and concurrency - not wiring up webs of generic abstractions. Obviously some people are also finding the language general enough to do the latter, but not without a bit of frustration. If my understanding is reasonable, people shouldn't be asking "why doesn't Go have generics," but rather "should I be using Go for this? Does this program even have one 'chan' in it?"

justthistime_ 11y ago
> I don't think Go is really about catering to hordes of cheap junior devs Rob Pike disagrees with you.

aikah 11y ago

> they do not believe that generics support as commonly envisioned is in line with go's mission. More like they can't add generics without breaking the backward compatibility of their mediocre type system.

danieldk 11y ago
More like they can't add generics without breaking the backward compatibility of their mediocre type system. Reference? Proof? (Genuinely interested.)
- aikah 11y ago
  https://news.ycombinator.com/item?id=9622417 https://news.ycombinator.com/item?id=9622417
  - danieldk 11y ago
    I don't see anything in Russ Cox's answer that proves your statement. If there is any conclusion to that post, it is 'We can probably do it. But we are not doing it now because we are too afraid that we do it wrong, like Java.' My problem with the Go team's line of reasoning is that they always cite Java (erasure gives problems) and C++ (too long compile times), but there are many languages that have implemented parametric polymorphism nicely ages ago (C#, ML, Haskell). Sometimes I wonder if it is the lack of a person like Philip Wadler on the Go team who can hash out how to best fit generics into Go's type system.

eternalban 11y ago

> .. anti-lisp .. So is Scala. Meaningless. > .. anti-unix Actually, the issue is precisely that Rob and team are entirely too comfortable on _nix, so there is a (typical for Go) duality where (L) language is syntactically light and semantically small, (R) *nix is your IDE and piping source through source level transformers are assumed to be 2nd nature to the user. [p.s.]: (L) is motivated by making another work-day tool for the broadest range of developers and experience levels, and (R) possibly emerged as a de-facto approach given the zippy compiler and source level parsers built into the Std. lib, and comfort at that level is a virtue of a much smaller set of developers that map into (L).

aikah 11y ago

> Go is the anti-lisp / anti-unix of languages Strange, I thought Go was all about the unix philosophy ? > It's possible to use these ideas to construct something analogous to type-safe Unix pipes. https://golang.org/doc/faq https://golang.org/doc/faq > designed to not give a team of junior devs enough rope to hang themselves yeah, I thought Google only hires PhDs ... if a noob from a code bootcamp can understand generics within 6 weeks, certainly a guy from a prestigious university hand picked by google can ... please stop being insulting.