21 ms·

One of the thing that's always been a bit off-putting about the Go community and leadership is that it seemed that when I came across things that I perceived as

by treve 8y ago

One of the thing that's always been a bit off-putting about the Go community and leadership is that it seemed that when I came across things that I perceived as flaws in the tooling or language, I often felt told off and was made to feel that it's me who is wrong for a variety of reasons. Examples of this include GOPATH, the package infrastructure, error handling, lack of generics. Rob Pike disagrees so I must be wrong. It's kind of satisfying to see that the "Go way" wasn't the best way after all and that some of these things are actively being addressed. I hope it makes the community a bit more welcoming as well.

cgag 8y ago
Honestly I got the impression no one ever liked gopath.
- revskill 8y ago
  Because setting environment variables is something most devs like to avoid.
  - cgag 8y ago
    No, because I have like 50 projects in ~/src and suddenly have to keep some of my code in ~/src/go/src/GitHub.com/cgag and that annoys me.
    - cyphar 8y ago
      I have tried several times to fix this problem in the past 5 or 6 years, once with symlinks (which would break quite often -- it's unsurprising that Plan 9 developers wouldn't care too much for handling symlinks correctly :P). The current way I handle it is that $HOME/.local is my GOPATH, and $HOME/src links to $HOME/.local/src. So you can just have $HOME/src/github.com/bar/foo -- which is less ideal than just $HOME/src/foo, but it's something at least.
    - revel 8y ago
      it's not just that large numbers of projects are a hassle, they make it harder to develop projects in isolation
    - lenkite 8y ago
      I keep the source code for my projects in ~/src and I always set my GOPATH to my home dir. So the special 'go' in the path can be avoided. It will just be ~/src/github.com/... But, yes, I rolled my eyes when learning about GOPATH for the first time.
- tptacek 8y ago
  I hated it at first but came around over time, to the point where I haven't switched to the modules workflow yet.
  - cyphar 8y ago
    I think a primary problem with the modules workflow is that you can't switch to it until all Go projects you work on switch to it. Plus, all of us have got our own GOPATH home-directory workarounds so there's no real point in switching anymore.
    - atombender 8y ago
      That's not true at all. A Go-modules-enabled project can import packages from a non-modules-enabled project that doesn't have Go.mod in it. This was always the case with Glide and Dep, too.
      - cyphar 8y ago
        That's not what I'm talking about. I'm talking about being able to build outside of GOPATH. This requires the top-level project to use go.mod and many don't (like Docker for instance).
        atombender 8y ago
        But that's not the same thing. You don't have to switch all the projects you work on over to Go modules at the same time, only the projects you want to upgrade. It's entirely possible to migrate incrementally.
    - Merovius 8y ago
      > I think a primary problem with the modules workflow is that you can't switch to it until all Go projects you work on switch to it It seems this gets fixed in Go 1.12 though. AIUI you'll be able to set GOMODULES=on, unset GOPATH and just continue working as before.
  - 8y ago
- zaphar 8y ago
  Pretty much every language has a GOPATH thing. CLASSPATH, PYTHON_PATH, PERL5LIB, ... I never really understand the hate here. It seems more like they didn't hate GOPATH specifically and more that they didn't like not having a package manager.
  - pjmlp 8y ago
    The ones listed by you apply mostly as library search path, while go compilers required GOPATH to point to the project being compiled.
    - kjksf 8y ago
      False. You can put your code anywhere you want and `go build` and `go run` will work just fine. It's only third party libraries that have to be in GOPATH, which is exactly a library (well, package) search path.
      - aeijdenberg 8y ago
        False only for very small values of code. ie if your code itself is split into modules, they won't work (as they are imported by their full path, not relatively), and anything in your vendor dir is also ignored when used outside of a GOPATH entry.
  - dagss 8y ago
    GOPATH behaves very, very differently from PYTHON_PATH and CLASSPATH, it is not the same thing at all. Basically before go 1.11, it was impossible to just do git clone ... somedir cd somedir # build code and run something You had to instead make sure "somedir" ended up somewhere within a particular deep directory structure. That is what people mean when they say "GOPATH".
    - Merovius 8y ago
      > Basically before go 1.11, it was impossible to just do That's not true. It was always perfectly possible to do that, the code you build just couldn't import any libraries not installed in GOPATH. AIUI that is exactly the same as in other languages.
weberc2 8y ago
I don't know. While no doubt some individual conversations have played out this way (law of averages and all that), I think this is a bad way to characterize the overall conversation. From my viewpoint, the conversation is largely people coming from other languages telling the Go community its way is wrong while the people on the Go team argue that there are tradeoffs that they'd like to explore. For example, pretty much every Go-related conversation over at /r/programming seems to have someone arguing that it's literally impossible to build software in a language that lacks generics (or exceptions) while people from the Go community argue that generics are probably worth the tradeoff, and then only if the maintainers can figure out a way to implement generics _well_ (i.e., not like C++ or Java).
- coldtea 8y ago
  >I don't know. While no doubt some individual conversations have played out this way (law of averages and all that), I think this is a bad way to characterize the overall conversation. Most everything I've seen from the Go camp, including the new re-discovery of various wheels with the Go 2.0 proposals, felt like the parent describes to me. Never got the same from Rust, otoh.
  - geodel 8y ago
    See comments for Rust new website thread on reddit and elsewhere. Most Rust community seems mightily pissed off for all negative comments about their newly designed website. Besides Rust enthusiasts have reputation of trolling random people on internet who have unflattering things to say about Rust. Or try opening new thread on Swift forum on issues where decisions have been take. They will quickly put you in place and close the thread. I have yet to see a successful language where whiners are embraced with great enthusiasm.
    - coldtea 8y ago
      >Besides Rust enthusiasts have reputation of trolling random people on internet who have unflattering things to say about Rust. I don't speak about Rust enthusiasts or even the Rust community at large, there are people like that in all languages (though indeed some communities might be better than others, but with large enough numbers of users of a language you get all kinds of people in a similar enough distribution). I speak of the core team. Go's one has a vibe I don't get from Rust's.
skybrian 8y ago
I think this is an example of rounding things off to one bit: either a feature is good or bad. Worse, people will round a language off to one bit: either it's great or terrible. Sometimes this is just due to defensiveness: someone uses a flaw to say the whole language is terrible and that gets a response from people who have learned to live with the flaw. Generally, if you back to the original statements you'll find something more nuanced: generic types have a lot of complicated effects on language design and they didn't like their own early proposals, so they started out without them. Yes, error checking can be repetitive, but many of the attempts to fix that in other languages were worse. In the meantime, the "Go way" is about following common conventions for working within the language's limitations. This isn't a bad thing! But it's tricky to be welcoming while getting across that the best way to deal with limitations is just to accept them, for now. On the Internet, everyone wants to be Steve Jobs and demand changes. (Also: Rob Pike, not Erik.)
- cyphar 8y ago
  > In the meantime, the "Go way" is about following common conventions for working within the language's limitations. Except the problem is that "the Go way" changes in a way that breaks your previously-"working within the language's limitations". An example of this that comes to mind is how the Go 1.5 vendor/ change was done. The community had rallied around several tools that would do vendoring and then would modify GOPATH to include vendor/ and would then symlink the current project into vendor/. All this required was a vendor/src. The Go 1.5 vendor/ implementation was almost identical but they removed the src directory -- which meant that pre-1.5 vendoring was now broken by Go (you can't really have two copies of your vendor tree in a repo and symlinks wouldn't work either). There are a few other examples of this, but this one sticks out as it was the first feeling I got that the Go development team doesn't really care how the community has decided to work around a language defect. It literally would have just taken them one additional directory to not break every vendor/ project. (Also, there has been absolutely no discussion with distributions -- as far as I'm aware -- on how packaging Go binaries should be done so we're all forced to come up with our own ideas. The Go modules stuff has considerations -- like builds requiring an internet connection -- that distributions would've had input on, but we didn't get asked about it.)
- 8y ago
purple_ducks 8y ago
i think the "Go way" was more like: Google have a different in-house solution for this so let's just leave it out and for something to bubble up out of community. Go solves Googles main problem -> something which new engineers can use to write practical solutions without having to think too much. It's not beautiful or expressive or technically interesting; most "craftsman" devs won't stick with it too long..But that's not the majority of devs google is hiring. Sit down, bang out code and don't concern yourself too much with craftmanship - it will be re-written in a couple of years. Just worry about performance.
- cstejerean 8y ago
  And then proceed to shit on whatever did bubble up from the community, at least as far as package management goes. I’m glad we’re finally getting the core team to focus on modules but as an outsider that whole situation was handled poorly and doesn’t give me a lot of faith in solutions bubbling up from the community.
cstejerean 8y ago
I agree completely, that’s precisely the same impression I got. Maybe it was mostly from discussions on HN and it doesn represent the community at large. Whatever the reason I’m glad to see focus on fixing the GOPATH abomination and the plan to finally add generics in Go 2.
deleted 8y ago
[deleted]
latch 8y ago
I wrote a blog post about the error handling. Someone put it on /r/golang (note the subreddit name). There were 22 comments, and the one from the Go developer was (and I quote): "Tempted to stop reading after the first word in the article. (The language isn't called Golang)"
- jaredmosley 8y ago
  Do you happen to have a link to the reddit post or to your article?
  - deleted 8y ago
    [deleted]
  - modernerd 8y ago
    Not the author, but guessing: https://www.reddit.com/r/golang/comments/33k8sp/gos_error_handling_good_and_bad/cqlyxxn https://www.reddit.com/r/golang/comments/33k8sp/gos_error_ha... https://www.openmymind.net/Golangs-Error-Handling-Good-And-Bad/ https://www.openmymind.net/Golangs-Error-Handling-Good-And-B...
- weberc2 8y ago
  That's a really disappointing story. Fortunately these sorts of attitudes aren't common in the Go community.
  - coldtea 8y ago
    Such putdowns are a regular occurrence in Golang-nuts (ironically, the Go team has named their own/list forum "golang-nuts" despite that "not being the name of the language").
    - weberc2 8y ago
      "golang" is the official disambiguation, so it's factually incorrect to call people out for using that term. I don't follow that mailing list particularly closely, but I've not seen anything like this in the threads I have perused. To the extent that these things happen, the community should address this behavior.
zemo 8y ago
the fact that you call Rob Pike "Erik Pike" really reads like the complaints of someone who doesn't do their homework and asks questions that have already been answered in many places. Generics is a major tell, too, since the Go team's position on generics was always "generics are interesting but we don't know how to make them work well with Go's existing type system". See for example, this blog post from 2009: https://research.swtch.com/generic https://research.swtch.com/generic which references the FAQ answer to the generics problem here: https://golang.org/doc/faq#generics https://golang.org/doc/faq#generics: "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." so I can see why people who have repeatedly answered the same question for years, only to have their answer misrepresented for years, to be annoyed when people who haven't read any prior discussion bring up a point that has been already talked about ad nauseam.
- treve 8y ago
  Sorry about mis-remembering his name, but my point was a bit more nuanced. The frustration I had was not that certain features were missing, but I was met with a response that suggested that I was wrong for even wanting these features. It was a comment on my personal experiences of interacting with the Go community, not the language and its limitations. My hope wasn't that Go implements my every pet peeve, my hope is that the community has gained some humility since I last dipped my toes in it. Pike seems especially aggressive when interacting with people he disagrees with and this was for me indicative of the culture. It's been a few years though, so maybe by now I'm wrong! Here's Pike on the topic of syntax highlighting: https://groups.google.com/d/msg/golang-nuts/hJHCAaiL0so/E2mQ1RDiio8J https://groups.google.com/d/msg/golang-nuts/hJHCAaiL0so/E2mQ...
  - rwj 8y ago
    The community has gotten better. Early discussions were frequently marred hype, and it was often impossible to cut through the noise. However, talks given by the authors usually impressed me by being fairly even-handed, and open about the trade-offs that were taken.
jonahx 8y ago
Contemptuous scorn seems to be the officially-sanctioned strategy for responding to reasoned critique or even questions about "the go way" within the community. My favorite example here is this arrogant dismissal of the idea that a one line expression, rather than a 5 line mutating statement, might be preferred for conditionally setting a value: if expr { n = trueVal } else { n = falseVal } > The if-else form, although longer, is unquestionably clearer. A language needs only one conditional control flow construct. [0] ... n = expr ? trueVal : falseVal "Unquestionably" [0] https://golang.org/doc/faq#Does_Go_have_a_ternary_form https://golang.org/doc/faq#Does_Go_have_a_ternary_form
- lsllc 8y ago
  > A language needs only one conditional control flow construct. If by "one" you mean `if` _and_ `switch` then yes!
  - tandr 8y ago
    and `select`
- munificent 8y ago
  What I find particularly off-putting is that this attitude of superiority is sometimes married with objective incorrectness. If you're going to claim something is black and white, it should actually be black and white. &&, ||, switch, select, for, and while all do conditional execution in Go. So the rule is not "A language needs only one conditional control flow construct." The rule is really, "We didn't think a conditional operator was worth it." That's a fine rule, but it's better to be honest about it than to pretend the language was designed around some pure principle that doesn't actually exist.
  - skybrian 8y ago
    Yeah, I agree about it being off-putting. There's very little science in programming language ergonomics, so it all comes down to taste, right? However, I wonder how much of this is a difference in substance and how much is about writing style? There is an older, authoritive style that has an implicit "in our opinion, of course" and sounds pretty grating these days. I remember being taught in school to remove "I think" and qualifiers expressing uncertainty, under the theory that in an opinion piece, that's understood. Especially these days when hyperbole is common, I prefer writers that have a humble writing style, but also try not to get hung up on stylistic differences.
axaxs 8y ago
I was very active in the community at around the 1.0 release time, and probably am guilty of this, so late apologies. The problem in my eyes was that this was a new language that really solved a lot of problems in its simplicity from experience. And we all know design by committee is a disaster. The list was under a -constant- barrage of 'you should do X like language Y.' The general response from the community was along the lines of 'if you like language Y, you should use that, stop polluting the mailing list.' Essentially, it quickly got old with the constant asking of things, many ridiculous, that I feel probably a few good suggestions got thrown out with the weekly trash so to speak.
karmakaze 8y ago
What I've come to learn from using Go on a number of projects and reading the long mailing list threads on topics that lead to the decisions and development of language features is that Go is a language intended for many programmers (e.g. average) to be successful writing systems(-like) software. Officially, it was meant to be for systems software, but it's since expanded beyond that scope. Given that it's designed and developed by very bright authors for everyday programmers, it's actually surprising how much thought has gone into seemingly obvious language features. They want users of the language to be successful more than they want their users ego to be happy about language features. Given that, they do also 'talk down' in their official documentation. I had to look back in time to understand the memory model for the sync.atomic operations which is documented: "These functions require great care to be used correctly. Except for special, low-level applications, synchronization is better done with channels or the facilities of the sync package. Share memory by communicating; don't communicate by sharing memory." The final word on what 'great care' means is that Go doesn't actually have a memory model for this part of the standard library. The discussion thread around it has a different tone than the official documentation. They agree on how they want implementations to operate, but don't feel that it needs to be officially defined or documented. I would have been happy if they at least referenced the discussion thread rather than merely label it 'great care' meaning 'not for you'. The other thing you find is that the performant parts of the standard library often does not follow "Share memory by communicating; don't communicate by sharing memory". One of the betrayals when working with I/O was finding that standard library routines can return a value AND an error, and that sometimes a non-nil error is not an error (EOF is not the only one of these).

by treve 8y ago

cgag 8y ago

Honestly I got the impression no one ever liked gopath.

revskill 8y ago
Because setting environment variables is something most devs like to avoid.
- cgag 8y ago
  No, because I have like 50 projects in ~/src and suddenly have to keep some of my code in ~/src/go/src/GitHub.com/cgag and that annoys me.
  - cyphar 8y ago
    I have tried several times to fix this problem in the past 5 or 6 years, once with symlinks (which would break quite often -- it's unsurprising that Plan 9 developers wouldn't care too much for handling symlinks correctly :P). The current way I handle it is that $HOME/.local is my GOPATH, and $HOME/src links to $HOME/.local/src. So you can just have $HOME/src/github.com/bar/foo -- which is less ideal than just $HOME/src/foo, but it's something at least.
  - revel 8y ago
    it's not just that large numbers of projects are a hassle, they make it harder to develop projects in isolation
  - lenkite 8y ago
    I keep the source code for my projects in ~/src and I always set my GOPATH to my home dir. So the special 'go' in the path can be avoided. It will just be ~/src/github.com/... But, yes, I rolled my eyes when learning about GOPATH for the first time.
tptacek 8y ago
I hated it at first but came around over time, to the point where I haven't switched to the modules workflow yet.
- cyphar 8y ago
  I think a primary problem with the modules workflow is that you can't switch to it until all Go projects you work on switch to it. Plus, all of us have got our own GOPATH home-directory workarounds so there's no real point in switching anymore.
  - atombender 8y ago
    That's not true at all. A Go-modules-enabled project can import packages from a non-modules-enabled project that doesn't have Go.mod in it. This was always the case with Glide and Dep, too.
    - cyphar 8y ago
      That's not what I'm talking about. I'm talking about being able to build outside of GOPATH. This requires the top-level project to use go.mod and many don't (like Docker for instance).
      - atombender 8y ago
        But that's not the same thing. You don't have to switch all the projects you work on over to Go modules at the same time, only the projects you want to upgrade. It's entirely possible to migrate incrementally.
  - Merovius 8y ago
    > I think a primary problem with the modules workflow is that you can't switch to it until all Go projects you work on switch to it It seems this gets fixed in Go 1.12 though. AIUI you'll be able to set GOMODULES=on, unset GOPATH and just continue working as before.
- 8y ago
zaphar 8y ago
Pretty much every language has a GOPATH thing. CLASSPATH, PYTHON_PATH, PERL5LIB, ... I never really understand the hate here. It seems more like they didn't hate GOPATH specifically and more that they didn't like not having a package manager.
- pjmlp 8y ago
  The ones listed by you apply mostly as library search path, while go compilers required GOPATH to point to the project being compiled.
  - kjksf 8y ago
    False. You can put your code anywhere you want and `go build` and `go run` will work just fine. It's only third party libraries that have to be in GOPATH, which is exactly a library (well, package) search path.
    - aeijdenberg 8y ago
      False only for very small values of code. ie if your code itself is split into modules, they won't work (as they are imported by their full path, not relatively), and anything in your vendor dir is also ignored when used outside of a GOPATH entry.
- dagss 8y ago
  GOPATH behaves very, very differently from PYTHON_PATH and CLASSPATH, it is not the same thing at all. Basically before go 1.11, it was impossible to just do git clone ... somedir cd somedir # build code and run something You had to instead make sure "somedir" ended up somewhere within a particular deep directory structure. That is what people mean when they say "GOPATH".
  - Merovius 8y ago
    > Basically before go 1.11, it was impossible to just do That's not true. It was always perfectly possible to do that, the code you build just couldn't import any libraries not installed in GOPATH. AIUI that is exactly the same as in other languages.

weberc2 8y ago

I don't know. While no doubt some individual conversations have played out this way (law of averages and all that), I think this is a bad way to characterize the overall conversation. From my viewpoint, the conversation is largely people coming from other languages telling the Go community its way is wrong while the people on the Go team argue that there are tradeoffs that they'd like to explore. For example, pretty much every Go-related conversation over at /r/programming seems to have someone arguing that it's literally impossible to build software in a language that lacks generics (or exceptions) while people from the Go community argue that generics are probably worth the tradeoff, and then only if the maintainers can figure out a way to implement generics _well_ (i.e., not like C++ or Java).

coldtea 8y ago
>I don't know. While no doubt some individual conversations have played out this way (law of averages and all that), I think this is a bad way to characterize the overall conversation. Most everything I've seen from the Go camp, including the new re-discovery of various wheels with the Go 2.0 proposals, felt like the parent describes to me. Never got the same from Rust, otoh.
- geodel 8y ago
  See comments for Rust new website thread on reddit and elsewhere. Most Rust community seems mightily pissed off for all negative comments about their newly designed website. Besides Rust enthusiasts have reputation of trolling random people on internet who have unflattering things to say about Rust. Or try opening new thread on Swift forum on issues where decisions have been take. They will quickly put you in place and close the thread. I have yet to see a successful language where whiners are embraced with great enthusiasm.
  - coldtea 8y ago
    >Besides Rust enthusiasts have reputation of trolling random people on internet who have unflattering things to say about Rust. I don't speak about Rust enthusiasts or even the Rust community at large, there are people like that in all languages (though indeed some communities might be better than others, but with large enough numbers of users of a language you get all kinds of people in a similar enough distribution). I speak of the core team. Go's one has a vibe I don't get from Rust's.

skybrian 8y ago

I think this is an example of rounding things off to one bit: either a feature is good or bad. Worse, people will round a language off to one bit: either it's great or terrible. Sometimes this is just due to defensiveness: someone uses a flaw to say the whole language is terrible and that gets a response from people who have learned to live with the flaw. Generally, if you back to the original statements you'll find something more nuanced: generic types have a lot of complicated effects on language design and they didn't like their own early proposals, so they started out without them. Yes, error checking can be repetitive, but many of the attempts to fix that in other languages were worse. In the meantime, the "Go way" is about following common conventions for working within the language's limitations. This isn't a bad thing! But it's tricky to be welcoming while getting across that the best way to deal with limitations is just to accept them, for now. On the Internet, everyone wants to be Steve Jobs and demand changes. (Also: Rob Pike, not Erik.)

cyphar 8y ago
> In the meantime, the "Go way" is about following common conventions for working within the language's limitations. Except the problem is that "the Go way" changes in a way that breaks your previously-"working within the language's limitations". An example of this that comes to mind is how the Go 1.5 vendor/ change was done. The community had rallied around several tools that would do vendoring and then would modify GOPATH to include vendor/ and would then symlink the current project into vendor/. All this required was a vendor/src. The Go 1.5 vendor/ implementation was almost identical but they removed the src directory -- which meant that pre-1.5 vendoring was now broken by Go (you can't really have two copies of your vendor tree in a repo and symlinks wouldn't work either). There are a few other examples of this, but this one sticks out as it was the first feeling I got that the Go development team doesn't really care how the community has decided to work around a language defect. It literally would have just taken them one additional directory to not break every vendor/ project. (Also, there has been absolutely no discussion with distributions -- as far as I'm aware -- on how packaging Go binaries should be done so we're all forced to come up with our own ideas. The Go modules stuff has considerations -- like builds requiring an internet connection -- that distributions would've had input on, but we didn't get asked about it.)
8y ago

purple_ducks 8y ago

i think the "Go way" was more like: Google have a different in-house solution for this so let's just leave it out and for something to bubble up out of community. Go solves Googles main problem -> something which new engineers can use to write practical solutions without having to think too much. It's not beautiful or expressive or technically interesting; most "craftsman" devs won't stick with it too long..But that's not the majority of devs google is hiring. Sit down, bang out code and don't concern yourself too much with craftmanship - it will be re-written in a couple of years. Just worry about performance.

cstejerean 8y ago
And then proceed to shit on whatever did bubble up from the community, at least as far as package management goes. I’m glad we’re finally getting the core team to focus on modules but as an outsider that whole situation was handled poorly and doesn’t give me a lot of faith in solutions bubbling up from the community.

cstejerean 8y ago

I agree completely, that’s precisely the same impression I got. Maybe it was mostly from discussions on HN and it doesn represent the community at large. Whatever the reason I’m glad to see focus on fixing the GOPATH abomination and the plan to finally add generics in Go 2.

deleted 8y ago

[deleted]

latch 8y ago

I wrote a blog post about the error handling. Someone put it on /r/golang (note the subreddit name). There were 22 comments, and the one from the Go developer was (and I quote): "Tempted to stop reading after the first word in the article. (The language isn't called Golang)"

jaredmosley 8y ago
Do you happen to have a link to the reddit post or to your article?
- deleted 8y ago
  [deleted]
- modernerd 8y ago
  Not the author, but guessing: https://www.reddit.com/r/golang/comments/33k8sp/gos_error_handling_good_and_bad/cqlyxxn https://www.reddit.com/r/golang/comments/33k8sp/gos_error_ha... https://www.openmymind.net/Golangs-Error-Handling-Good-And-Bad/ https://www.openmymind.net/Golangs-Error-Handling-Good-And-B...
weberc2 8y ago
That's a really disappointing story. Fortunately these sorts of attitudes aren't common in the Go community.
- coldtea 8y ago
  Such putdowns are a regular occurrence in Golang-nuts (ironically, the Go team has named their own/list forum "golang-nuts" despite that "not being the name of the language").
  - weberc2 8y ago
    "golang" is the official disambiguation, so it's factually incorrect to call people out for using that term. I don't follow that mailing list particularly closely, but I've not seen anything like this in the threads I have perused. To the extent that these things happen, the community should address this behavior.

zemo 8y ago

the fact that you call Rob Pike "Erik Pike" really reads like the complaints of someone who doesn't do their homework and asks questions that have already been answered in many places. Generics is a major tell, too, since the Go team's position on generics was always "generics are interesting but we don't know how to make them work well with Go's existing type system". See for example, this blog post from 2009: https://research.swtch.com/generic https://research.swtch.com/generic which references the FAQ answer to the generics problem here: https://golang.org/doc/faq#generics https://golang.org/doc/faq#generics: "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." so I can see why people who have repeatedly answered the same question for years, only to have their answer misrepresented for years, to be annoyed when people who haven't read any prior discussion bring up a point that has been already talked about ad nauseam.

treve 8y ago
Sorry about mis-remembering his name, but my point was a bit more nuanced. The frustration I had was not that certain features were missing, but I was met with a response that suggested that I was wrong for even wanting these features. It was a comment on my personal experiences of interacting with the Go community, not the language and its limitations. My hope wasn't that Go implements my every pet peeve, my hope is that the community has gained some humility since I last dipped my toes in it. Pike seems especially aggressive when interacting with people he disagrees with and this was for me indicative of the culture. It's been a few years though, so maybe by now I'm wrong! Here's Pike on the topic of syntax highlighting: https://groups.google.com/d/msg/golang-nuts/hJHCAaiL0so/E2mQ1RDiio8J https://groups.google.com/d/msg/golang-nuts/hJHCAaiL0so/E2mQ...
- rwj 8y ago
  The community has gotten better. Early discussions were frequently marred hype, and it was often impossible to cut through the noise. However, talks given by the authors usually impressed me by being fairly even-handed, and open about the trade-offs that were taken.

jonahx 8y ago

Contemptuous scorn seems to be the officially-sanctioned strategy for responding to reasoned critique or even questions about "the go way" within the community. My favorite example here is this arrogant dismissal of the idea that a one line expression, rather than a 5 line mutating statement, might be preferred for conditionally setting a value: if expr { n = trueVal } else { n = falseVal } > The if-else form, although longer, is unquestionably clearer. A language needs only one conditional control flow construct. [0] ... n = expr ? trueVal : falseVal "Unquestionably" [0] https://golang.org/doc/faq#Does_Go_have_a_ternary_form https://golang.org/doc/faq#Does_Go_have_a_ternary_form

lsllc 8y ago
> A language needs only one conditional control flow construct. If by "one" you mean `if` _and_ `switch` then yes!
- tandr 8y ago
  and `select`
munificent 8y ago
What I find particularly off-putting is that this attitude of superiority is sometimes married with objective incorrectness. If you're going to claim something is black and white, it should actually be black and white. &&, ||, switch, select, for, and while all do conditional execution in Go. So the rule is not "A language needs only one conditional control flow construct." The rule is really, "We didn't think a conditional operator was worth it." That's a fine rule, but it's better to be honest about it than to pretend the language was designed around some pure principle that doesn't actually exist.
- skybrian 8y ago
  Yeah, I agree about it being off-putting. There's very little science in programming language ergonomics, so it all comes down to taste, right? However, I wonder how much of this is a difference in substance and how much is about writing style? There is an older, authoritive style that has an implicit "in our opinion, of course" and sounds pretty grating these days. I remember being taught in school to remove "I think" and qualifiers expressing uncertainty, under the theory that in an opinion piece, that's understood. Especially these days when hyperbole is common, I prefer writers that have a humble writing style, but also try not to get hung up on stylistic differences.

axaxs 8y ago

I was very active in the community at around the 1.0 release time, and probably am guilty of this, so late apologies. The problem in my eyes was that this was a new language that really solved a lot of problems in its simplicity from experience. And we all know design by committee is a disaster. The list was under a -constant- barrage of 'you should do X like language Y.' The general response from the community was along the lines of 'if you like language Y, you should use that, stop polluting the mailing list.' Essentially, it quickly got old with the constant asking of things, many ridiculous, that I feel probably a few good suggestions got thrown out with the weekly trash so to speak.

karmakaze 8y ago

What I've come to learn from using Go on a number of projects and reading the long mailing list threads on topics that lead to the decisions and development of language features is that Go is a language intended for many programmers (e.g. average) to be successful writing systems(-like) software. Officially, it was meant to be for systems software, but it's since expanded beyond that scope. Given that it's designed and developed by very bright authors for everyday programmers, it's actually surprising how much thought has gone into seemingly obvious language features. They want users of the language to be successful more than they want their users ego to be happy about language features. Given that, they do also 'talk down' in their official documentation. I had to look back in time to understand the memory model for the sync.atomic operations which is documented: "These functions require great care to be used correctly. Except for special, low-level applications, synchronization is better done with channels or the facilities of the sync package. Share memory by communicating; don't communicate by sharing memory." The final word on what 'great care' means is that Go doesn't actually have a memory model for this part of the standard library. The discussion thread around it has a different tone than the official documentation. They agree on how they want implementations to operate, but don't feel that it needs to be officially defined or documented. I would have been happy if they at least referenced the discussion thread rather than merely label it 'great care' meaning 'not for you'. The other thing you find is that the performant parts of the standard library often does not follow "Share memory by communicating; don't communicate by sharing memory". One of the betrayals when working with I/O was finding that standard library routines can return a value AND an error, and that sometimes a non-nil error is not an error (EOF is not the only one of these).