5 ms·

I feel like not including generics is a huge oversight. Also, the way many go aficionados discuss this over at golang-nuts put me off a great deal.

azth 14y ago
Have you checked out Rust (http://rust-lang.org http://rust-lang.org)? They seem to be closer to what Go's original goals were, with generics, proper RAII, etc.
sanderjd 14y ago
What is an example of a use case for generics that can't be done, or is significantly less convenient to do, with interfaces? It sounds like there is at least some thought that generics may be included at some point, but I really haven't missed them thus far.
- lmkg 14y ago
  It's not that there's a lot of things that you flat-out can't do, it's that you can't do those things in a type-safe manner. The type system isn't capable of representing what you're trying to do. This seems like an odd omission in a language that otherwise has static typing. I suspect this is why a lot of people who've jumped on the Golang bandwagon come from Python & Ruby: they're already used to no compile-time type safety, so they're not missing anything. For people who like type systems and have a style of programming that relies upon them, Go doesn't give them the tools they need to be productive. In Steve Yegge's terms: C++ is a pretty software-conservative update to C (it even has backwards-compatible syntax). Meanwhile, Go is a pretty software-liberal update (slightly to the right of Python). G simply does not support a software-conservative programming style. Consequently, Go's adoption has mostly come from software-liberal communities.
  - jbooth 14y ago
    I hate those terms, but by his definitions, Go is statically typed and defaults to not including features if they think they might be misused. Doesn't sound that liberal to me, compared to, say, Ruby with monkey-patching.
- pufuwozu 14y ago
  A lot of functional constructs heavily rely on parametric polymorphism. For example: map :: (a -> b) -> [a] -> [b] Interfaces can't provide this type of code reuse.
  - DanWaterworth 14y ago
    Slight nitpick, you can do this, just not with type safety. Type safety is the real reason generics are better than interfaces.
  - mseepgood 14y ago
    If you're attached to FP style you shouldn't choose an imperative language in the first place.
    - jerf 14y ago
      It has been pretty conclusively demonstrated at this point that a basic suite of "weak" FP tools is pretty useful in any language. No serious modern language should try to work without convenient closures and a functioning map and filter statement/function/whatever. This hasn't got anything to do with purity or academic goodness, and everything to do with the fact that languages like Python or Ruby, which are emphatically not FP languages, have simply shown such things to be indispensable tools for concise code.
      - eckyptang 14y ago
        Pretty useful: yes. Essential: no. Map/Filter introduce several new semantic concepts to a language. I think they were avoided for simplicity's sake and the fact you can achieve the same result with a for loop, even if it is slightly less concise.
        masklinn 14y ago
        > Map/Filter introduce several new semantic concepts to a language. No they don't. If you already have first-class functions (Go does) and some sort of sequence type (Go does), you have map/filter. There's no new semantic concepts.
- emu 14y ago
  I have to agree that the lack of generics is one of the biggest holes in Go. Common container data structures are one example. You can't write, say, a generic binary search tree in Go, unless you wrap all your data in an interface. While possible, this means you have to downcast all over the place. The built-in map, while useful, is limited in how far it goes. Maybe I'm just spoiled by the STL and the Java collections libraries.
- libria 14y ago
  Repository style generic data access layers: http://stackoverflow.com/questions/11914712/writing-generic-data-access-functions-in-go http://stackoverflow.com/questions/11914712/writing-generic-...
  - BarkMore 14y ago
    There are several generic data access layers implemented in Go: standard JSON package, Gustavo's BSON package, App Engine Data store and more. They all use the reflect package internally.
- colin_jack 14y ago
  I tend to use generics alongside reflection a lot, for example I might use a Mapper<TFrom, TTo> when mapping between different representations (an object and associated service contract being one example). The mapper can take care of almost everything using a few conventions and reflection, and for anything where those conventions don't cover it you plug in a little custom code (inherit from Mapper<,> or use composition). Not sure how you’d handle that sort of case in Go without generics?
nephesh 14y ago
Yeah, it basically makes the answer to the original question an emphatic "No".
andrewcooke 14y ago
to some extent, i think that the demand for generics is based on familiarity. for example, long ago, i was looking at the source for some of the go libraries and couldn't understand why they had cut+paste code. when i asked on stackoverflow the unaminous answer was "because go doesn't support generics". you can see the discussion here - http://stackoverflow.com/questions/6645329/why-does-the-go-image-package-cutpaste-looping-over-pixels http://stackoverflow.com/questions/6645329/why-does-the-go-i... BUT if you read that thread, and the discussion under the first answer, you'll see that there is an apparently reasonable solution without generics. that seemed like an obvious approach to me (coming, i guess, more from python and fp), but one that wasn't obvious to anyone answering (coming, i guess, more from java and c). i have no evidence that this is a general problem, but it surprised me at the time. ever since i have been suspicious of people complaining about the lack of generics (disclaimer: i don't use go myself - when i looked at it i thought that it was clear improvement on c/c++/java, but could have been even better if they had been more open to ideas from fp - http://acooke.org/cute/GoRocksHow0.html http://acooke.org/cute/GoRocksHow0.html ; in other words, i'd be happy to use it at work instead of c (current project), but if i can choose myself i'm more likely to go with a more functional approach).
- masklinn 14y ago
  > to some extent, i think that the demand for generics is based on familiarity. Such as the familiarity of java developers who had to wait for a decade to get generics? The familiarity of C developers where void*? Or the familiarity of Python developers where "whatever"? This claim doesn't check out.
  - deleted 14y ago
    [deleted]
- bjourne 14y ago
  I think your so question shows exactly why generics are useful. A solution where you pass a callback predicate to the iterating function would work in Go, but be much slower than one in which the predicate logic can be inlined. E.g. if your image is 1920x1200 you would need to call the function that checks if the pixel is opaque 2.3 million times. That approach works ok in Python and Ruby which do not mind being a little on the slow side, but Go is supposed to be closer to the metal so something more efficient is needed.
Evbn 14y ago
It's not an oversight, it is a tradeoff. Check Russ Cox'sswtch.com website for details. You can write generic functions with reflection.

azth 14y ago

Have you checked out Rust (http://rust-lang.org http://rust-lang.org)? They seem to be closer to what Go's original goals were, with generics, proper RAII, etc.

sanderjd 14y ago

What is an example of a use case for generics that can't be done, or is significantly less convenient to do, with interfaces? It sounds like there is at least some thought that generics may be included at some point, but I really haven't missed them thus far.

lmkg 14y ago
It's not that there's a lot of things that you flat-out can't do, it's that you can't do those things in a type-safe manner. The type system isn't capable of representing what you're trying to do. This seems like an odd omission in a language that otherwise has static typing. I suspect this is why a lot of people who've jumped on the Golang bandwagon come from Python & Ruby: they're already used to no compile-time type safety, so they're not missing anything. For people who like type systems and have a style of programming that relies upon them, Go doesn't give them the tools they need to be productive. In Steve Yegge's terms: C++ is a pretty software-conservative update to C (it even has backwards-compatible syntax). Meanwhile, Go is a pretty software-liberal update (slightly to the right of Python). G simply does not support a software-conservative programming style. Consequently, Go's adoption has mostly come from software-liberal communities.
- jbooth 14y ago
  I hate those terms, but by his definitions, Go is statically typed and defaults to not including features if they think they might be misused. Doesn't sound that liberal to me, compared to, say, Ruby with monkey-patching.
pufuwozu 14y ago
A lot of functional constructs heavily rely on parametric polymorphism. For example: map :: (a -> b) -> [a] -> [b] Interfaces can't provide this type of code reuse.
- DanWaterworth 14y ago
  Slight nitpick, you can do this, just not with type safety. Type safety is the real reason generics are better than interfaces.
- mseepgood 14y ago
  If you're attached to FP style you shouldn't choose an imperative language in the first place.
  - jerf 14y ago
    It has been pretty conclusively demonstrated at this point that a basic suite of "weak" FP tools is pretty useful in any language. No serious modern language should try to work without convenient closures and a functioning map and filter statement/function/whatever. This hasn't got anything to do with purity or academic goodness, and everything to do with the fact that languages like Python or Ruby, which are emphatically not FP languages, have simply shown such things to be indispensable tools for concise code.
    - eckyptang 14y ago
      Pretty useful: yes. Essential: no. Map/Filter introduce several new semantic concepts to a language. I think they were avoided for simplicity's sake and the fact you can achieve the same result with a for loop, even if it is slightly less concise.
      - masklinn 14y ago
        > Map/Filter introduce several new semantic concepts to a language. No they don't. If you already have first-class functions (Go does) and some sort of sequence type (Go does), you have map/filter. There's no new semantic concepts.
emu 14y ago
I have to agree that the lack of generics is one of the biggest holes in Go. Common container data structures are one example. You can't write, say, a generic binary search tree in Go, unless you wrap all your data in an interface. While possible, this means you have to downcast all over the place. The built-in map, while useful, is limited in how far it goes. Maybe I'm just spoiled by the STL and the Java collections libraries.
libria 14y ago
Repository style generic data access layers: http://stackoverflow.com/questions/11914712/writing-generic-data-access-functions-in-go http://stackoverflow.com/questions/11914712/writing-generic-...
- BarkMore 14y ago
  There are several generic data access layers implemented in Go: standard JSON package, Gustavo's BSON package, App Engine Data store and more. They all use the reflect package internally.
colin_jack 14y ago
I tend to use generics alongside reflection a lot, for example I might use a Mapper<TFrom, TTo> when mapping between different representations (an object and associated service contract being one example). The mapper can take care of almost everything using a few conventions and reflection, and for anything where those conventions don't cover it you plug in a little custom code (inherit from Mapper<,> or use composition). Not sure how you’d handle that sort of case in Go without generics?

nephesh 14y ago

Yeah, it basically makes the answer to the original question an emphatic "No".

andrewcooke 14y ago

to some extent, i think that the demand for generics is based on familiarity. for example, long ago, i was looking at the source for some of the go libraries and couldn't understand why they had cut+paste code. when i asked on stackoverflow the unaminous answer was "because go doesn't support generics". you can see the discussion here - http://stackoverflow.com/questions/6645329/why-does-the-go-image-package-cutpaste-looping-over-pixels http://stackoverflow.com/questions/6645329/why-does-the-go-i... BUT if you read that thread, and the discussion under the first answer, you'll see that there is an apparently reasonable solution without generics. that seemed like an obvious approach to me (coming, i guess, more from python and fp), but one that wasn't obvious to anyone answering (coming, i guess, more from java and c). i have no evidence that this is a general problem, but it surprised me at the time. ever since i have been suspicious of people complaining about the lack of generics (disclaimer: i don't use go myself - when i looked at it i thought that it was clear improvement on c/c++/java, but could have been even better if they had been more open to ideas from fp - http://acooke.org/cute/GoRocksHow0.html http://acooke.org/cute/GoRocksHow0.html ; in other words, i'd be happy to use it at work instead of c (current project), but if i can choose myself i'm more likely to go with a more functional approach).

masklinn 14y ago
> to some extent, i think that the demand for generics is based on familiarity. Such as the familiarity of java developers who had to wait for a decade to get generics? The familiarity of C developers where void*? Or the familiarity of Python developers where "whatever"? This claim doesn't check out.
- deleted 14y ago
  [deleted]
bjourne 14y ago
I think your so question shows exactly why generics are useful. A solution where you pass a callback predicate to the iterating function would work in Go, but be much slower than one in which the predicate logic can be inlined. E.g. if your image is 1920x1200 you would need to call the function that checks if the pixel is opaque 2.3 million times. That approach works ok in Python and Ruby which do not mind being a little on the slow side, but Go is supposed to be closer to the metal so something more efficient is needed.

Evbn 14y ago

It's not an oversight, it is a tradeoff. Check Russ Cox'sswtch.com website for details. You can write generic functions with reflection.