Google's Go Lead: the Language Belongs To the Community (google.com) 60
Russ Cox (along with Rob Pike) is the tech lead for Google's Go team and its Go project. This week he responded on the Google group golang-nuts to a blogger who'd argued that "Go is Google's language, not ours."
First Cox points to a talk at Gophercon 2015 -- and its accompanying blog post -- which argued that Go's open source status is critical to its long-term success. He noted this week that "good ideas come from outside Google as often as they come from inside Google.... But getting to yes on every suggested new feature is not and never has been a goal." No one can speak for the entire Go community: it is large, it contains multitudes. As best we can, we try to hear all the many different perspectives of the Go community. We encourage bug reports and experience reports, and we run the annual Go user survey, and we hang out here on golang-nuts and on gophers slack precisely because all those mechanisms help us hear you better. We try to listen not just to the feature requests but the underlying problems people are having, and we try, as I said in the Gophercon talk, to find the small number of changes that solve 90% of the problems instead of the much more complex solution that gets to 99%. We try to add as little as possible to solve as much as possible.
In short, we aim to listen to everyone's problems and address as many of them as possible, but at the same time we don't aim to accept everyone's offered solutions. Instead we aim to create space for thoughtful discussions about the offered solutions and revisions to them, and to work toward a consensus about how to move forward...
The "proposal review" group meets roughly weekly to review proposal issues and make sure the process is working. We handle trivial yes and trivial no answers, but our primary job is to shepherd suggested proposals, bring in the necessary voices, and make sure discussions are proceeding constructively. We have talked in the past about whether to explicitly look for people outside Google to sit in our weekly meeting, but if that's really important, then we are not doing our job right. Again, our primary job is to make sure the issues get appropriate discussion on the issue tracker, where everyone can participate, and to lead that discussion toward a solution with broad agreement and acceptance. If you skim through any of the accepted proposals you will see how we spend most of our meetings nudging conversations along and trying to make sure we hear from everyone who has a stake in a particular decision.
It remains an explicit goal to enable anyone with a good piece of code or a good idea to be able to contribute it to the project, and we've continued to revise both the code contribution and proposal contribution docs as we find gaps. But as I said in 2015, the most important thing we the original authors of Go can do is to provide consistency of vision, to keep Go feeling like a coherent system, to keep Go Go. People may disagree with individual decisions. We may get some flat wrong. But we hope that the overall result still works well for everyone, and the decision process we have seems far more likely to preserve a coherent, understandable system than a standards committee or other process.
His conclusion? The Go language belongs to the Go community -- and, because it's open source, "the freedom to fork hopefully keeps me and the other current Go leadership honest."
First Cox points to a talk at Gophercon 2015 -- and its accompanying blog post -- which argued that Go's open source status is critical to its long-term success. He noted this week that "good ideas come from outside Google as often as they come from inside Google.... But getting to yes on every suggested new feature is not and never has been a goal." No one can speak for the entire Go community: it is large, it contains multitudes. As best we can, we try to hear all the many different perspectives of the Go community. We encourage bug reports and experience reports, and we run the annual Go user survey, and we hang out here on golang-nuts and on gophers slack precisely because all those mechanisms help us hear you better. We try to listen not just to the feature requests but the underlying problems people are having, and we try, as I said in the Gophercon talk, to find the small number of changes that solve 90% of the problems instead of the much more complex solution that gets to 99%. We try to add as little as possible to solve as much as possible.
In short, we aim to listen to everyone's problems and address as many of them as possible, but at the same time we don't aim to accept everyone's offered solutions. Instead we aim to create space for thoughtful discussions about the offered solutions and revisions to them, and to work toward a consensus about how to move forward...
The "proposal review" group meets roughly weekly to review proposal issues and make sure the process is working. We handle trivial yes and trivial no answers, but our primary job is to shepherd suggested proposals, bring in the necessary voices, and make sure discussions are proceeding constructively. We have talked in the past about whether to explicitly look for people outside Google to sit in our weekly meeting, but if that's really important, then we are not doing our job right. Again, our primary job is to make sure the issues get appropriate discussion on the issue tracker, where everyone can participate, and to lead that discussion toward a solution with broad agreement and acceptance. If you skim through any of the accepted proposals you will see how we spend most of our meetings nudging conversations along and trying to make sure we hear from everyone who has a stake in a particular decision.
It remains an explicit goal to enable anyone with a good piece of code or a good idea to be able to contribute it to the project, and we've continued to revise both the code contribution and proposal contribution docs as we find gaps. But as I said in 2015, the most important thing we the original authors of Go can do is to provide consistency of vision, to keep Go feeling like a coherent system, to keep Go Go. People may disagree with individual decisions. We may get some flat wrong. But we hope that the overall result still works well for everyone, and the decision process we have seems far more likely to preserve a coherent, understandable system than a standards committee or other process.
His conclusion? The Go language belongs to the Go community -- and, because it's open source, "the freedom to fork hopefully keeps me and the other current Go leadership honest."
Yes, in short Google owns it (Score:1)
Basically the unnecessarily long justification in the fking summary is that
"Just trust us, we listen to everyone before we take the decisions! really!"
That doesn't mean the community own it. It means Google owns it, but we pinky promise to listen.
Fuck Google. The previous article is right. They never claimed that Google is making wrong decisions, but that structurally Google totally controls it. Which by their own admission of the structure is totally TRUE.
Does Go have a Moderation Team? (Score:1)
Does Go have the equivalent of Rust's Moderation Team? If not, then how does the Go community ensure that any dissent or independent thinking is quickly and thoroughly crushed?
Listen to Ricky (Score:3)
"Good ideas come from outside Google as often as they come from inside Google.... But getting to yes on every suggested new feature is not and never has been a goal."
It’s all right now,
I’ve learned my lesson well,
It seems you can’t please everyone, so
You gotta please yourself.
The last sucessful compiler fork... (Score:1)
Was egcs, which got refactored back into gcc, bloating the codebase, and leading to a 20 year mess under the 'new' leadership.
Reimplementations don't work either for non-trivial projects. It is why Linux is so different and incompatible with both Minix and the BSDs, or even the BSDs from each other.
Implementing compatibly is *HARD* unless you have the exact same people trying to implement the exact same features... and just as often if you hand those same people the same problem at different times in their
Re: (Score:2)
It is why Linux is so different and incompatible with both Minix and the BSDs, or even the BSDs from each other.
The BSDs and Linux aren't very different from each other. Neither is OSX, really. That's why most software for one or the other can run on the other ones.
Reimplementations don't work either for non-trivial projects
The only question is whether you can clearly define the interface. If you can, then it's doable. The biggest problem people run into is time estimation: they expect to rewrite in a few months something that took a decade to write in the first place. Unrealistic.
Re:The last sucessful compiler fork... (Score:4, Insightful)
egcs, which got refactored back into gcc, bloating the codebase, and leading to a 20 year mess under the 'new' leadership
You are an idiot. GCC is of course really EGCS, which won the fork because it was the better compiler. GCC basically compiles the internet. Has done so for all of those 20 years. GCC leads the pack of C++ compilers. GCC -O3 optimization is awesome, like hand written assembler. I could go on but why should I? You are an idiot.
Re: (Score:1)
Confirmed you are an idiot. Why should I be surprised?
Re: (Score:2)
GCC -O3 optimization is awesome, like hand written assembler
For x86 perhaps, but on other architectures it varies a lot. The official ARM compiler is LLVM now, which might tell you something.
Don't get me wrong, I love GCC, but let's be realistic about this.
What a load of BS. (Score:5, Interesting)
Programming languages that lack a formal specification are owned by the original compiler project specifically because they can modified on a whim and because it's the original, every other compiler is forced to follow or suddenly brand itself as a supporting a different programming language. After and ONLY after an open formal specification is released for a programming language does it truly belong to the people. Until they do this, he's just saying nice things to make you feel better. Rust is owned by Mozilla and Go is owned by Google. Anyone who tells you any different is likely a fool or a liar.
Re: (Score:2)
http://wiki.c2.com/?TheKenThom... [c2.com]
What shows you of I think about Go . . .
Re: (Score:1)
This week he responded on the Google group golang-nuts to a blogger who'd argued that "Go is Google's language, not ours."
Except that all he actually did was give a non-response. He doesn't actually give any meaningful response to the complaints people have and instead just spouts the same old standard patronizing bullshit of "We hear you. We're listening to you. We are looking at all your suggestions."
But in actual practice, they are completely ignoring the Go community and just doing what they want to do.
Re:What a load of BS. (Score:4, Informative)
But in actual practice, they are completely ignoring the Go community and just doing what they want to do.
Their decisions seem good to me.
Re: (Score:2)
Their decisions seem good to me.
Some of their decisions have been good, some have been bad, and some have been terrible. Let's be careful to not deify them (I'm not suggesting you are doing that); they're only human after all.
Some decisions that I personally think have been bad or terrible are lack of explicit interfaces, lack of generics from the start causing interface{} abuse and the resulting lack of type safety, and lack of goroutine local storage forcing context to be passed to all sorts of weird and unexpected places it shouldn't h
Re: (Score:2)
lack of goroutine local storage forcing context to be passed to all sorts of weird and unexpected places it shouldn't have to be.
This doesn't seem bad to me, it seems like the right thing to do. If you are trying to understand a codebase, have everything explicitely passed in is easier to reason about because you don't have side effects (or worse, invisible side effects that happen because someone overloaded something that is not normally overloaded). This is the pure functional programming style.
lack of explicit interfaces, lack of generics from the start causing interface{} abuse and the resulting lack of type safety
They are not big on type safety, that's true.
Re: (Score:2)
Rust is owned by Mozilla and Go is owned by Google.
I trust Mozilla a whole lot more than I trust Google and its kooky smart people mythology.
Re: (Score:3)
Then you should know that one a handful of the people working on the core language is actively trying discourage the use and demanding the halt of the development of mrustc [github.com], an alternative Rust compiler. You should not trust corporations because they do not have your interests in mind, only their own.
Re: (Score:2)
Thanks for the heads up, however I stand by my original statement.
Re: (Score:2)
I did a quick search and couldn't find these demands. Are they not public? Where should I look?
Re: (Score:2)
Mailing lists and IRC channels.
Re: (Score:2)
Are any of those lists public? Usually those kinds of lists are archived somewhere.
Go has a published formal specification (Score:2)
Ownership=control (Score:2)
Agreed. The defining characteristic of ownership is control. Can the community change Go in a way that Google doesn't approve of? No? Then they don't own it, Google does.
Admittedly being open source means that anyone can fork the language if they really want to, but the new language will not be Go (Google owns the trademark on the name).
Don't need outsiders (Score:3)
... nice. So, if they need outsiders in the meetings then they're not doing their jobs right. Huh. Sure sounds like it's a community project, eh? Wow.
Don't be what now (Score:1)
At this point in the relationship, it's safer to assume that everything Google says is a lie.
Re:Some hits of their care for community. (Score:4, Funny)
Exporting symbols by starting them with uppercase is totally fine, no need for extra keywords. What if I want to write my symbols in Chinese for example?
That issue will soon be moot: In compliance with the latest US government requirements, Google is removing support for all Chinese Unicode characters from the language -- Identifiers this year, string literals early next year, and I/O by 2021. After that, any Chinese characters encountered will get replaced by a new "USA#1" emoticon.
Hearts and minds (Score:2)
That sounds so good in keeping smart people interested in a project.
Would paying ads accept any system that's 90% to 99% working?
But thats ok for the "community"?
Voices, discussions, broad agreement and acceptance are words used for people having meetings.
Not the needed people with the skills to get a project 100% ready. Projects don't need more and more discussion, projects need to be worked on, get tested and be completed.
Then kept working as the next project is worked on.
How much tim
yes (Score:2)
and the Java API doesn't belong to Oracle either...
Go is not a good language (Score:1)
* All function parameters are *copied* and if you are passing multi-megabyte arrays then tough bananas
* To do much of anything (check a dictionary) you have to pull out all kinds of parameters including ones you don't care about but you have to use them all because that's "best practice"
* No object oriented option