6 ms·

I'm not sure what you mean by vocal minority's complaints. Golang generics is the second most voted issue on GitHub itself: https://github.com/issues?q=is%3Aop

I'm not sure what you mean by vocal minority's complaints. Golang generics is the second most voted issue on GitHub itself: https://github.com/issues?q=is%3Aopen+is%3Aissue+sort%3Areactions-heart-desc https://github.com/issues?q=is%3Aopen+is%3Aissue+sort%3Areac... (I'm not sure if GitHub sorting is broken, but the same issue has more +1s than the top +1d issue as per that sort mode as well) Generics has the most experience reports in Go 2 proposal. Maybe this can be categorized and excluded as a vocal minority, but above data doesn't seem to.

theshrike79 9y ago
They haven't said "No" to generics. What the developers want is for people to submit _actual_ problems that generics would solve, with examples. Because there are more than a few way to do it and they want to pick the right one.
- kmicklas 9y ago
  It's simply astounding that the Google engineers working on Go lack the imagination to understand what problems generics would solve.
  - sctb 9y ago
    We've asked you twice before not to do this and now you're at it again, so we've banned the account like we said we would. If you would like to comment within the guidelines, we'd be happy to unban your account. https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html
- erik_seaberg 9y ago
  That's easy. Concurrent access to maps is unsafe. https://golang.org/pkg/sync/#Map https://golang.org/pkg/sync/#Map should be a drop-in replacement but due to the lack of generics it can't present a compatible or typesafe API.
  - terminalcommand 9y ago
    I've run into concurrency problems using maps while writing an irc client. It was really frustrating for me, because it did not happen everytime I ran the program, but rather rarely. I had chosen Go for it's memory-safety and easy concurrency. But I felt like I could not vouch for my program's safety any more. I did not know about sync/map at the time, had I known, I would probably have used it. I think Golang has a fondness for magical (to me) special language constructs. For example if you want to use the RPC modules, you have to write your functions a certain way. Or as I've explained in a comment above, if you want to use an interface you just have to implement all it's properties. Or you can't have generics, but we have a special language construct called maps, where you kind of can mimick genericks but it is not safe and may break. Golang is a great language, but I think it expects all its users to think very rigidly in the same way their designers do. Basically, you have to explore the language's deficiencies yourself, read the designers' explanations, dive into the intrinsics of the language, understand it, make yourself believe and move on. I sometimes half-jokingly feel like Golang follows the principle of most obedience.
    - kjksf 9y ago
      For concurrency issues, -race flag is your friend. Don't blame the language for your buggy code. Unless otherwise stated, Go's data structures are not thread-safe. Maps are not thread safe. In that respect Go isn't different from any other mainstream language with pre-emptive threading (C++, Java, C#).
      - wbl 9y ago
        But I can't implement a drop in compatible concurrency safe map.
        coldtea 9y ago
        Don't blame the language for that: jump through BS hoops to create one such map /s
      - coldtea 9y ago
qyv 9y ago
It is a vocal minority in the (probably correct) assumption that the majority of Go programmers are not part of that GitHub issue, nor any other group asking for Generics.
nine_k 9y ago
I'm afraid not all votes are (and should be) considered equal by the project maintainers. A great number of casual Go users might want feature XYZ. OTOH a couple dozen of large Go projects, with combined millions MLOCs and hundreds of millions of end users, may have a different list of priorities, and these priorities might be catered first. Also, let's not forget that Go is created at Google, and definitely Google's internal projects, likely large-scale by both line count and users served metrics, must take priority. Frankly, there is a number of reasonably nice languages that do provide generics, good / great type systems, good / great package management, decent async features, and quite decent performance: Rust, Nim, Crystal, ... all the way down to Haskell. Go is not competing with them at their strongest features. Instead, it's in the sweet spot of simplicity, fast build times, reasonable hygiene, and trivial deployment. It's the "getting job done" mentality which worked so well for PHP and Perl back in the day. There is a considerable demand for that.
- coldtea 9y ago
  >I'm afraid not all votes are (and should be) considered equal by the project maintainers. A great number of casual Go users might want feature XYZ. OTOH a couple dozen of large Go projects, with combined millions MLOCs and hundreds of millions of end users, may have a different list of priorities, and these priorities might be catered first. Many large users writing in company and project blogs have mentioned lack of Generics as a pain point, so that distinction doesn't go very far. >Also, let's not forget that Go is created at Google, and definitely Google's internal projects, likely large-scale by both line count and users served metrics, must take priority. Go was not created through some official decree to create a Google language, nor was it mandated to be used or to have some timeline to convert other stuff to it, etc. It's just a project started by some Go people with the idea "let's examine what a language appropriate for Google's programming would be" -- but using their personal ideas of what Google style programming would need, not something requested, researched etc by Google as an organization. In other words it started as a glorified 20% project, and today it's not any more official in Google than C++ or Java is.
  - nine_k 9y ago
    I suspect that Rob Pike's and Russ Cox's work is paid for by Google. But even if it were not, I suspect that heavyweight users like Google do have a weighty say, just because of the sheer amount of practical experience they have with developing and running software using the language. Just like Mozilla, I suppose, do have a say in the development of Rust.
freyir 9y ago
It's the biggest issue, but that doesn't mean the majority of Go developers support it. 1734 people reacted to the generics issue, most in favor, but there are many more Go developers than that. But the people who read the proposal and reacted to it may be the vocal minority who are concerned about generics. The majority may not spend their time reading or reacting to proposals they don't care about.
- coldtea 9y ago
  >Also, let's not forget that Go is created at Google, and definitely Google's internal projects, likely large-scale by both line count and users served metrics, must take priority. And many more want Generics without having responded to the issue. Issues are representative as a sampling, not absolute numbers.
  - skybrian 9y ago
    Unless you do random sampling, you still can't conclude anything one way or the other about whether it's a majority of users. Perhaps something like Google Surveys could be used to settle this?
  - freyir 9y ago
    I'm not sure who you're quoting or why. > Issues are representative as a sampling, not absolute numbers. My point was that issues are not a reliable sample of the Go community as a whole. They're a self-selected population of Go developers who cared enough about generics to click on a Github proposal on the subject and react to it. I'll say it again: >> The majority may not spend their time reading or reacting to proposals they don't care about. Maybe the majority do want generics, but the Github issue is poor evidence. A random sample of Go developers would be much better, and then we wouldn't have to make up things like "And many more want Generics without having responded to the issue."
    - coldtea 9y ago
      >I'm not sure who you're quoting or why. I accidentally re-pasted the same quote from nine_k I've answered to higher up the thread. Meant to quote this from you: "1734 people reacted to the generics issue, most in favor, but there are many more Go developers than that". >* My point was that issues are not a reliable sample of the Go community as a whole. They're a self-selected population of Go developers who cared enough about generics to click on a Github proposal on the subject and react to it.* And my point is that I don't think this is the case. I don't know either way, but there's no reason to assume people caring to vote in the issue are necessarily not representative -- like I don't think that for any other project/issue combo on github. In any case, even if they aren't representative of existing heavy Golang users, who cares about them? The language is still niche. There are tons more programmers to come to the language than those that already are using already. So I would very much pay attention to what those not yet using it but caring enough to vote have to say about it.
lossolo 9y ago
The most vocal group is the always the one that is not happy with someone. Doesn't mean this is majority and often it's not.
jhjwe888 9y ago
It should be obvious to folks on HN why a Github issue that may go completely unseen by a large swath of the go community, or +1's which can be gamed/trolled, should not be taken as a valid measure. But it must be explained I guess.
- coldtea 9y ago
  Confirmation bias much?
jackmott 9y ago
the guy is just being a dick.
baby 9y ago
Thanks for pointing that out, I went there to downvote the issue.

theshrike79 9y ago

They haven't said "No" to generics. What the developers want is for people to submit _actual_ problems that generics would solve, with examples. Because there are more than a few way to do it and they want to pick the right one.

kmicklas 9y ago
It's simply astounding that the Google engineers working on Go lack the imagination to understand what problems generics would solve.
- sctb 9y ago
  We've asked you twice before not to do this and now you're at it again, so we've banned the account like we said we would. If you would like to comment within the guidelines, we'd be happy to unban your account. https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html
erik_seaberg 9y ago
That's easy. Concurrent access to maps is unsafe. https://golang.org/pkg/sync/#Map https://golang.org/pkg/sync/#Map should be a drop-in replacement but due to the lack of generics it can't present a compatible or typesafe API.
- terminalcommand 9y ago
  I've run into concurrency problems using maps while writing an irc client. It was really frustrating for me, because it did not happen everytime I ran the program, but rather rarely. I had chosen Go for it's memory-safety and easy concurrency. But I felt like I could not vouch for my program's safety any more. I did not know about sync/map at the time, had I known, I would probably have used it. I think Golang has a fondness for magical (to me) special language constructs. For example if you want to use the RPC modules, you have to write your functions a certain way. Or as I've explained in a comment above, if you want to use an interface you just have to implement all it's properties. Or you can't have generics, but we have a special language construct called maps, where you kind of can mimick genericks but it is not safe and may break. Golang is a great language, but I think it expects all its users to think very rigidly in the same way their designers do. Basically, you have to explore the language's deficiencies yourself, read the designers' explanations, dive into the intrinsics of the language, understand it, make yourself believe and move on. I sometimes half-jokingly feel like Golang follows the principle of most obedience.
  - kjksf 9y ago
    For concurrency issues, -race flag is your friend. Don't blame the language for your buggy code. Unless otherwise stated, Go's data structures are not thread-safe. Maps are not thread safe. In that respect Go isn't different from any other mainstream language with pre-emptive threading (C++, Java, C#).
    - wbl 9y ago
      But I can't implement a drop in compatible concurrency safe map.
      - coldtea 9y ago
        Don't blame the language for that: jump through BS hoops to create one such map /s
    - coldtea 9y ago

qyv 9y ago

It is a vocal minority in the (probably correct) assumption that the majority of Go programmers are not part of that GitHub issue, nor any other group asking for Generics.

nine_k 9y ago

I'm afraid not all votes are (and should be) considered equal by the project maintainers. A great number of casual Go users might want feature XYZ. OTOH a couple dozen of large Go projects, with combined millions MLOCs and hundreds of millions of end users, may have a different list of priorities, and these priorities might be catered first. Also, let's not forget that Go is created at Google, and definitely Google's internal projects, likely large-scale by both line count and users served metrics, must take priority. Frankly, there is a number of reasonably nice languages that do provide generics, good / great type systems, good / great package management, decent async features, and quite decent performance: Rust, Nim, Crystal, ... all the way down to Haskell. Go is not competing with them at their strongest features. Instead, it's in the sweet spot of simplicity, fast build times, reasonable hygiene, and trivial deployment. It's the "getting job done" mentality which worked so well for PHP and Perl back in the day. There is a considerable demand for that.

coldtea 9y ago
>I'm afraid not all votes are (and should be) considered equal by the project maintainers. A great number of casual Go users might want feature XYZ. OTOH a couple dozen of large Go projects, with combined millions MLOCs and hundreds of millions of end users, may have a different list of priorities, and these priorities might be catered first. Many large users writing in company and project blogs have mentioned lack of Generics as a pain point, so that distinction doesn't go very far. >Also, let's not forget that Go is created at Google, and definitely Google's internal projects, likely large-scale by both line count and users served metrics, must take priority. Go was not created through some official decree to create a Google language, nor was it mandated to be used or to have some timeline to convert other stuff to it, etc. It's just a project started by some Go people with the idea "let's examine what a language appropriate for Google's programming would be" -- but using their personal ideas of what Google style programming would need, not something requested, researched etc by Google as an organization. In other words it started as a glorified 20% project, and today it's not any more official in Google than C++ or Java is.
- nine_k 9y ago
  I suspect that Rob Pike's and Russ Cox's work is paid for by Google. But even if it were not, I suspect that heavyweight users like Google do have a weighty say, just because of the sheer amount of practical experience they have with developing and running software using the language. Just like Mozilla, I suppose, do have a say in the development of Rust.

freyir 9y ago

It's the biggest issue, but that doesn't mean the majority of Go developers support it. 1734 people reacted to the generics issue, most in favor, but there are many more Go developers than that. But the people who read the proposal and reacted to it may be the vocal minority who are concerned about generics. The majority may not spend their time reading or reacting to proposals they don't care about.

coldtea 9y ago
>Also, let's not forget that Go is created at Google, and definitely Google's internal projects, likely large-scale by both line count and users served metrics, must take priority. And many more want Generics without having responded to the issue. Issues are representative as a sampling, not absolute numbers.
- skybrian 9y ago
  Unless you do random sampling, you still can't conclude anything one way or the other about whether it's a majority of users. Perhaps something like Google Surveys could be used to settle this?
- freyir 9y ago
  I'm not sure who you're quoting or why. > Issues are representative as a sampling, not absolute numbers. My point was that issues are not a reliable sample of the Go community as a whole. They're a self-selected population of Go developers who cared enough about generics to click on a Github proposal on the subject and react to it. I'll say it again: >> The majority may not spend their time reading or reacting to proposals they don't care about. Maybe the majority do want generics, but the Github issue is poor evidence. A random sample of Go developers would be much better, and then we wouldn't have to make up things like "And many more want Generics without having responded to the issue."
  - coldtea 9y ago
    >I'm not sure who you're quoting or why. I accidentally re-pasted the same quote from nine_k I've answered to higher up the thread. Meant to quote this from you: "1734 people reacted to the generics issue, most in favor, but there are many more Go developers than that". >* My point was that issues are not a reliable sample of the Go community as a whole. They're a self-selected population of Go developers who cared enough about generics to click on a Github proposal on the subject and react to it.* And my point is that I don't think this is the case. I don't know either way, but there's no reason to assume people caring to vote in the issue are necessarily not representative -- like I don't think that for any other project/issue combo on github. In any case, even if they aren't representative of existing heavy Golang users, who cares about them? The language is still niche. There are tons more programmers to come to the language than those that already are using already. So I would very much pay attention to what those not yet using it but caring enough to vote have to say about it.

lossolo 9y ago

The most vocal group is the always the one that is not happy with someone. Doesn't mean this is majority and often it's not.

jhjwe888 9y ago

It should be obvious to folks on HN why a Github issue that may go completely unseen by a large swath of the go community, or +1's which can be gamed/trolled, should not be taken as a valid measure. But it must be explained I guess.

coldtea 9y ago
Confirmation bias much?

jackmott 9y ago

the guy is just being a dick.

baby 9y ago

Thanks for pointing that out, I went there to downvote the issue.