4 ms·

I really want to like Go, but I'm having a hard time believing that they don't have a plan for generics. I've read the FAQs about go+generics, but do we have a

I really want to like Go, but I'm having a hard time believing that they don't have a plan for generics. I've read the FAQs about go+generics, but do we have any better idea of when generics might make an appearance? Not being able to write a generic "map" function in a modern language seems very strange to me. edit: there's something "map"-ish here: https://code.google.com/p/go/source/browse/src/pkg/exp/iterable/iterable.go?r=1d1670229de33959691a343d716cfb32594bddbd https://code.google.com/p/go/source/browse/src/pkg/exp/itera...

masklinn 13y ago
> I really want to like Go Why? 4 years on seems a long enough time to come to term with what Go is.
dragonwriter 13y ago
> I really want to like Go, but I'm having a hard time believing that they don't have a plan for generics. I've read the FAQs about go+generics, but do we have any better idea of when generics might make an appearance? As a language feature: not likely any sooner than Go 2.0, given everything that's been said on the issue, though I suppose if a way could be found to do generics that doesn't explode compilation time and doesn't involve syntax changes that would break any existing Go 1.x code, it might happen in a later 1.x release. Wouldn't hold my breath. Via a preprocessor? Its already a thing: https://github.com/droundy/gotgo https://github.com/droundy/gotgo
bsg75 13y ago
http://golang.org/doc/faq http://golang.org/doc/faq : "Generics are convenient but they come at a cost in complexity in the type system and run-time. We haven't yet found a design that gives value proportionate to the complexity, although we continue to think about it. Meanwhile, Go's built-in maps and slices, plus the ability to use the empty interface to construct containers (with explicit unboxing) mean in many cases it is possible to write code that does what generics would enable, if less smoothly." One of Go's goals is a certain level of simplicity. The above point seems to state that generics don't fit that goal, but they are not precluded from a future version. I take this to mean that since no language has every feature that anyone could possibly want, if generics are a requirement for your work, then Go does not fit the requirements. Some potentially relevant material here - http://commandcenter.blogspot.de/2012/06/less-is-exponentially-more.html http://commandcenter.blogspot.de/2012/06/less-is-exponential... : "Early in the rollout of Go I was told by someone that he could not imagine working in a language without generic types. As I have reported elsewhere, I found that an odd remark."

masklinn 13y ago

> I really want to like Go Why? 4 years on seems a long enough time to come to term with what Go is.

dragonwriter 13y ago

> I really want to like Go, but I'm having a hard time believing that they don't have a plan for generics. I've read the FAQs about go+generics, but do we have any better idea of when generics might make an appearance? As a language feature: not likely any sooner than Go 2.0, given everything that's been said on the issue, though I suppose if a way could be found to do generics that doesn't explode compilation time and doesn't involve syntax changes that would break any existing Go 1.x code, it might happen in a later 1.x release. Wouldn't hold my breath. Via a preprocessor? Its already a thing: https://github.com/droundy/gotgo https://github.com/droundy/gotgo

bsg75 13y ago

http://golang.org/doc/faq http://golang.org/doc/faq : "Generics are convenient but they come at a cost in complexity in the type system and run-time. We haven't yet found a design that gives value proportionate to the complexity, although we continue to think about it. Meanwhile, Go's built-in maps and slices, plus the ability to use the empty interface to construct containers (with explicit unboxing) mean in many cases it is possible to write code that does what generics would enable, if less smoothly." One of Go's goals is a certain level of simplicity. The above point seems to state that generics don't fit that goal, but they are not precluded from a future version. I take this to mean that since no language has every feature that anyone could possibly want, if generics are a requirement for your work, then Go does not fit the requirements. Some potentially relevant material here - http://commandcenter.blogspot.de/2012/06/less-is-exponentially-more.html http://commandcenter.blogspot.de/2012/06/less-is-exponential... : "Early in the rollout of Go I was told by someone that he could not imagine working in a language without generic types. As I have reported elsewhere, I found that an odd remark."