Like it or not, Google is probably paying around a million $$ a year to keep senior full-time developers around that want to work on the language. That could be used as a benchmark to calculate how much of an investment is required to have a healthy development cycle.
If a community-maintained fork is created, it would need time and monetary investment similar to what google is doing just to maintain and develop non-controversial features. Question is: Is this assessment sensible and if so, is the community able or willing to make this kind of investment?
(Source: public git logs for all core Go repos in past year, look for google.com or golang.org emails, multiply by typical Google salaries, which you can find on various sites.)
I read somewhere on mailing list that there are about ~30 people inside Google working full time on Go. And that is different from engineers working on products built using Go.
With infrastructure cost added it would be easily $10 million a year.
So these Linkedin/Twitter style thought leaders demanding some kinda OpenGo foundation need to ask if they have capacity to raise this amount consistently over years to start and run this foundation.
I think, to a degree, the growth in popularity in the language — coupled with the perceived value of whichever changes the current Go team won't make — will determine the viability of a fork.
If the popularity of the language grows enough, there will inevitably be new companies and ecosystems reliant on it and those interests may eventually band together to create forks they think bring value to their businesses.
Outside of that formula, forks will almost always remain niche and without significant investment.
A very well written piece by Ian Lance Taylor. If you don't want to read it all, he summarizes it here:
> In effect, then, the current state is what the blog post suggests at the very end: final decisions about the Go language are made by the core Go team, and the core Go team all work at Google, but there is no meaningful sense in which Google, apart from the core Go team, makes decisions about the language.
> I believe that every successful language must have a
coherent vision that is shared by a relatively small group of people.
He points out that there are over 100 committers, nearly half of which are non-Google; it's only the small group of people in charge of the language spec that are at Google.
It may be true that Google the company don't drive Go the language. However, simply working in the same company tends to make you take on the perspective and values of that company.
In the Xen Project, for instance, Citrix is the largest single contributor. Citrix management have basically left the engineers working in the Xen to our own devices; but nonetheless we've made a conscious effort to diversify the organizational membership of the core decision-makers in the project: partly to make sure that we're not drifting into a Citrix-centric groupthink, and partly to avoid the appearance of Xen being a Citrix-only project.
If I were them, I would be looking for an opportunity to arrange to have at least one non-Googler on the core Go team, for the same reasons.
no successful language-indeed, no successful free software project of any
sort is a democracy [...]
Successful languages pay attention to what people want, but to change
the language according to what most people want is, I believe, a recipe
for chaos and incoherence. I believe that every successful language
must have a coherent vision that is shared by a relatively small group
of people.
which is essentially the "benevolent dictatorship" principle; it's hard to swallow because developers tend to imagine open source projects as "owned by the people".
I believe too that projects "owned by the people" end like The Homer™, and I'm actually curious, as the author, about:
I would be interested to hear of a counter-example
My takeaway from this is that there is no active attempt to influence the direction of Go to fit Google's agenda and that's a good thing. However, active influence isn't necessary to shape Go's direction and functionality. Probably the best example of this are the twin canker sores of GOPATH and dep. Anyone who has wanted to develop multiple projects in isolation has run into issues with these two and the way that they work-but-don't-really. For Google, this doesn't and will never matter because use of blaze / bazel is assumed and any problems relating to GOPATH or dependency management were likely addressed eons ago.
So is this good that the team is crafting the language for their own needs? Perhaps they will keep the language small and keep scope creep to a minimum?
Googler here, but these are my own opinions formed from less than a year at the company.
My observation of Google's culture is that it can be very difficult to see the ways in which they dominate projects they participate in because it's very difficult to keep perspective on how even small investments by Google tend to overwhelm the volume of other contributers project. Google has a lot of great, productive engineers and when they turn those folks fulltime to open source projects the results are very impressive. I feel this too with the open source work I'm adjacent to.
Go's situation is further exacerbated by the somewhat normal expectation at Google that programming systems often feel very top-down mandated to new employees (even if I think reality is that there is just a lot of cultural and tooling inertia there; in reality you can use whatever you want if you can make a case for it). The recent "fix Python's broken batteries" thing comes to mind as a conflict long overdue but suppressed by that culture of top-down mandates. Indeed, even without insider knowledge, rumors speak in hushed tones about how top-down GVR's leadership of Python was during his time working with Google. It seems like after he left, that notion has softened.
So even if folks on the Go project don't mean for it to feel like "google's language", it's still entirely possible that it does feel like Google exercises a lot of control over Go. This is a really significant and old challenge for big companies interacting with open source, but it's one that language teams have only recently started to really face at scale (see also: Rich Hickey's conflict with the Clojure community over overly biasing Clojure towards Datomic's interest and not helping to prioritize or yield resources or his oversight mechanisms to other people's needs).
The Go team was (and has been) also been slow to address the community's obvious and vocal need for some sort of templating solution. While it's fair to appreciate the difficulty of these discussions and designs, it's also the case that the Go project communicated their reservations rather poorly and created a lot of ill will that the language still suffers from today.
As languages are starting to open up and become more community driven (again, it used to be a lot more like this with small scripting language communities), the difference between a carefully guided language like Go and a language where anyone an contribute all the way down to the compiler and have a fair expectation of getting it included (like Haskell's GHC project) start to really contrast.
There are many of us in the Go community who like Go the way it is. The last thing we want is another Java ecosystem, which feels like something designed by archonaut committee more than anything coherent. Better to not have generics than to have generics that are bodged into the language like they were in Java.
There is a notion here that the community is unified and all the core team needs to do is listen to the community and do what they say. In reality the community is too large to get a grip on and has conflicting ideas. You can run polls and read online arguments but in the end this won't result in a design.
There is a good point about fulltime, and nothing specific to either go or google.
Lots of opensource projects get by largely on the evenings-and-weekends contributions of a (often small) number of contributors. Sometimes managing to find resources for a full time person or two at the core.
There are a ton of great, productive engineers out there. Some of them contribute across a number of projects in their "spare" time. It's easy to understate the impact even a small, mostly full time (or at least solidly part-time) team can make on a project.
Any company willing to put it's money where its proverbial mouth is like this can easily start to significantly affect the direction of all but the largest OS projects. You don't have to be google sized, you just have to effectively vote with hours (e.g. $) spent. The governance model of the project may help or hinder this to some degree, but in the end results speak (or a fork is likely).
Go is not the only such project. For how long did linux hw decoding patch for chromium wait for being merge?
And it's still not merged because of the "maintenance burden" (needless to say big linux distros maintain this patch and apply it to their chromium packages just fine).
Android hw support is merged, no problems. Oh, and Chromium OS has hw decoding as well, while having 0.0001% market share. Because it's a google's product.
For google open source is nothing but a way to obtain free labor and make more money. These are their products, meant to make money for them. Others are mere free contributors.
> Rich Hickey's conflict with the Clojure community over overly biasing Clojure towards Datomic's interest
I’m not sure I would describe it that way. I don’t know of anything in Clojure language that is biased towards Datomic’s interest (or Cognitec’s). The conflict was about Rich not having enough time to consider/review/accept changes to the language core and declining to relax acceptance of such changes without his sign off. It’s a problem and it doesn’t sit well with some people in the community, but it really is very different from your accusation.
> Successful languages pay
attention to what people want, but to change the language according to
what most people want is, I believe, a recipe for chaos and
incoherence. I believe that every successful language must have a
coherent vision that is shared by a relatively small group of people.
I'm continually surprised that more of the greater, vocal community does not grok this.
The fact that Golang has no generic is a huge thing. I've read countless amount of code that abused generics (unfortunarely developers think they have to use generics all the time if they are available) and is probably completely insecure for the simple reason that very few people manage to audit/understand the code. If it generics could only be used when necessary, yes, but there are no technical way to enforce this.
Gofmt is the second blessing. All codebases look the same because it is not customizable. This makes reading Golang code and understanding it fast as hell.
The GOPATH is also a huge win. You always know where everything is and it is really fast to figure out about dependencies or structure of the project.
What I'm saying is that in my years of security consulting, Golang codebases have always been the clearest ones to read and have always been the most secure ones.
I feel like a lot of the negative perspectives are given from the writing point of view, but the reading perspective is clearly a huge win for Golang.
Everyone's upset that Go is Google's language, but no one would have adopted it if it weren't. It's not enough to have a cool idea for a language, even if your cool idea is not to put any new cool ideas in the language. You have to be Mozilla, or Google, or someone it seems in order to convince people this language is for real and will be supported for many years to come, and will have a healthy ecosystem. If I had made Go, no one would be using it right now. Network effects matter in languages. People want all the upsides of the network effects (i.e. the ecosystem and adoption), but none of the downsides (it's propped up by a big company with massive network effects).
History doesn't really support that. PHP, Python, Ruby, Tcl, OCaml, Lua. Successful programming languages seem to come in equal measures from both large corporate backers and not.
There is certainly the need for network effects which large corporations often can provide more consistently, but we have seen plenty of examples within the space where individuals or smaller companies have been successful in providing these same network effects.
is that actually true or is that true of a vocal minority? I've been using Go since 2011 and I'm perfectly happy that it's Google's language; I'm happy to mooch off of their investments. In my seven-plus years of using Go I have never encountered a Go programmer in real life that is actually mad about this.
If I had made Go, no one would be using it right now.
It would be really frustrating for you, because assuming people found out about your language in the first place, it would be shot down for not having generics (or something else), and there wouldn’t be any Google fanboys to come defend it. So much of what’s popular is determined by which company is backing it, whether people want to admit that or not. Pure bandwagoning.
I know of more than one organization that have decided against Angular in recent years primarily because of Google's backing of the project. Skepticism of the big three (four?) tech giants is growing, especially if you've had some of your market carved out by them.
Pleasing all pleases noone. Successful products and projects come from a vision that is executed with discipline. Design by committee never works if the committee reaches a certain size. Instead of whining and trying to sabotage Go, why don't you fork it and apply your misguided product management ideas to the soon-to-be-forgotten fork instead? Applause to the Go core team, inside Google or outside it, for creating a great language. Please keep it up!
> Everyone's upset that Go is Google's language, but no one would have adopted it if it weren't.
Brand recognition is not that important for programming languages. It does skew decisions a bit, but people still have to make too many of them when moving to another programming language, so the effect is not that significant. Go just happened to hit all the right spots for many programmers at the time and a bit of marketing turned that into some adoption.
> Everyone's upset that Go is Google's language, but no one would have adopted it if it weren't.
I guess because it does not merit that adoption. The only reason it gets attention at all is either 1) "oh it's made by the same people who made UNIX and C and UTF-8", or 2) "oh it's made by Google".
> ...but no one would have adopted it if it weren't.
It's a C-like language with GC, that compiles to native code supported by an efficient runtime, and can work effectively with parallel/concurrent code. In many ways it's Java done right, or a more intuitive (and from certain POVs, preferable) alternative to Haskell and Ocaml. That would seem to be enough to drive adoption.
“It Is Difficult to Get a Man to Understand Something When His Salary Depends Upon His Not Understanding It” —- Google employee’s defenses of Go
Even if it is theoretically true that Go is open source, by employing the majority of the Core Go team, Google exercises extensive soft power over Go. All of the defenses of Go seem to gloss over this.
>The blog post starts by quoting @kapoorsunny asking why there can't be something like OpenGo, with a community implementation of generics. I hope that it is clear that the answer is that there could be. Nothing prevents that from happening. In particular, Google doesn't prevent that from happening.
No, but like with the community developed dependency solution, Google can arbitrarily chose not to include it in Go, even if itself proves successful.
So it's more like saying "you can have your own niche ports, just don't expect them to become part of the main language".
I feel like some people/groups are obsessed with community owned/open source languages/infrastructure. At the end of the day, most of these are controlled by a small group of individuals and we put different wrappers around them/labels...
I recall a time when Google's SVP of Engineering saw some of us in
the cafeteria and congratulated us on a release; this was surprising
since we hadn't released anything recently, and it soon came up that
he thought we were working on the Dart language, not the Go language.
That's a great little story. As an IC, I always felt that VP's, Staff, etc would know everything about what was going on in their organization. This story lets me know that even at that level, they don't know everything.
Honestly, I'm very confused by all this. Don't like it, fork it no? Isn't that the whole point of open source? Any project needs to have a certain set of people in charge of making actual decisions and working on those. You'll never have every single user be a part of that decision making. It wouldn't scale.
What language is not driven by a handful of decision maker? Even what could be argued to be committee driven languages, like say Java, are very much controlled by a handful of committee members.
It's hard to trust a bunch of people employed by a megacorp to make all the decisions about the project you rely on. But easier to trust independent people, closer to the users, maybe even voted in by the users, like democracies do, not like top down only ruler's interests matter dictatorships.
No. Forking a language is very difficult from forking an application (which is itself a Herculean task if the app is big). And few end-users of a piece of software will switch to a fork with much less backing because of soft-power influence or governance model.
Is there any incident where a patch that was antithetical to Google’s business interests that was specifically blocked by the Go core team? If not, then I’d say there’s nothing to see here.
> those executives, and upper management in general, have never made any attempt to affect how the Go language and tools and standard library are developed
Power and control aren't about whether you've attempted to change something, they're about whether you can change something.
If Google ever had a conflict between the core Go team vs the people who make money for the company, you can be sure who will win out in that debate. Saying that it's never happened before or that it's unlikely to happen doesn't change the fundamental power dynamics that people are upset about.
>> I do think that it will be interesting to see what happens if someone
on the core Go team decides to leave Google and but wants to continue
working on Go.
Or, what would happen if non-google employees on the core Go team were to take Go in a direction that Google's leadership didn't want to?
I definitely feel that Google owns Go and it is a language designed for Google's purposes, but that didn't dissuade me from using it. It only makes me not want to contribute to the core language, just as Google's control over Chrome makes me not want to contribute to chromium.
Keep reading; further down the thread, Rob "Commander" Pike found it "a surprise" that Google trademarked Go. Maybe Pike feels that Go isn't Google's language, but it certainly seems that Google does indeed have a modicum of control over Go, and that that control is above and beyond the Go authors' perception.
> Many people will provide input to this decision, but no successful language--indeed, no successful free software project of any sort--is a democracy. [..]
> As I said, that is my opinion, but I think it's true. I would be interested to hear of a counter-example.
Debian is 1000+ developers with a constitution and voting system.
So if it isn't Google's language, does it mean i can go and make my own compiler for it, call it -say- "Crinus Go" (to differentiate it from Google's Go but still point out that it is an implementation of Go) and not worry about Google coming after me?
Go is a Thompson/Pike language and neither suffer fools gladly. I've had only the briefest, AUUG and related unix conference type interaction with either and claim no special privilege or insight but I do know people who worked with them in a deeper sense, and I spoke to them in times past about both people (and Ritche)
If they decide on their own formidable intellect they want something they do it, and if they can be convinced by others intellect they may do it, but simply wanting it is not enough to get over their bar.
Pike is more curt. But I think both of them stand by a principle: Don't waste our time.
[+] [-] nurettin|6 years ago|reply
If a community-maintained fork is created, it would need time and monetary investment similar to what google is doing just to maintain and develop non-controversial features. Question is: Is this assessment sensible and if so, is the community able or willing to make this kind of investment?
[+] [-] bradfitz|6 years ago|reply
(Source: public git logs for all core Go repos in past year, look for google.com or golang.org emails, multiply by typical Google salaries, which you can find on various sites.)
[+] [-] geodel|6 years ago|reply
So these Linkedin/Twitter style thought leaders demanding some kinda OpenGo foundation need to ask if they have capacity to raise this amount consistently over years to start and run this foundation.
[+] [-] jeffalyanak|6 years ago|reply
If the popularity of the language grows enough, there will inevitably be new companies and ecosystems reliant on it and those interests may eventually band together to create forks they think bring value to their businesses.
Outside of that formula, forks will almost always remain niche and without significant investment.
[+] [-] nickcw|6 years ago|reply
> In effect, then, the current state is what the blog post suggests at the very end: final decisions about the Go language are made by the core Go team, and the core Go team all work at Google, but there is no meaningful sense in which Google, apart from the core Go team, makes decisions about the language.
[+] [-] gwd|6 years ago|reply
> I believe that every successful language must have a coherent vision that is shared by a relatively small group of people.
He points out that there are over 100 committers, nearly half of which are non-Google; it's only the small group of people in charge of the language spec that are at Google.
It may be true that Google the company don't drive Go the language. However, simply working in the same company tends to make you take on the perspective and values of that company.
In the Xen Project, for instance, Citrix is the largest single contributor. Citrix management have basically left the engineers working in the Xen to our own devices; but nonetheless we've made a conscious effort to diversify the organizational membership of the core decision-makers in the project: partly to make sure that we're not drifting into a Citrix-centric groupthink, and partly to avoid the appearance of Xen being a Citrix-only project.
If I were them, I would be looking for an opportunity to arrange to have at least one non-Googler on the core Go team, for the same reasons.
[+] [-] pizza234|6 years ago|reply
I believe too that projects "owned by the people" end like The Homer™, and I'm actually curious, as the author, about:
[+] [-] brianberns|6 years ago|reply
That's like saying that there's no meaningful sense in which I, apart from my brain and nervous system, make decisions about what my body does.
[+] [-] revel|6 years ago|reply
[+] [-] gigatexal|6 years ago|reply
[+] [-] KirinDave|6 years ago|reply
My observation of Google's culture is that it can be very difficult to see the ways in which they dominate projects they participate in because it's very difficult to keep perspective on how even small investments by Google tend to overwhelm the volume of other contributers project. Google has a lot of great, productive engineers and when they turn those folks fulltime to open source projects the results are very impressive. I feel this too with the open source work I'm adjacent to.
Go's situation is further exacerbated by the somewhat normal expectation at Google that programming systems often feel very top-down mandated to new employees (even if I think reality is that there is just a lot of cultural and tooling inertia there; in reality you can use whatever you want if you can make a case for it). The recent "fix Python's broken batteries" thing comes to mind as a conflict long overdue but suppressed by that culture of top-down mandates. Indeed, even without insider knowledge, rumors speak in hushed tones about how top-down GVR's leadership of Python was during his time working with Google. It seems like after he left, that notion has softened.
So even if folks on the Go project don't mean for it to feel like "google's language", it's still entirely possible that it does feel like Google exercises a lot of control over Go. This is a really significant and old challenge for big companies interacting with open source, but it's one that language teams have only recently started to really face at scale (see also: Rich Hickey's conflict with the Clojure community over overly biasing Clojure towards Datomic's interest and not helping to prioritize or yield resources or his oversight mechanisms to other people's needs).
The Go team was (and has been) also been slow to address the community's obvious and vocal need for some sort of templating solution. While it's fair to appreciate the difficulty of these discussions and designs, it's also the case that the Go project communicated their reservations rather poorly and created a lot of ill will that the language still suffers from today.
As languages are starting to open up and become more community driven (again, it used to be a lot more like this with small scripting language communities), the difference between a carefully guided language like Go and a language where anyone an contribute all the way down to the compiler and have a fair expectation of getting it included (like Haskell's GHC project) start to really contrast.
[+] [-] tomohawk|6 years ago|reply
[+] [-] skybrian|6 years ago|reply
[+] [-] ska|6 years ago|reply
Lots of opensource projects get by largely on the evenings-and-weekends contributions of a (often small) number of contributors. Sometimes managing to find resources for a full time person or two at the core.
There are a ton of great, productive engineers out there. Some of them contribute across a number of projects in their "spare" time. It's easy to understate the impact even a small, mostly full time (or at least solidly part-time) team can make on a project.
Any company willing to put it's money where its proverbial mouth is like this can easily start to significantly affect the direction of all but the largest OS projects. You don't have to be google sized, you just have to effectively vote with hours (e.g. $) spent. The governance model of the project may help or hinder this to some degree, but in the end results speak (or a fork is likely).
[+] [-] ernst_klim|6 years ago|reply
Go is not the only such project. For how long did linux hw decoding patch for chromium wait for being merge?
And it's still not merged because of the "maintenance burden" (needless to say big linux distros maintain this patch and apply it to their chromium packages just fine).
Android hw support is merged, no problems. Oh, and Chromium OS has hw decoding as well, while having 0.0001% market share. Because it's a google's product.
For google open source is nothing but a way to obtain free labor and make more money. These are their products, meant to make money for them. Others are mere free contributors.
[+] [-] keymone|6 years ago|reply
I’m not sure I would describe it that way. I don’t know of anything in Clojure language that is biased towards Datomic’s interest (or Cognitec’s). The conflict was about Rich not having enough time to consider/review/accept changes to the language core and declining to relax acceptance of such changes without his sign off. It’s a problem and it doesn’t sit well with some people in the community, but it really is very different from your accusation.
[+] [-] xyzzy_plugh|6 years ago|reply
I'm continually surprised that more of the greater, vocal community does not grok this.
[+] [-] baby|6 years ago|reply
The fact that Golang has no generic is a huge thing. I've read countless amount of code that abused generics (unfortunarely developers think they have to use generics all the time if they are available) and is probably completely insecure for the simple reason that very few people manage to audit/understand the code. If it generics could only be used when necessary, yes, but there are no technical way to enforce this.
Gofmt is the second blessing. All codebases look the same because it is not customizable. This makes reading Golang code and understanding it fast as hell.
The GOPATH is also a huge win. You always know where everything is and it is really fast to figure out about dependencies or structure of the project.
What I'm saying is that in my years of security consulting, Golang codebases have always been the clearest ones to read and have always been the most secure ones.
I feel like a lot of the negative perspectives are given from the writing point of view, but the reading perspective is clearly a huge win for Golang.
[+] [-] c3534l|6 years ago|reply
[+] [-] bigtunacan|6 years ago|reply
There is certainly the need for network effects which large corporations often can provide more consistently, but we have seen plenty of examples within the space where individuals or smaller companies have been successful in providing these same network effects.
[+] [-] zemo|6 years ago|reply
is that actually true or is that true of a vocal minority? I've been using Go since 2011 and I'm perfectly happy that it's Google's language; I'm happy to mooch off of their investments. In my seven-plus years of using Go I have never encountered a Go programmer in real life that is actually mad about this.
[+] [-] booleandilemma|6 years ago|reply
It would be really frustrating for you, because assuming people found out about your language in the first place, it would be shot down for not having generics (or something else), and there wouldn’t be any Google fanboys to come defend it. So much of what’s popular is determined by which company is backing it, whether people want to admit that or not. Pure bandwagoning.
[+] [-] tacosx|6 years ago|reply
[+] [-] rlonn|6 years ago|reply
[+] [-] edoceo|6 years ago|reply
Folk were using that Go, but they would use the Google Go.
[+] [-] smnscu|6 years ago|reply
This made me think of this (thank you for reminding me about it, by the way):
https://vlang.io/
Really looking forward to see where Alex will take this project.
[+] [-] unknown|6 years ago|reply
[deleted]
[+] [-] zzzcpan|6 years ago|reply
Brand recognition is not that important for programming languages. It does skew decisions a bit, but people still have to make too many of them when moving to another programming language, so the effect is not that significant. Go just happened to hit all the right spots for many programmers at the time and a bit of marketing turned that into some adoption.
[+] [-] javajosh|6 years ago|reply
Counter-examples: Clojure, Elm.
[+] [-] fredmorcos|6 years ago|reply
I guess because it does not merit that adoption. The only reason it gets attention at all is either 1) "oh it's made by the same people who made UNIX and C and UTF-8", or 2) "oh it's made by Google".
[+] [-] Rerarom|6 years ago|reply
[+] [-] pictur|6 years ago|reply
[+] [-] objektif|6 years ago|reply
[+] [-] 0815test|6 years ago|reply
It's a C-like language with GC, that compiles to native code supported by an efficient runtime, and can work effectively with parallel/concurrent code. In many ways it's Java done right, or a more intuitive (and from certain POVs, preferable) alternative to Haskell and Ocaml. That would seem to be enough to drive adoption.
[+] [-] et2o|6 years ago|reply
Even if it is theoretically true that Go is open source, by employing the majority of the Core Go team, Google exercises extensive soft power over Go. All of the defenses of Go seem to gloss over this.
[+] [-] coldtea|6 years ago|reply
No, but like with the community developed dependency solution, Google can arbitrarily chose not to include it in Go, even if itself proves successful.
So it's more like saying "you can have your own niche ports, just don't expect them to become part of the main language".
[+] [-] Blackstone4|6 years ago|reply
[+] [-] joeblau|6 years ago|reply
[+] [-] didibus|6 years ago|reply
What language is not driven by a handful of decision maker? Even what could be argued to be committee driven languages, like say Java, are very much controlled by a handful of committee members.
[+] [-] zzzcpan|6 years ago|reply
[+] [-] einpoklum|6 years ago|reply
[+] [-] reilly3000|6 years ago|reply
[+] [-] mabbo|6 years ago|reply
Power and control aren't about whether you've attempted to change something, they're about whether you can change something.
If Google ever had a conflict between the core Go team vs the people who make money for the company, you can be sure who will win out in that debate. Saying that it's never happened before or that it's unlikely to happen doesn't change the fundamental power dynamics that people are upset about.
[+] [-] d0m|6 years ago|reply
Or, what would happen if non-google employees on the core Go team were to take Go in a direction that Google's leadership didn't want to?
[+] [-] blaisio|6 years ago|reply
[+] [-] boapnuaput|6 years ago|reply
[+] [-] infinity0|6 years ago|reply
> As I said, that is my opinion, but I think it's true. I would be interested to hear of a counter-example.
Debian is 1000+ developers with a constitution and voting system.
[+] [-] Crinus|6 years ago|reply
[+] [-] loeg|6 years ago|reply
[+] [-] ggm|6 years ago|reply
If they decide on their own formidable intellect they want something they do it, and if they can be convinced by others intellect they may do it, but simply wanting it is not enough to get over their bar.
Pike is more curt. But I think both of them stand by a principle: Don't waste our time.