5 ms·

What storm? Generics?

by _wldu 6y ago

mseepgood 6y ago
Yes, the proposal was accepted this week: https://golang.org/doc/faq#generics https://golang.org/doc/faq#generics
- _wldu 6y ago
  But is that really bad for Go? I'm not sure it is. Go1 will always be useful just as it is.
  - mseepgood 6y ago
    > But is that really bad for Go? No, I don't think so.
  - cpuguy83 6y ago
    I don't think the op intended "storm" to be negative here. Just to say that there are loads of changes coming soon.
  - throwaway894345 6y ago
    One of the features of Go is that everyone writes code the same way, which means anyone can easily read anyone else's code; there's only one paradigm; idioms and conventions are strong across the community. This property exists precisely because Go isn't very expressive, but the generics proposal will make Go more expressive and in all likelihood the ecosystem will become more diverse accordingly. Whether this is a positive or negative depends on how much you value expressiveness versus standardization.
mholt 6y ago
Yeah. To clarify, I'm not suggesting it's either good or bad -- just that it's a big deal. To some, it's controversial. I personally think Go's proposed implementation of parametric polymorphism a great feat of modern software engineering, and a testament to the open source process. Anyway, they'll probably land in Go 1.18.
- _wldu 6y ago
  Thanks. I could take them or leave them. I've used generics a lot in C++, but as long as I can continue writing Go1 programs as I have been for the last 10 years, I'll be happy.
  - craigching 6y ago
    Oh, come now, calling C++ templates generics belittles their power. :p Honestly, the one thing I miss in any language is the complete power of C++ templates, but I definitely understand others' reluctance to include something like them in their language. Something that allows me to write simple generic functionality a la Java generics and not have to write the same code multiple times is good enough for me in go. Luckily I do have some ability to use C++ at my current job, so I can get my fix again there :)
- benhoyt 6y ago
  I'm looking forward to them, and definitely agree it's a great feat of software engineering ... though I'm not sure about "testament to the open source process". Go is open source, but most of the core developers are Google employees, and definitely the folks that worked on generics (Ian and Robert, mainly) are full time at Google. I don't actually think that's a bad thing: I love it that Google pays people to work on Go full time, and don't mind the language being spear-headed by a tight team with a vision (who happen to work at a commercial entity). I'm impressed with their direction, and ability to say no.
  - nemo1618 6y ago
    Yeah, let's be real -- just as with Go Modules and the "try" proposal, there is no "open source process" when it comes to major language changes; the decision is always ultimately made by the core team, not the community. And I agree with you -- this arrangement is fine! I strongly prefer it that way. The Go devs have an excellent track record of getting it right, even when it went against the prevailing wisdom. Personally, I'm opposed to adding generics, but if we have to...I trust the Go devs to do it better than just about anyone else.
- 6y ago

What storm? Generics?

by _wldu 6y ago

What storm? Generics?

mseepgood 6y ago

Yes, the proposal was accepted this week: https://golang.org/doc/faq#generics https://golang.org/doc/faq#generics

_wldu 6y ago
But is that really bad for Go? I'm not sure it is. Go1 will always be useful just as it is.
- mseepgood 6y ago
  > But is that really bad for Go? No, I don't think so.
- cpuguy83 6y ago
  I don't think the op intended "storm" to be negative here. Just to say that there are loads of changes coming soon.
- throwaway894345 6y ago
  One of the features of Go is that everyone writes code the same way, which means anyone can easily read anyone else's code; there's only one paradigm; idioms and conventions are strong across the community. This property exists precisely because Go isn't very expressive, but the generics proposal will make Go more expressive and in all likelihood the ecosystem will become more diverse accordingly. Whether this is a positive or negative depends on how much you value expressiveness versus standardization.

mholt 6y ago

Yeah. To clarify, I'm not suggesting it's either good or bad -- just that it's a big deal. To some, it's controversial. I personally think Go's proposed implementation of parametric polymorphism a great feat of modern software engineering, and a testament to the open source process. Anyway, they'll probably land in Go 1.18.

_wldu 6y ago
Thanks. I could take them or leave them. I've used generics a lot in C++, but as long as I can continue writing Go1 programs as I have been for the last 10 years, I'll be happy.
- craigching 6y ago
  Oh, come now, calling C++ templates generics belittles their power. :p Honestly, the one thing I miss in any language is the complete power of C++ templates, but I definitely understand others' reluctance to include something like them in their language. Something that allows me to write simple generic functionality a la Java generics and not have to write the same code multiple times is good enough for me in go. Luckily I do have some ability to use C++ at my current job, so I can get my fix again there :)
benhoyt 6y ago
I'm looking forward to them, and definitely agree it's a great feat of software engineering ... though I'm not sure about "testament to the open source process". Go is open source, but most of the core developers are Google employees, and definitely the folks that worked on generics (Ian and Robert, mainly) are full time at Google. I don't actually think that's a bad thing: I love it that Google pays people to work on Go full time, and don't mind the language being spear-headed by a tight team with a vision (who happen to work at a commercial entity). I'm impressed with their direction, and ability to say no.
- nemo1618 6y ago
  Yeah, let's be real -- just as with Go Modules and the "try" proposal, there is no "open source process" when it comes to major language changes; the decision is always ultimately made by the core team, not the community. And I agree with you -- this arrangement is fine! I strongly prefer it that way. The Go devs have an excellent track record of getting it right, even when it went against the prevailing wisdom. Personally, I'm opposed to adding generics, but if we have to...I trust the Go devs to do it better than just about anyone else.
6y ago