5 ms·

The article uses "Google" instead of individuals names to make the actions taken seem like sinister actions of a faceless corporation. My interpretation is tha

The article uses "Google" instead of individuals names to make the actions taken seem like sinister actions of a faceless corporation. My interpretation is that Google employs a tight-knit group of people that work on Go and collectively are the BDFLs of the language. This isn't that much different from most large OSS projects, although it does seem likely that this core team weights the opinions of those that they interact with daily (ie, other Google employees) over people they barely know.

silvester23 7y ago
The last two paragraphs of the article address exactly that issue - that it's hard to tell whether the direction of Go development is decided solely by the Go core team or by Google as a corporation.
- kkarakk 7y ago
  ...was this ever in doubt? i've always thought from day 1 that this is "Go as in made by Google". Even the name branding screams that
- divan 7y ago
  Go team is actually incredibly open and approachable if you meet them at conferences. Google (as a company) has little influence on the language design design. Its needs has shaped design (obviously), but it's not like there are requirements outside of the Go team. Go is heavily used in Google, so it's a natural dogfooding process, but that's it.
  - FroshKiller 7y ago
    "If you meet them at conferences" is a huge if of inaccessibility.
    - divan 7y ago
      Haha, sorry, they're open outside of conferences too :)
- jon-wood 7y ago
  I don’t really get this distinction. “Google as a corporation” isn’t a thing, it’s a collection of people, some of whom happen to be the Go core team. It’s likely that due to being close to Go developers at Google there’s a bias towards implementing features that would help those people, but I very much doubt the subject of genetics in Go comes up at board meetings.
  - dx034 7y ago
    Google the corporation is represented by upper management, the people by developers. The question is if upper management at Google takes any influence on the development process.
  - fragmede 7y ago
    Implementing features Google needs sooner, rather than later, is one thing, but at some point, Google-the-profit-driven-corporation's needs will contradict the broader Golang community's needs, at which point the question is who "wins"? What will, on a long enough timeline, come up in board meetings, especially as Google fails to meet Wall Street analyst's expectations, and as the ad-tech space evolves, is how much of Google-the-corporation's money to continue plowing into broader community things, like Golang at all. Hopefully, by the time that happens, the community will be strong enough to persist, and I use Golang professionally, so I have personal investment for that to be true, but the possible eventuality that it'll end up being in the situation Java is currently in, makes me nervous.
- brown9-2 7y ago
  A useful mental exercise here: if the core team left Google, do you think they’d lose power?
- DannyBee 7y ago
  Which is nonsense, and is equivalent in this case to "i never bothered to ask so i'm just going to assert some stuff that agrees with my viewpoint". They could have just asked. In fact I can answer this for you, since I was the relevant director (IE Go directly reported to me) It was driven by the core team, and more particularly, the leads and what they want to be trying to do. I have provided precisely 0% of the vision there. Further, the org/etc they belong to has changed (a very small number of times) over the past 10+ years depending on the Go team goals, not depending on Google's goals. (IE when their goals have changed, or the org goals changed, Google has put them in a place that aligns with their goals, not tried to align them to the goals of the org they belong to)
  - mcguire 7y ago
    So, why is Google paying them? Is Google getting enough value out, or PR, or...?
    - takeda 7y ago
      People are stepping around trying not to offend anyone, but it is no secret that Go was created for Google to solve their needs, it supposed to be a simple language that even a fresh graduate out of school could pick it up quickly and work with it. It is also very opinionated for example regarding the formatting or (at least initially before vgo was introduced due to outside pressure) to work well only in a mono repo scenarios. Google makes it free to use, so it will be easier to recruit people that already know it. Many companies do that as well, the difference is that still generally no one uses their languages. This one is different, because well it's Google. The Go itself isn't really that great language, but there's a lot of hype behind it. I wonder when it will die out, but I guess it will be a while.
    - user5994461 7y ago
      Google is getting tremendous value from Go, on multiple fronts. For reference, Go was meant as an alternative to Java and C++, to develop distributed systems. Given the direction that Java went, acquisition by Oracle and $10B lawsuit against Google, it is a well worth having an alternative.
richardwhiuk 7y ago
The basic question is "Are they on the core team because they work at Google?" - If someone new joined Google, would they immediately get added to the core team, with no history of contributions? - If someone had a long history of contributions, but wasn't hired by Google, could they join the core team? Those two questions are pretty determinate on whether this is a community project or a Google project.
- mcguire 7y ago
  - Probably not? - Maybe? A better question is, "Can you successfully act like you worked at Bell Labs in the 70s and 80s?"
mcguire 7y ago
I don't know the real relationship between Google and Go, but Go is very much a product of its current core team, who are (AFAIK) all veterans of Bell Labs (Robert Griesemer?) and all have the same Bell Labs approach. Bell Labs invented Not Invented Here syndrome. You can know this to be true because there is no way this group of people could have the syndrome so bad any other way. The other side of the coin is that they are very, very good. You can know that because they do a lot of interesting, novel work without obviously (or obviously without) having looked at any other research in that field. Take for example, Chris's comment, "(The most clear and obvious illustration of this is what happened with Go modules, where one member of Google's Go core team discarded the entire system the outside Go community had been working on in favour of a relatively radically different model. See eg for one version of this history.)" The second link there is to https://peter.bourgon.org/blog/2018/07/27/a-response-about-dep-and-vgo.html.[^1][^2] https://peter.bourgon.org/blog/2018/07/27/a-response-about-d... From that: "[RSC and the dep-pies] discussed dep at the GopherCon contributor summit. Matt Farina says that [Russ Cox] said [he] could do better if [he] went off on [his] own and built something. ... The clear impression was that Russ wasn’t going to engage with the committee, the research [the committee] had prepared for him, or the prototype product of that research, dep — at least, not yet. The clear impression was that Russ had his own hypothesis about what a solution would look like, and that he was interested in validating those hypotheses, by himself. ... Russ decided to implement his ideas on his own, and make a proposal without us, and without telling us that’s what he was doing until it was essentially done." This is what I'm talking about. If your ideas suitably mesh with their philosophy, they may be adopted. If they do not, the Bell Labs team will ignore them completely. And if they think the problem is a problem (and they don't, in many, many cases), they are quite capable of doing an end-run around you and producing a solution which satisfies their perception of the problem. Go may or may not be Google's language. Go is the Go-lang team's language and you will go where they want you to go, to adapt MS's old slogan. To an extent, it's similar to Perl; one's success as a Perl programmer depends entirely on your ability to hold your mouth right and successfully simulate Larry Wall. Perl is not a DWIM language, it's a do-what-Larry-would-mean-if-he-wrote-what-you-wrote language. [^1] I myself do not endorse the technical ideas in that post. "[Something] does not support using multiple major versions of a program in a single build. This alone is a complete showstopper." is true. The fact that most tools don't do it---and have to live with the resulting pain---simply means that it's hard, not that it's not necessary. [^2] A previous discussion of Go modules here: https://news.ycombinator.com/item?id=17534923 https://news.ycombinator.com/item?id=17534923

silvester23 7y ago

The last two paragraphs of the article address exactly that issue - that it's hard to tell whether the direction of Go development is decided solely by the Go core team or by Google as a corporation.

kkarakk 7y ago
...was this ever in doubt? i've always thought from day 1 that this is "Go as in made by Google". Even the name branding screams that
divan 7y ago
Go team is actually incredibly open and approachable if you meet them at conferences. Google (as a company) has little influence on the language design design. Its needs has shaped design (obviously), but it's not like there are requirements outside of the Go team. Go is heavily used in Google, so it's a natural dogfooding process, but that's it.
- FroshKiller 7y ago
  "If you meet them at conferences" is a huge if of inaccessibility.
  - divan 7y ago
    Haha, sorry, they're open outside of conferences too :)
jon-wood 7y ago
I don’t really get this distinction. “Google as a corporation” isn’t a thing, it’s a collection of people, some of whom happen to be the Go core team. It’s likely that due to being close to Go developers at Google there’s a bias towards implementing features that would help those people, but I very much doubt the subject of genetics in Go comes up at board meetings.
- dx034 7y ago
  Google the corporation is represented by upper management, the people by developers. The question is if upper management at Google takes any influence on the development process.
- fragmede 7y ago
  Implementing features Google needs sooner, rather than later, is one thing, but at some point, Google-the-profit-driven-corporation's needs will contradict the broader Golang community's needs, at which point the question is who "wins"? What will, on a long enough timeline, come up in board meetings, especially as Google fails to meet Wall Street analyst's expectations, and as the ad-tech space evolves, is how much of Google-the-corporation's money to continue plowing into broader community things, like Golang at all. Hopefully, by the time that happens, the community will be strong enough to persist, and I use Golang professionally, so I have personal investment for that to be true, but the possible eventuality that it'll end up being in the situation Java is currently in, makes me nervous.
brown9-2 7y ago
A useful mental exercise here: if the core team left Google, do you think they’d lose power?
DannyBee 7y ago
Which is nonsense, and is equivalent in this case to "i never bothered to ask so i'm just going to assert some stuff that agrees with my viewpoint". They could have just asked. In fact I can answer this for you, since I was the relevant director (IE Go directly reported to me) It was driven by the core team, and more particularly, the leads and what they want to be trying to do. I have provided precisely 0% of the vision there. Further, the org/etc they belong to has changed (a very small number of times) over the past 10+ years depending on the Go team goals, not depending on Google's goals. (IE when their goals have changed, or the org goals changed, Google has put them in a place that aligns with their goals, not tried to align them to the goals of the org they belong to)
- mcguire 7y ago
  So, why is Google paying them? Is Google getting enough value out, or PR, or...?
  - takeda 7y ago
    People are stepping around trying not to offend anyone, but it is no secret that Go was created for Google to solve their needs, it supposed to be a simple language that even a fresh graduate out of school could pick it up quickly and work with it. It is also very opinionated for example regarding the formatting or (at least initially before vgo was introduced due to outside pressure) to work well only in a mono repo scenarios. Google makes it free to use, so it will be easier to recruit people that already know it. Many companies do that as well, the difference is that still generally no one uses their languages. This one is different, because well it's Google. The Go itself isn't really that great language, but there's a lot of hype behind it. I wonder when it will die out, but I guess it will be a while.
  - user5994461 7y ago
    Google is getting tremendous value from Go, on multiple fronts. For reference, Go was meant as an alternative to Java and C++, to develop distributed systems. Given the direction that Java went, acquisition by Oracle and $10B lawsuit against Google, it is a well worth having an alternative.

richardwhiuk 7y ago

The basic question is "Are they on the core team because they work at Google?" - If someone new joined Google, would they immediately get added to the core team, with no history of contributions? - If someone had a long history of contributions, but wasn't hired by Google, could they join the core team? Those two questions are pretty determinate on whether this is a community project or a Google project.

mcguire 7y ago
- Probably not? - Maybe? A better question is, "Can you successfully act like you worked at Bell Labs in the 70s and 80s?"

mcguire 7y ago

I don't know the real relationship between Google and Go, but Go is very much a product of its current core team, who are (AFAIK) all veterans of Bell Labs (Robert Griesemer?) and all have the same Bell Labs approach. Bell Labs invented Not Invented Here syndrome. You can know this to be true because there is no way this group of people could have the syndrome so bad any other way. The other side of the coin is that they are very, very good. You can know that because they do a lot of interesting, novel work without obviously (or obviously without) having looked at any other research in that field. Take for example, Chris's comment, "(The most clear and obvious illustration of this is what happened with Go modules, where one member of Google's Go core team discarded the entire system the outside Go community had been working on in favour of a relatively radically different model. See eg for one version of this history.)" The second link there is to https://peter.bourgon.org/blog/2018/07/27/a-response-about-dep-and-vgo.html.[^1][^2] https://peter.bourgon.org/blog/2018/07/27/a-response-about-d... From that: "[RSC and the dep-pies] discussed dep at the GopherCon contributor summit. Matt Farina says that [Russ Cox] said [he] could do better if [he] went off on [his] own and built something. ... The clear impression was that Russ wasn’t going to engage with the committee, the research [the committee] had prepared for him, or the prototype product of that research, dep — at least, not yet. The clear impression was that Russ had his own hypothesis about what a solution would look like, and that he was interested in validating those hypotheses, by himself. ... Russ decided to implement his ideas on his own, and make a proposal without us, and without telling us that’s what he was doing until it was essentially done." This is what I'm talking about. If your ideas suitably mesh with their philosophy, they may be adopted. If they do not, the Bell Labs team will ignore them completely. And if they think the problem is a problem (and they don't, in many, many cases), they are quite capable of doing an end-run around you and producing a solution which satisfies their perception of the problem. Go may or may not be Google's language. Go is the Go-lang team's language and you will go where they want you to go, to adapt MS's old slogan. To an extent, it's similar to Perl; one's success as a Perl programmer depends entirely on your ability to hold your mouth right and successfully simulate Larry Wall. Perl is not a DWIM language, it's a do-what-Larry-would-mean-if-he-wrote-what-you-wrote language. [^1] I myself do not endorse the technical ideas in that post. "[Something] does not support using multiple major versions of a program in a single build. This alone is a complete showstopper." is true. The fact that most tools don't do it---and have to live with the resulting pain---simply means that it's hard, not that it's not necessary. [^2] A previous discussion of Go modules here: https://news.ycombinator.com/item?id=17534923 https://news.ycombinator.com/item?id=17534923