7 ms·

Are there any plans to add generics yet, or do I still have to write a bunch of extra boilerplate functions in order to sort a list?

colin_mccabe 13y ago
Hi hdevlance, Generics actually have very little to do with sorting a list in Go. The example that the parent gave could be expressed in one line as "sort.Sort(sort.Reverse(sort.StringSlice(vs)));" No generics needed-- only composition. sort.Reverse is a wrapper interface which can be composed with any other sort.Interface to reverse it. It is typesafe, too-- there are no typecasts. There are cases where generics would allow us to avoid typecasts, but this is simply not one of them. In many cases, what you want can be expressed via composition of types, and often (in my opinion) in a clearer way than by using lambdas, continuations, and callbacks. I suggest learning a bit more about the language and keeping an open mind.
- hdevalence 13y ago
  If you say so -- I'm just going off of the examples given in the Go documentation on how to sort lists. If that's not the "Go-ic" way to do it, perhaps the documentation should be updated. If it is the "Go-ic" way to do it, then I think that my point still holds. I also don't really have a lot of excitement about the prospect of solving problems by composing types in Go. For instance, to the best of my knowledge, Go does not have language support for sum types. It's not that I'd rather use continuations or callbacks -- I like powerful, expressive type systems to do, e.g., static enforcement of contracts -- it's just that I think that Go's type system isn't very expressive. You're right, perhaps I'm totally misinformed about the language, and that lurking below there really is a way to do clear and clean things with types in Go. But everything I've seen points in the opposite direction, so at this point, though I have an open mind, I'd need more evidence to change my view.
  - colin_mccabe 13y ago
    The example we were discussing was written by Mark McGranaghan, and is not part of the go documentation per se. I think it's a nice little tutorial, but please don't confuse it with "the Go documentation." Mark's point was that you can create an arbitrary wrapper type around another interface, so that the behaviors are composed. This is the most flexible way to do things. If there's already a wrapper type that does what you want, however, then you can simply use that. They are both examples of composition, and both "the Go-ic way to do it." Composition is often overlooked by people who are fixated on other ways of doing things, like inheritance or generics. But in many ways, it's cleaner, since composition allows you to link together many modules without peeking inside. It's funny that people have accepted the reality of dynamic languages, but can't seem to "get" the idea of statically typed language without generics. There isn't a troll comment in every Python article that it would be better with static typing. Type systems are a little bit like body armor-- development can be slower, but in exchanged you get a little more confidence in the program. People have accepted the idea of going naked, and the idea of medieval-style full plate armor, but the idea that you might want some type safety, but not go overboard often seems to fall on deaf ears.
    - hdevalence 13y ago
      Actually, the example I was referring to (see my comment elsewhere in the thread) is copied directly from the Go documentation here: http://golang.org/pkg/sort/ http://golang.org/pkg/sort/ Composition is great. It does not solve the same problem as generics. The reason people can't seem to "get" the idea of statically typed languages without generics is because static typing without parametric polymorphism is a painful experience. I'm not opposed to the idea of finding some balance between static and dynamic typing -- Clojure type annotations seem interesting -- it's just that I don't like the way Go does it.
sergiotapia 13y ago
That's something for the Go creators to decide, but personally I enjoy the feeling of safety that comes with lack of generics. I have very few Go bugs at runtime and I think that explicitness plays a huge part in it.
- JeanPierre 13y ago
  Could you elaborate on how generics makes code less safe? In my experience, the lack of generics is much more type unsafe, as you often have to do casts at runtime (and handle them) when you have to implement your own data structures. In contrast, languages with generics handle those at compile time.
- hdevalence 13y ago
  What? I'm talking about stuff like this, copied from the documentation: func (a ByAge) Len() int { return len(a) } func (a ByAge) Swap(i, j int) { a[i], a[j] = a[j], a[i] } func (a ByAge) Less(i, j int) bool { return a[i].Age < a[j].Age } How does forcing me to type out (or copy-paste) an implementation of Swap increase safety? If anything, it just makes the code more error-prone. And not having generics means that (as far as I can tell) people end up using a lot of `interface{}`. How does that increase safety? More importantly, why would I want to use a language whose solution to the problem of "dealing with generic data" essentially boils down to "use a void*"?
- pcwalton 13y ago
  Not having generics reduces explicitness (because you don't specify the types of your containers) and reduces safety (because of all the casts and manual implementations of things like swap functions).
  - fauigerzigerk 13y ago
    On the other hand, C++ templates sometimes make it hard to understand which function ends up getting called, what size a particular type actually has or what is an alias for what. There are too many indirections to follow manually. All I know is that the compiler will select some function that has conforming types. The compiler is very very smart. It knows all the incredibly complicated name resolution rules and it will use each one of them. Unfortuntately I'm not as smart. Even after more than 20 years of using C++ I sometimes fail to anticipate which function the compiler decides to use. And that is not safe. In fact it is less safe than casting interface{}, because that will at least fail fast at runtime instead of silently doing something unexpected.
bsg75 13y ago
What does yet another gripe about generics in Go have to do with a tutorial written by an independent party, one that is about features in the language today ?
- jamesaguilar 13y ago
  Same reason most posts about MongoDB for a long time had complaints about Mongo's uh . . . let's say "relaxed" . . . approach to durability. Because proponents of the language/system/idea tend to promote an unbalanced view of its quality, its detractors need to be there to give people on the fence the right dose of the bad medicine. Also, speaking only for myself, I really like the language and its ideas, but that one thing it's missing makes it too annoying to write code in it. I'd like to see more people aware of this deficiency and putting pressure on the language's owners to fix that problem, so that I can start using it.
  - bsg75 13y ago
    Go generics and Mongo durability in the same thread. There is a trifecta brewing here...
    - sehr 13y ago
      Never underestimate the power of nitpicking in an HN thread.
      - jamesaguilar 13y ago
        It is amusing that you consider either generics or durability to be "nitpicks." One is a feature that is present in almost every static language of at least the last two decades, and another is a fundamental need of most database users, relational or not. Unless by nitpick you mean, "something I personally don't care about," I think your nitpick-classifier is a bit busted.
        sehr 13y ago
scriptproof 13y ago
http://commandcenter.blogspot.co.uk/2011/12/esmereldas-imagination.html http://commandcenter.blogspot.co.uk/2011/12/esmereldas-imagi...
- Dewie 13y ago
  "I resolve to recognize that a complaint reveals more about the complainer than the complained-about. Authority is won not by rants but by experience and insight, which require practice and imagination. And maybe some programming." Of course, being Rob Pike, decreeing that authority and experience is more valuable than any (well-reasoned) complaints from other people is a very convenient stance for him to take; how many complainers are going to rival his résumé?
  - burntsushi 13y ago
    That's pretty much the boiler plate ad hominem.
- deleted 13y ago
  [deleted]
asdf3 13y ago
Complaint<generics>("write a bunch of extra boilerplate functions in order to sort a list");

colin_mccabe 13y ago

Hi hdevlance, Generics actually have very little to do with sorting a list in Go. The example that the parent gave could be expressed in one line as "sort.Sort(sort.Reverse(sort.StringSlice(vs)));" No generics needed-- only composition. sort.Reverse is a wrapper interface which can be composed with any other sort.Interface to reverse it. It is typesafe, too-- there are no typecasts. There are cases where generics would allow us to avoid typecasts, but this is simply not one of them. In many cases, what you want can be expressed via composition of types, and often (in my opinion) in a clearer way than by using lambdas, continuations, and callbacks. I suggest learning a bit more about the language and keeping an open mind.

hdevalence 13y ago
If you say so -- I'm just going off of the examples given in the Go documentation on how to sort lists. If that's not the "Go-ic" way to do it, perhaps the documentation should be updated. If it is the "Go-ic" way to do it, then I think that my point still holds. I also don't really have a lot of excitement about the prospect of solving problems by composing types in Go. For instance, to the best of my knowledge, Go does not have language support for sum types. It's not that I'd rather use continuations or callbacks -- I like powerful, expressive type systems to do, e.g., static enforcement of contracts -- it's just that I think that Go's type system isn't very expressive. You're right, perhaps I'm totally misinformed about the language, and that lurking below there really is a way to do clear and clean things with types in Go. But everything I've seen points in the opposite direction, so at this point, though I have an open mind, I'd need more evidence to change my view.
- colin_mccabe 13y ago
  The example we were discussing was written by Mark McGranaghan, and is not part of the go documentation per se. I think it's a nice little tutorial, but please don't confuse it with "the Go documentation." Mark's point was that you can create an arbitrary wrapper type around another interface, so that the behaviors are composed. This is the most flexible way to do things. If there's already a wrapper type that does what you want, however, then you can simply use that. They are both examples of composition, and both "the Go-ic way to do it." Composition is often overlooked by people who are fixated on other ways of doing things, like inheritance or generics. But in many ways, it's cleaner, since composition allows you to link together many modules without peeking inside. It's funny that people have accepted the reality of dynamic languages, but can't seem to "get" the idea of statically typed language without generics. There isn't a troll comment in every Python article that it would be better with static typing. Type systems are a little bit like body armor-- development can be slower, but in exchanged you get a little more confidence in the program. People have accepted the idea of going naked, and the idea of medieval-style full plate armor, but the idea that you might want some type safety, but not go overboard often seems to fall on deaf ears.
  - hdevalence 13y ago
    Actually, the example I was referring to (see my comment elsewhere in the thread) is copied directly from the Go documentation here: http://golang.org/pkg/sort/ http://golang.org/pkg/sort/ Composition is great. It does not solve the same problem as generics. The reason people can't seem to "get" the idea of statically typed languages without generics is because static typing without parametric polymorphism is a painful experience. I'm not opposed to the idea of finding some balance between static and dynamic typing -- Clojure type annotations seem interesting -- it's just that I don't like the way Go does it.

sergiotapia 13y ago

That's something for the Go creators to decide, but personally I enjoy the feeling of safety that comes with lack of generics. I have very few Go bugs at runtime and I think that explicitness plays a huge part in it.

JeanPierre 13y ago
Could you elaborate on how generics makes code less safe? In my experience, the lack of generics is much more type unsafe, as you often have to do casts at runtime (and handle them) when you have to implement your own data structures. In contrast, languages with generics handle those at compile time.
hdevalence 13y ago
What? I'm talking about stuff like this, copied from the documentation: func (a ByAge) Len() int { return len(a) } func (a ByAge) Swap(i, j int) { a[i], a[j] = a[j], a[i] } func (a ByAge) Less(i, j int) bool { return a[i].Age < a[j].Age } How does forcing me to type out (or copy-paste) an implementation of Swap increase safety? If anything, it just makes the code more error-prone. And not having generics means that (as far as I can tell) people end up using a lot of `interface{}`. How does that increase safety? More importantly, why would I want to use a language whose solution to the problem of "dealing with generic data" essentially boils down to "use a void*"?
pcwalton 13y ago
Not having generics reduces explicitness (because you don't specify the types of your containers) and reduces safety (because of all the casts and manual implementations of things like swap functions).
- fauigerzigerk 13y ago
  On the other hand, C++ templates sometimes make it hard to understand which function ends up getting called, what size a particular type actually has or what is an alias for what. There are too many indirections to follow manually. All I know is that the compiler will select some function that has conforming types. The compiler is very very smart. It knows all the incredibly complicated name resolution rules and it will use each one of them. Unfortuntately I'm not as smart. Even after more than 20 years of using C++ I sometimes fail to anticipate which function the compiler decides to use. And that is not safe. In fact it is less safe than casting interface{}, because that will at least fail fast at runtime instead of silently doing something unexpected.

bsg75 13y ago

What does yet another gripe about generics in Go have to do with a tutorial written by an independent party, one that is about features in the language today ?

jamesaguilar 13y ago
Same reason most posts about MongoDB for a long time had complaints about Mongo's uh . . . let's say "relaxed" . . . approach to durability. Because proponents of the language/system/idea tend to promote an unbalanced view of its quality, its detractors need to be there to give people on the fence the right dose of the bad medicine. Also, speaking only for myself, I really like the language and its ideas, but that one thing it's missing makes it too annoying to write code in it. I'd like to see more people aware of this deficiency and putting pressure on the language's owners to fix that problem, so that I can start using it.
- bsg75 13y ago
  Go generics and Mongo durability in the same thread. There is a trifecta brewing here...
  - sehr 13y ago
    Never underestimate the power of nitpicking in an HN thread.
    - jamesaguilar 13y ago
      It is amusing that you consider either generics or durability to be "nitpicks." One is a feature that is present in almost every static language of at least the last two decades, and another is a fundamental need of most database users, relational or not. Unless by nitpick you mean, "something I personally don't care about," I think your nitpick-classifier is a bit busted.
      - sehr 13y ago

scriptproof 13y ago

http://commandcenter.blogspot.co.uk/2011/12/esmereldas-imagination.html http://commandcenter.blogspot.co.uk/2011/12/esmereldas-imagi...

Dewie 13y ago
"I resolve to recognize that a complaint reveals more about the complainer than the complained-about. Authority is won not by rants but by experience and insight, which require practice and imagination. And maybe some programming." Of course, being Rob Pike, decreeing that authority and experience is more valuable than any (well-reasoned) complaints from other people is a very convenient stance for him to take; how many complainers are going to rival his résumé?
- burntsushi 13y ago
  That's pretty much the boiler plate ad hominem.
deleted 13y ago
[deleted]

asdf3 13y ago

Complaint<generics>("write a bunch of extra boilerplate functions in order to sort a list");