4 ms·

I sometimes wonder if they should have implemented generics. On the one hand you had a group of people using go as it was and presumably mostly happy with the l

I sometimes wonder if they should have implemented generics. On the one hand you had a group of people using go as it was and presumably mostly happy with the lack of generics. On the other side you have people (like me) complaining about the lack of generics but who were unlikely to use the language once they were added. It's very subjective but my gut feeling is they probably didn't expand their community much by adding generics to the language.

cherryteastain 2y ago
I think a lot of the people who wanted generics wanted them more to be like C++ templates, with compile time duck typing. Go maintainers were unwilling to go that route because of complexity. However, as a result, any time I think "oh this looks like it could be made generic" I fall into a rabbit hole regarding what Go generics do and dont allow you to do and usually end up copy pasting code instead.
- wyufro 2y ago
  I think "oh this looks like it could be made generic" is the wrong time to convert to generics. You should convert when you reach the point "I wish I had that code but with this other type". Even then, sometimes interfaces are the right answer, rather than generics.
  - deleted 2y ago
    [deleted]
  - cherryteastain 2y ago
    I mostly agree, hence the > end up copy pasting code instead bit of my original comment
vbezhenar 2y ago
Generic containers are needed in some cases. Using generic containers with interface{} is very slow and memory-intensive. Not a problem for small containers, but for big containers it's just not feasible, so you would need to either copy&paste huge chunks of code or generate code. Compared to those approaches, generic support is superior in every way, so it's needed. But creating STL on top of them is not the indended use-case.
sbrother 2y ago
Having recently had to work on a Go project for the first time, I think I agree with you here. I'd tried Go a little bit when it came out, had zero interest in what it offered, and then when I was asked to work on this project a couple months ago I thought it would be fun to try it out again since I had read the language had improved. No, it still feels like programming with a blindfold on and one hand tied behind my back. I truly don't get it. I've worked with a lot of languages and paradigms, am not a zealot by any means. Other than fast compiles and easy binary distribution, I don't see any value here, and I see even experienced Go programmers constantly wasting time writing unreadable boilerplate to work around the bad language design. I know I must be missing something because some people much smarter than me like this language, but... what is it?
- quinnirill 2y ago
  Mad LoCs, dude, gotta make alotta lines, that’s what productivity is!
- deleted 2y ago
  [deleted]
- indulona 2y ago
  > I see even experienced Go programmers constantly wasting time writing unreadable boilerplate if it is unreadable, in Go, probably the most readable language used today, i would question the aforementioned experience.
  - DangitBobby 2y ago
    What you're doing right now is called "coping".
  - LinXitoW 2y ago
    I don't think a language where for every 1 line of functionality, you need 3 lines of error handling boilerplate gets to be called readable. Heck, Go went out of it's way to "subvert expectations" more than the last season of Game of Thrones. 99% of decent C-ish languages either do "String thing" or "thing: String", but Go is so fancy and quirky, it does "thing String" for no freaking reason. Don't get me started on the nightmare that is map types.
marcus_holmes 2y ago
Library authors were the main target group, I think. Without generics, your library has to define interfaces that your users have to implement and it all gets a bit strange and unintuitive. With generics you can write library code that is easier to use. The thing I was worried about with this (adding generics) is that we'd start moving more towards the NPM Hell of everyone just writing plumbing code for imported packages. But thankfully that hasn't happened and idiomatic Go still tends to just use the standard lib and very few external packages.
brokencode 2y ago
Most of the improvements made to any language don’t expand the community much. And they don’t have to, because that’s not the point. The point is to improve the language and ecosystem to help make better software. Generics support is a ubiquitous feature in static programming languages. If it was included on day one in Go, nobody would have blinked an eye. This is only such a controversial topic in Go because the language maintainers made it one.

cherryteastain 2y ago

I think a lot of the people who wanted generics wanted them more to be like C++ templates, with compile time duck typing. Go maintainers were unwilling to go that route because of complexity. However, as a result, any time I think "oh this looks like it could be made generic" I fall into a rabbit hole regarding what Go generics do and dont allow you to do and usually end up copy pasting code instead.

wyufro 2y ago
I think "oh this looks like it could be made generic" is the wrong time to convert to generics. You should convert when you reach the point "I wish I had that code but with this other type". Even then, sometimes interfaces are the right answer, rather than generics.
- deleted 2y ago
  [deleted]
- cherryteastain 2y ago
  I mostly agree, hence the > end up copy pasting code instead bit of my original comment

vbezhenar 2y ago

Generic containers are needed in some cases. Using generic containers with interface{} is very slow and memory-intensive. Not a problem for small containers, but for big containers it's just not feasible, so you would need to either copy&paste huge chunks of code or generate code. Compared to those approaches, generic support is superior in every way, so it's needed. But creating STL on top of them is not the indended use-case.

sbrother 2y ago

Having recently had to work on a Go project for the first time, I think I agree with you here. I'd tried Go a little bit when it came out, had zero interest in what it offered, and then when I was asked to work on this project a couple months ago I thought it would be fun to try it out again since I had read the language had improved. No, it still feels like programming with a blindfold on and one hand tied behind my back. I truly don't get it. I've worked with a lot of languages and paradigms, am not a zealot by any means. Other than fast compiles and easy binary distribution, I don't see any value here, and I see even experienced Go programmers constantly wasting time writing unreadable boilerplate to work around the bad language design. I know I must be missing something because some people much smarter than me like this language, but... what is it?

quinnirill 2y ago
Mad LoCs, dude, gotta make alotta lines, that’s what productivity is!
deleted 2y ago
[deleted]
indulona 2y ago
> I see even experienced Go programmers constantly wasting time writing unreadable boilerplate if it is unreadable, in Go, probably the most readable language used today, i would question the aforementioned experience.
- DangitBobby 2y ago
  What you're doing right now is called "coping".
- LinXitoW 2y ago
  I don't think a language where for every 1 line of functionality, you need 3 lines of error handling boilerplate gets to be called readable. Heck, Go went out of it's way to "subvert expectations" more than the last season of Game of Thrones. 99% of decent C-ish languages either do "String thing" or "thing: String", but Go is so fancy and quirky, it does "thing String" for no freaking reason. Don't get me started on the nightmare that is map types.

marcus_holmes 2y ago

Library authors were the main target group, I think. Without generics, your library has to define interfaces that your users have to implement and it all gets a bit strange and unintuitive. With generics you can write library code that is easier to use. The thing I was worried about with this (adding generics) is that we'd start moving more towards the NPM Hell of everyone just writing plumbing code for imported packages. But thankfully that hasn't happened and idiomatic Go still tends to just use the standard lib and very few external packages.

brokencode 2y ago

Most of the improvements made to any language don’t expand the community much. And they don’t have to, because that’s not the point. The point is to improve the language and ecosystem to help make better software. Generics support is a ubiquitous feature in static programming languages. If it was included on day one in Go, nobody would have blinked an eye. This is only such a controversial topic in Go because the language maintainers made it one.