Interesting public commentary on Go...

30128 views
Skip to first unread message

lgo...@gmail.com

unread,
May 23, 2019, 9:18:25 AM5/23/19
to golang-nuts

B Carr

unread,
May 23, 2019, 12:30:08 PM5/23/19
to golang-nuts
I'm a hobbyist and make no money on the Go projects I write. This article seems a bit over-the-top, particularly Fred Fnord's comment. Doesn't Linus Torvalds have a stranglehold on the Linux kernel? Yet Linux flourishes.

Rather than complaining about Google (via Go) why don't these folks simply switch to Rust or some other language and press on?

Ian Lance Taylor

unread,
May 23, 2019, 1:59:57 PM5/23/19
to lgo...@gmail.com, golang-nuts
On Thu, May 23, 2019 at 9:18 AM <lgo...@gmail.com> wrote:
>
> https://utcc.utoronto.ca/~cks/space/blog/programming/GoIsGooglesLanguage

Thanks for the link. There is clearly a real sense in which Go is
Google's language. But I think I would like to emphasize some points
that don't necessarily contradict the blog post but may add some
nuance.

I'm a member of the Go team and I'm employed by Google. I'm speaking
exclusively for myself here, not for Google nor for the Go team.

I've worked on free software for my entire career, before I joined
Google and indeed before Google existed. I think it's fair to say
that Go is an open source language. All the source code, including
the source code for all the infrastructure support, is freely
available and may be reused and changed by anyone. For software the
most fundamental freedom is freedom to fork: freedom to take an
existing project in a new direction. People have that freedom with
the Go language. They don't necessarily have the freedom to call that
forked language "Go" (I'm not sure), but I think that limitation is
OK; it serves nobody to call different projects by the same name.

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.

So when someone says that Go is Google's language, they must mean
something else.

For any free software project, there is a set of people who can commit
changes to the project. For the Go project, that is the set of people
who are on the approvers list, who can click the +2 button in Gerrit.
I don't think this list is publicly visible for anybody is not an
approver, but I just took a look. Since some people who work at
Google use their personal e-mail addresses I could have made a
mistake, but I count 59 Googlers on the committers list and 51
non-Googlers.

So while Google is the majority, it's not an overwhelming one. Again,
this can't be what it means to say that Go is Google's language.

A programming language is a type of shared software infrastructure.
It's most useful when everybody is using the same language, so code
written by person A can be reused by person B. That means that
programming languages are most useful when we all agree on exactly
what the language is. All successful languages have either a single
specification or a single primary implementation. (Go and C++ are
examples of language based on a specification; Perl, at least before
Perl 6, is an example of a language based on an implementation).
These serve as the definition of what the language is: whatever the
specification says or whatever the implementation does.

I think most people would agree to all of the above. Now some
opinion, where people may disagree.

If a language is to change over time, this specification or
implementation must change. Somebody has to decide how changes will
be made. All successful languages have a small set of people who make
the final decisions. Many people will provide input to this decision,
but 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.

As I said, that is my opinion, but I think it's true. I would be
interested to hear of a counter-example.

Since Go is a successful language, and hopes to remain successful, it
too must be open to community input but must have a small number of
people who make final decisions about how the language will change
over time.

So, I think that when the blog post says that Go is Google's language,
what they mean is that Google makes those final decisions.

Now a bit of personal history. The Go project was started, by Rob,
Robert, and Ken, as a bottom-up project. I joined the project some 9
months later, on my own initiative, against my manager's preference.
There was no mandate or suggestion from Google management or
executives that Google should develop a programming language. For
many years, including well after the open source release, I doubt any
Google executives had more than a vague awareness of the existence of
Go (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.)

Since Go was developed by people who worked at Google, it is
inevitable that the people who initially developed Go, who became the
core Go team, were Google employees. And it happens that of that core
Go team, while not all are actively working on Go, none have left
Google for another company in the years since.

I do think that due to Go's success there are now Google executives
who know about Go. Google as a company is doing more work with Go at
a higher level, supporting efforts like the Go Cloud Development Kit
(https://github.com/google/go-cloud). And, of course, Go is a
significant supporting element for major Google Cloud projects like
Kubernetes.

But (and here you'll just have to trust me) 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. Of
course, there's no reason for them to. Go is doing fine, so why
should they interfere? And what could they gain if they did
interfere? So they leave us alone.

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 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. And it will be interesting to see what the core Go
team, including me, decides to do about succession planning as time
goes on. Being a core Go team member is a full time job, and many
people who want to work on Go full time wind up being hired by Google,
so it would not be particularly surprising if the core Go team
continues to be primarily or exclusively Google employees. But even
then it's not clear that Go will be Google's language in any deep
sense. It's also possible that someday it will become appropriate to
create some sort of separate Go Foundation to manage the language. I
don't know. We'll have to see.

As I said initially, none of this necessarily contradicts anything in
the blog post, but perhaps it gives a slightly different perspective.

In this note I've specifically focused on whether Go is Google's
language. I have some thoughts on other aspects of the blog post,
about its discussion of the interaction between the core Go team and
the rest of the Go community, but this note is already too long.
Perhaps I will tackle those later. Or perhaps not, no promises.

Ian

Daniela Petruzalek

unread,
May 23, 2019, 2:47:27 PM5/23/19
to Ian Lance Taylor, lgo...@gmail.com, golang-nuts
I just want to thank Ian for taking the time to write this. I've already got the idea that it worked that way, but my own deduction process, but it's good to have a confirmation from inside.

When I started contributing to Go, whatever that means... talks, code, samples, etc... my first reaction about Go being open source was "hey, that's cool", but I didn't pay much attention to it. 

By the time I got more intimate to it, I started to learn what open source really meant, and got the impression that Go was "not so open source" after all... I felt that back then I was influenced by the community reaction to Google's "control" over the language, and how it was not listening to the demands of the crowd of having generics or better error handling or whatever...

Then I've matured a little bit more and started understanding the meaning of "no is temporary, but yes is permanent". I've also came to understand even more about open source... to the point now I know that having the code open doesn't mean you give up control of it. It's actually quite the opposite... just like you mentioned, it's not a democracy. If you are unhappy, fork it and make it work the way you want.

And finally, after coding Go for a while (and for the past 3 months professionally at last!), I came to the conclusion that the Go team is right in many ways. Today I don't see any necessity in generics, and every experience report out there with implementation proposals made me thank God many times for not having generics today. It defeats entirely the principles of simplicity and orthogonality that made Go so fun to write for me.

I feel that the problem is that the community doesn't really want to learn the "Go-way" of doing things, and instead they want to keep programming like they do in Java, JS, C++, python or any other language.

Me, on the other hand, I like to try different things... I remember the first time I've written C++ code after learning a functional language... having that different mindset helped me become better at a previous language. If I never studied functional language I would stay with the same idioms I knew originally. Likewise, Go has its own programming style, and I feel that when I go back to other languages now I'm better at them too. So it pays to learn to code things in different ways, that why I'm not bothered by writing non-generic code in Go. I'm just exercising a different part of the brain.

In the end, if the Go team makes a bad decision and Go stops being fun, it's just time to move on to a new thing. It's not the end of the world.

Daniela Petruzalek
Software Engineer


--
You received this message because you are subscribed to the Google Groups "golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/CAOyqgcXdDcUKCzOaSbaCq466cxeO1KzsxAxgasabJma2XPkkxw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Sam Whited

unread,
May 23, 2019, 3:23:18 PM5/23/19
to jsonp via golang-nuts
Thank you for writing your reply Ian. Since it's a rather long post I
don't want to go through it point by point, but suffice it to say that I
agree with most of what you've written. However, I also agree that Go is
Google's language, and that in its current form this is a problem. I'm going to talk about two related but distinct probles here:

It's good to have strong central leadership, and I'm okay with that
leadership being employed by Google. The problem is that the Go team
doesn't always appear to be interested in listening to the rest of the
community. We saw this when the modules proposal was created and rushed
out without adequate community feedback; after the push back against
that the Go team promised to do better, but they're still putting out
proposals with little to no opportunity to make significant changes (eg.
the package sum proposal which was put out, and then almost immediately
merged, made into a release, and then made the default behavior).

This is especially a problem when these proposals further tie Go to
Google web services run by the Go team (though I'm veering off into a
separate problem here). To me this feels like it's almost a type of
vertical integration and it's an absolutely disgusting thing to do, and
I don't use that word lightly. Not because I think the Go team is
planning on doing anything bad with the information all Go users will
now be sending to them, or because I think Google executives are putting
down mandates and influencing Go, but because we don't know what future
Go team members or Google execs will do. We don't know who will be
running the Go project in 10 or 20 years, so the Go team now should be
making sure they limit the potential for abuse, especially when they
work for a company with a long history of anti- competitive behavior and
abuse of its size and power.

It's possible that my dissatisfaction with the proposal process is all
merely confirmation bias due to my extreme negative reaction to Go
communicating with Google-run web services that can't be used by large
portions of the world due to U.S. export laws, but I hope the Go team
will still take the feedback in the original link seriously and try to
change the process.

Sam Whited

unread,
May 23, 2019, 3:24:46 PM5/23/19
to jsonp via golang-nuts
I apologize for the rambling nature of this post; I somehow sent this
while working on a revision, I should really figure out what keyboard
shortcut I keep accidentally hitting to do that, especially when I
haven't toned down the language yet. Oh well, please pardon the lack
of polish.

—Sam
--
Sam Whited

Tom Mitchell

unread,
May 23, 2019, 3:26:45 PM5/23/19
to lgo...@gmail.com, golang-nuts
This makes a bit of sense from the Google point of view.

The central nut of a language under development is something that needs to be well managed. 
I have seen this with Modula-2 in the past as well as C++.  
Niklaus Wirth declined blessing a standard library for Modula-2 perhaps killing it as a market and
SGI an early adopter of C++ ended up with many man years of C++ library code that no longer 
compiled and run with a spin of the C++ revision dial outside of their control.

From the system design view the layers of code dare not look like spaghetti. 
At SGI a number of GFX libraries had symbols that allowed the entry to 
the black box internals of important GFX functions.  Improvements or changes to 
the internals of these black box functions for many reasons including new hardware 
broke a lot of internal and external code (internal symbols were stripped after this)

Hardware vendors have to protect their unimplemented instruction space.
Language designers need to managed the central nut of the language.
TeX has bounds  and a test suite if  your code is to be called TeX it must pass 
the test and all that.

Building code that runs reliably requires discipline and by way of
example is the constrained languages used by Knuth used to code TeX
(WEB).  And N.B.  that LaTeX is not part of TeX but is written in TeX.









On Thu, May 23, 2019 at 6:18 AM <lgo...@gmail.com> wrote:
You received this message because you are subscribed to the Google Groups "golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.


--
   T o m    M i t c h e l l

wilk

unread,
May 23, 2019, 4:16:21 PM5/23/19
to golan...@googlegroups.com
On 23-05-2019, Sam Whited wrote:
> Thank you for writing your reply Ian. Since it's a rather long post I
> don't want to go through it point by point, but suffice it to say that I
> agree with most of what you've written. However, I also agree that Go is
> Google's language, and that in its current form this is a problem. I'm going to talk about two related but distinct probles here:
>
> It's good to have strong central leadership, and I'm okay with that
> leadership being employed by Google. The problem is that the Go team
> doesn't always appear to be interested in listening to the rest of the
> community. We saw this when the modules proposal was created and rushed
> out without adequate community feedback; after the push back against
> that the Go team promised to do better, but they're still putting out
> proposals with little to no opportunity to make significant changes (eg.
> the package sum proposal which was put out, and then almost immediately
> merged, made into a release, and then made the default behavior).

I don't think the Go team doesn't listen to the community about modules,
quite the opposite technicaly speaking.

But i share your concern about proxy.golang.org being the default.
Because of privacy but also because it immediatly break private repos
and some country.

I believe it could be just fine if it's opt-in, specially that in the
alpha stage...

And thanks Ian for your writing. I'm every day surprise to see how a
language can fit at the same time a big compagny and an independant
developer ! scaling is that !

--
Wilk

Rob Pike

unread,
May 23, 2019, 5:41:27 PM5/23/19
to golang-nuts
The last sentence of the article is not correct. The name Go is not trademarked by Google, at least as a programming language trademark. There are other things Google makes called Go (an interesting signal on its own) and they might be trademarked, but Go the language is not a trademark.

-rob

Anthony Martin

unread,
May 23, 2019, 6:29:09 PM5/23/19
to Sam Whited, golan...@googlegroups.com
Sam Whited <s...@samwhited.com> once said:
> This is especially a problem when these proposals further tie Go to
> Google web services run by the Go team (though I'm veering off into a
> separate problem here). To me this feels like it's almost a type of
> vertical integration and it's an absolutely disgusting thing to do, and
> I don't use that word lightly. Not because I think the Go team is
> planning on doing anything bad with the information all Go users will
> now be sending to them, or because I think Google executives are putting
> down mandates and influencing Go, but because we don't know what future
> Go team members or Google execs will do. We don't know who will be
> running the Go project in 10 or 20 years, so the Go team now should be
> making sure they limit the potential for abuse, especially when they
> work for a company with a long history of anti- competitive behavior and
> abuse of its size and power.

How do you square this opinion with the fact that the Go team
went out of their way to enable the use of third-party module
proxies, something that is good for the community but would be
of little practical use to Google?

Anthony

Sam Whited

unread,
May 23, 2019, 6:30:50 PM5/23/19
to Anthony Martin, jsonp via golang-nuts
On Thu, May 23, 2019, at 22:28, Anthony Martin wrote:
> How do you square this opinion with the fact that the Go team went out
> of their way to enable the use of third-party module proxies,
> something that is good for the community but would be of little
> practical use to Google?

I'm certainly glad they did this, but most people will never change the
default options (or won't even know to change the options since this
behavior is silent) and the main proxy and sum file service is owned by
Google.

—Sam

lgo...@gmail.com

unread,
May 23, 2019, 8:50:22 PM5/23/19
to golang-nuts
Ian: I find many of your comments related to how the Go team functions very interesting,
I for one would find it helpful if 2 or 3 times a year the Go Team would communicate to the Go community at large, information related  to where and in what direction(s) it is taking Go, and what directions the team has decided NOT to take Go . 

I think the idea of a relatively small team of people deciding what Go will / will not morf into, is a sound one considering the what goes on within the C++ world,  

I also think it important that the Go team utilize some mechanism for screening input from the Go user community regarding changes / enhancements to the language, new packages etc.

An important measure of Go's value as a useful language is measured by the size of Go user community, which in my opinion is very much related what Go offers developers to make their life easier vs other languages.      

Gerald Henriksen

unread,
May 23, 2019, 8:51:05 PM5/23/19
to Rob Pike, golan...@googlegroups.com
The link provided in the blog post would seem to indicate otherwise.

If one scrolls down the list the following 2 entries are of interest:

Golang™ programming language
Go™ programming language

https://www.google.com/permissions/trademark/trademark-list/

Gerald Henriksen

unread,
May 23, 2019, 8:52:53 PM5/23/19
to golan...@googlegroups.com
On Fri, 24 May 2019 07:40:52 +1000, you wrote:

As a follow up, should make clear the fact that Google has trademarked
it is a good thing in my opinion for the community, as it prevents
somewhat else acting in a malicious manner and trademarking it and
forcing the community to change the name.

Pat Farrell

unread,
May 23, 2019, 10:24:41 PM5/23/19
to golang-nuts
On Thursday, May 23, 2019 at 9:18:25 AM UTC-4, lgo...@gmail.com wrote:

Before I became a GO nut, I did 20 years of commercial Java. I became a big fan of Google's Guava library.
Guava was open source, but was driven by Google's needs. Outside contributions were rare. I got used to it.

I wonder if being "community driven" is really a good thing. GO was invented by a tiny team with strict ideas. This is in strong contrast to Java or C++, which are bloated and overly complex languages.

There are times I'd rather not have something, say generics, rather than pollute the simplicity of the tool to add features that the community wants. IMHO, YMMV, etc. 

Rob Pike

unread,
May 24, 2019, 2:49:18 AM5/24/19
to Gerald Henriksen, golang-nuts
If that's true - and it might well not be - it's a surprise to me. When launching the language we explicitly made sure NOT to trademark it.

-rob

Lucio

unread,
May 24, 2019, 4:30:02 AM5/24/19
to golang-nuts
Well, the two enries are listed at the given URI, quite far apart and in the opposite order.

Could be a mistake or a bureaucratic glitch.

Lucio.

ste...@yakdata.com

unread,
May 24, 2019, 7:34:16 AM5/24/19
to golang-nuts
I am a consumer of Go. As far as I am concerned, it has been a wonder of modern computing. And I have been programming for almost 40 years.

As a cloud computing and data science polyglot, Go has become my go to language for systems control and critical web “glue” projects. It has been a joy to learn, with very little about it’s structure and syntax that made me scratch my head.

Most impressive is the efficiency, speed and scalability baked into this project. So whether the core team is at Google or not, the value of the core team originally being at Google in these areas is most apparent and appreciated.

Thank you to the many who created, evolve and maintain Go. Numerous people who likely will never comment here appreciate it. Of that I am confident.

Best regards,
Stephen McDaniel
Principal Data Scientist
YakData, LLC

Gerald Henriksen

unread,
May 24, 2019, 9:22:59 AM5/24/19
to golan...@googlegroups.com
On Fri, 24 May 2019 01:30:02 -0700 (PDT), you wrote:

>Well, the two enries are listed at the given URI, quite far apart and in
>the opposite order.

The list is alphabetical.

andrey mirtchovski

unread,
May 24, 2019, 10:40:56 AM5/24/19
to Rob Pike, golang-nuts
On Fri, May 24, 2019 at 12:49 AM Rob Pike <r...@golang.org> wrote:
>
> If that's true - and it might well not be - it's a surprise to me. When launching the language we explicitly made sure NOT to trademark it.
>

Go appears to be trademarked, as well as the new design of the Go
logo. Golang doesn't seem to be. Hopefully these links work:

http://tmsearch.uspto.gov/bin/showfield?f=doc&state=4801:7mlvuo.5.15
http://tmsearch.uspto.gov/bin/showfield?f=doc&state=4801:7mlvuo.5.14

Filing dates for both are August 2018, owner of the trademarks is Google.

Michael Jones

unread,
May 24, 2019, 11:52:08 AM5/24/19
to andrey mirtchovski, Rob Pike, golang-nuts
It is very good to have registered the marks to prevent abuse. Once owned, the owner then has the ability to share as freely as desired, but in a structured way (a la open source licenses) while holding questionable uses at bay.

In my work this kind of control has demonstrated its importance. In the creation of OpenGL ist SGI t was essential to have it mean something specific API and conformance wise; in inventing Google Earth and growing it and Google Maps to a billion unique monthly users it was important to control the brands, including Keyhole's KML which I gave to the OGC; now as a senior exec at Niantic, it seems more important than ever that Pokémon Go is a carefully controlled name and mark--every knock-off product seems to want to use our kind of "Go" as a marketing leverage (including "AR GO" from Google, a Niantic investor, sigh).

May be a surprise to the Go team, but not to Kent Walker...
Mark Image
Word MarkGO
Goods and ServicesIC 009. US 021 023 026 036 038. G & S: Computer programs and downloadable computer programs that implement a computer programming language for use in developing, building and managing other software. FIRST USE: 20091110. FIRST USE IN COMMERCE: 20091110
Standard Characters Claimed
Mark Drawing Code(4) STANDARD CHARACTER MARK
Serial Number88100955
Filing DateAugust 31, 2018
Current Basis1A
Original Filing Basis1A
Owner(APPLICANT) Google LLC LIMITED LIABILITY COMPANY DELAWARE 1600 Amphitheatre Parkway Mountain View CALIFORNIA 94043
Type of MarkTRADEMARK
RegisterPRINCIPAL
Live/Dead IndicatorLIVE


Mark Image
Word MarkGO
Goods and ServicesIC 009. US 021 023 026 036 038. G & S: Computer programs and downloadable computer programs that implement a computer programming language for use in developing, building and managing other software
Mark Drawing Code(3) DESIGN PLUS WORDS, LETTERS, AND/OR NUMBERS
Design Search Code26.17.01 - Bands, straight ; Bars, straight ; Lines, straight ; Straight line(s), band(s) or bar(s)
26.17.06 - Bands, diagonal ; Bars, diagonal ; Diagonal line(s), band(s) or bar(s) ; Lines, diagonal
Serial Number88100957
Filing DateAugust 31, 2018
Current Basis1B
Original Filing Basis1B
Owner(APPLICANT) Google LLC LIMITED LIABILITY COMPANY DELAWARE 1600 Amphitheatre Parkway Mountain View CALIFORNIA 94043
Description of MarkColor is not claimed as a feature of the mark. The mark consists of the stylized word GO with three small lines to the left of the word.
Type of MarkTRADEMARK
RegisterPRINCIPAL
Live/Dead Indicator

--
Michael T. Jones
michae...@gmail.com

Space A.

unread,
May 24, 2019, 4:36:39 PM5/24/19
to golang-nuts
Hi Pat,

I also have some (quite a lot) years of Java, and absolutely agree with everything you said.

And +1 to Ian's opinion on how free software projects must be driven.

Axel Wagner

unread,
May 27, 2019, 1:35:31 AM5/27/19
to Ian Lance Taylor, golang-nuts
This is a bit of an aside, I agree with everything Ian said, but:

On Thu, May 23, 2019 at 7:59 PM Ian Lance Taylor <ia...@golang.org> wrote:
If a language is to change over time, this specification or
implementation must change.  Somebody has to decide how changes will
be made.  All successful languages have a small set of people who make
the final decisions.  Many people will provide input to this decision,
but 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.

As I said, that is my opinion, but I think it's true.  I would be
interested to hear of a counter-example.

I also believe that every successful free software project has a small set of final deciders, but I don't think it's correct to say that thus, no successful free software project is a democracy. Representative democracy is still democracy - and indeed, any modern democracy I'm aware of, is a representative one. And Debian is undeniably successful and very easily defended to be a representative democracy. There is a limitation on voting rights (only Debian Developers can vote), but it's akin to the limitation of passports and the set of Debian Developers is hardly "small".

This just as a specific counter because you asked for counter examples :) Personally (opinion!), I tend to think that it rather supports your larger point of democratic software development being a recipe for chaos and incoherence - but YMMV of course.
 
--
You received this message because you are subscribed to the Google Groups "golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts...@googlegroups.com.

Space A.

unread,
May 27, 2019, 3:45:07 AM5/27/19
to Axel Wagner, Ian Lance Taylor, golang-nuts
Debian users vote for someone to become Debian Developer and give him right to vote? If no, how can it be "representative"?


пн, 27 мая 2019 г. в 08:35, 'Axel Wagner' via golang-nuts <golan...@googlegroups.com>:
You received this message because you are subscribed to a topic in the Google Groups "golang-nuts" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/golang-nuts/6dKNSN0M_kg/unsubscribe.
To unsubscribe from this group and all its topics, send an email to golang-nuts...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/CAEkBMfFhOF0kiNsUfZkMc71SoJ8M5Y2Rqx1TnG9Yhc5aORMXBA%40mail.gmail.com.

Axel Wagner

unread,
May 27, 2019, 4:09:42 AM5/27/19
to Space A., Ian Lance Taylor, golang-nuts
The actual organizational structure of Debian is pretty complex. You can think of Debian Developers (DD) as "people who can submit to Debian" (so the people with approval rights in gerrit, in analogy to the Go project). The people who steer the project and are final deciders on Debian (so the "core Go team" from Ian's message) are the Debian Project Leader (DPL) and the Technical Committee (TC) (with different responsibilities).

The process to become a DD is based on contribution and some endorsement from existing DDs and it's very open. The DDs then elect representatives for the roles of DPL and TC. They can also push General Resolutions, which every DD votes on.
So, in analogy to a modern democracy, DDs would be "citizens" and the DPL and TC are "the government" and the Debian project combines elements of representative democracy (by electing "the government") and direct democracy (via General Resolutions).

Anyhow, I didn't want this to become a discussion of Debian organizational structure. Anyone interested in it can probably google around a bit and there are far more qualified people than me to talk about it. I just think it provides a decent example of how a democratic and successful open source project could look. And that, IMO, it's a negative example (but YMMV).

Matt Farina

unread,
May 27, 2019, 3:16:16 PM5/27/19
to golang-nuts
This whole conversation illustrates the difference between open source and open governance. Go is open source but the governance is controlled by Google. This compares to something like Kubernetes that is both open source and open governance.

Should Go be open governance? It sounds like this is a question some want to discuss. Open governance is just a different topic than open source.

Liam

unread,
May 27, 2019, 3:31:22 PM5/27/19
to golang-nuts
I filed an issue requesting that the Go team issue RFPs to both communicate directions they plan to go in, and solicit community input about them. It was declined.

proposal: Go 2: establish RFP/RFC process for language feature proposals

Part of my reasoning was that the Go 2 Error Handling Draft Design lacked a discussion of "requirements". IMHO a well-developed set of requirements (and revised with community input) would have been more valuable than a design proposal which fulfills unspecified requirements.

Ian Lance Taylor

unread,
May 27, 2019, 4:03:55 PM5/27/19
to lgo...@gmail.com, golang-nuts
On Thu, May 23, 2019 at 8:50 PM <lgo...@gmail.com> wrote:
>
> Ian: I find many of your comments related to how the Go team functions very interesting,
> I for one would find it helpful if 2 or 3 times a year the Go Team would communicate to the Go community at large, information related to where and in what direction(s) it is taking Go, and what directions the team has decided NOT to take Go .
>
> I think the idea of a relatively small team of people deciding what Go will / will not morf into, is a sound one considering the what goes on within the C++ world,
>
> I also think it important that the Go team utilize some mechanism for screening input from the Go user community regarding changes / enhancements to the language, new packages etc.
>
> An important measure of Go's value as a useful language is measured by the size of Go user community, which in my opinion is very much related what Go offers developers to make their life easier vs other languages.

Thanks for the note. We do try to communicate plans for the language
and standard library packages, broadly on the Go blog and more
specifically on the golang-dev mailing list. E.g.,
https://blog.golang.org/go2draft,
https://blog.golang.org/go2-here-we-come .

Naturally it's a lot harder to say which directions the team has
decided not to take Go. One way to see that is to follow the issue
tracker for bugs marked Go2
(https://github.com/golang/go/issues?utf8=%E2%9C%93&q=is%3Aissue+label%3Ago2).
That is a list of changes either rejected or still being considered.
Of course, a rejected issue doesn't always mean that some similar
change will not be adopted; sometimes it only means that that
particular change is rejected, but a different, better change that
addresses the same problems might still be accepted. I don't really
see a benefit to a broader announcement of ideas that we aren't going
to do. For one thing, it might change.

In general we are always interested in hearing new proposals for
changes, using the proposal process described at
https://golang.org/s/proposal. Of course, before writing a new
proposal, it helps to look to see whether there are similar previous
proposals.

Ian

Ian Lance Taylor

unread,
May 27, 2019, 4:04:59 PM5/27/19
to Axel Wagner, golang-nuts
On Mon, May 27, 2019 at 1:35 AM Axel Wagner
<axel.wa...@googlemail.com> wrote:
>
> This is a bit of an aside, I agree with everything Ian said, but:
>
> On Thu, May 23, 2019 at 7:59 PM Ian Lance Taylor <ia...@golang.org> wrote:
>>
>> If a language is to change over time, this specification or
>> implementation must change. Somebody has to decide how changes will
>> be made. All successful languages have a small set of people who make
>> the final decisions. Many people will provide input to this decision,
>> but 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.
>>
>> As I said, that is my opinion, but I think it's true. I would be
>> interested to hear of a counter-example.
>
>
> I also believe that every successful free software project has a small set of final deciders, but I don't think it's correct to say that thus, no successful free software project is a democracy. Representative democracy is still democracy - and indeed, any modern democracy I'm aware of, is a representative one. And Debian is undeniably successful and very easily defended to be a representative democracy. There is a limitation on voting rights (only Debian Developers can vote), but it's akin to the limitation of passports and the set of Debian Developers is hardly "small".
>
> This just as a specific counter because you asked for counter examples :) Personally (opinion!), I tend to think that it rather supports your larger point of democratic software development being a recipe for chaos and incoherence - but YMMV of course.

Thanks. That's an interesting counter-example. I do tend to think of
distros somewhat separately from more focused free software projects,
but I probably shouldn't.

Ian

Axel Wagner

unread,
May 27, 2019, 4:28:21 PM5/27/19
to Matt Farina, golang-nuts
On Mon, May 27, 2019 at 9:16 PM Matt Farina <matt....@gmail.com> wrote:
This whole conversation illustrates the difference between open source and open governance. Go is open source but the governance is controlled by Google. This compares to something like Kubernetes that is both open source and open governance.

I'm not sure whether I agree with this characterization. There is, AFAIK, approximately no codified process in the Go project that would single out Google or Google Employees. To a degree, that's because there aren't that many codified processes and the ones there are, are kept a bit vague (in favor of a consensus-driven culture). But also, I'd argue, because the process isn't actually that closed.

Ian outlines several reasons why it isn't - and why it might appear that way nevertheless.
But if, hypothetically, Google would successfully hire anyone doing core-team-level work on Go and if, hypothetically, anyone working on Go would immediately lose interest once they don't work at Google anymore, you'd end up in a world where a) anyone in the Go team works at Google, but b) I would find it hard to claim the governance isn't open, as anyone can just do the necessary level of work and become part of the Go team. Just like in an "open governance" model. i.e. you'd end up with "you work at Google because you are a decider for Go", not with "you are a decider for Go because you work at Google".

So, the question is how far these hypotheticals deviate from reality. And that's just hard to talk about in any founded way, because we don't have a lot of obvious examples of people either not accepting an offer to work on the Go team fulltime *or* quitting Google and then stopping (or not stopping) to be on the Go team.

Now, there are some ways in which processes are more or less Googler-specific. AIUI the proposal review meeting is internal only, for example. But AIUI, no one has yet excluded the possibility of opening that up to non-Googlers who are still qualifying… i.e. it's not *codified* as being Googler-specific, it just never came up that a non-Googler qualified for an invite.

Anyway, as I said: I genuinely don't know whether I'd consider Go open governance or not. But, TBQH, the assertion that it's *not* should at least address why Ian's points aren't convincing (because in its essence, that question is *exactly* what he was debating pretty in-depth).

Should Go be open governance? It sounds like this is a question some want to discuss. Open governance is just a different topic than open source.

--
You received this message because you are subscribed to the Google Groups "golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts...@googlegroups.com.

Wojciech S. Czarnecki

unread,
May 27, 2019, 4:41:32 PM5/27/19
to golan...@googlegroups.com
On Mon, 27 May 2019 12:31:22 -0700 (PDT)
Liam <networ...@gmail.com> wrote:

Rust was irreparably damaged by delivering custom painted ponies to the
most vocal and enough stubborn "representatives of the whole community".
I personally wishes Go team will guard the future of Go free from such fate,
as they did for past years.

> a well-developed set of requirements (and revised with community input)
> would have been more valuable than a design proposal which fulfills
> unspecified requirements.

Then ones who abode to guidelines and requirements would **demand**
that someone at Google should immediately implement their proposal
'because it was much work to made this proposal in line with RFC process'.

Unlike many other open sourced projects the Go compiler and tools are self
contained and produce working set from a single script call.

So now my opinion is that the only real way of proposing changes to
Go is with one's work: git clone, git checkout -b quipintedpony, work, test,
**document**, **explain why and what** then post ANNounce.
Let community (and the dev-team) really see merit in your proposal.

P.S. My personal feeling (I am on this list from pre 1.0 IIRC) is that Go team
listen, read, then take the very nut of one or more proposals and either improve
on it or — on the way — they come to the other solution that learns from
proposal's shortcomings. See dev list archive around GC improvements.

TC,

--
Wojciech S. Czarnecki
<< ^oo^ >> OHIR-RIPE

Matt Farina

unread,
May 27, 2019, 7:08:16 PM5/27/19
to Axel Wagner, golang-nuts

I'm not sure whether I agree with this characterization. There is, AFAIK, approximately no codified process in the Go project that would single out Google or Google Employees. To a degree, that's because there aren't that many codified processes and the ones there are, are kept a bit vague (in favor of a consensus-driven culture). But also, I'd argue, because the process isn't actually that closed.

Three things I've considered:

1) when a company runs a project without much publicly documented process but does as they choose, isn't that a sign of a company run project?
2) The go team at Google has had processes that are not public. One example is the proposal review process. There has long been a group at Google that decides these. For a long time this wasn't documented publicly but happened. The public documentation on it came after the decision on go modules.
3) how has no one outside of Google qualified for the core team and why aren't more companies who are heavy users in on owning it? I've heard stories (not mine to share) of more outside engagement not happening for Go.

I'm not nocking on Google for doing what they do. It's a business decision. I get it and I can understand a climate where it might change. I'm just trying to be aware of what's happening.

I do sometimes wonder what the small decision making core team would look like with people from multiple companies with differing concerns on it. But, that's just wondering.

I use Go. Gonna start something new in go soon, too.

--
Matt Farina

Go in Practice - A book of Recipes for the Go programming language.

Code Engineered - A blog on cloud, web, and software development.

Axel Wagner

unread,
May 27, 2019, 8:18:38 PM5/27/19
to Matt Farina, golang-nuts
On Tue, May 28, 2019 at 1:08 AM Matt Farina <matt....@gmail.com> wrote:
Three things I've considered:

1) when a company runs a project without much publicly documented process but does as they choose, isn't that a sign of a company run project?

Ian mentioned that "Google" as a company doesn't actually choose to do a lot. The Go team is largely autonomous in their decision making and isn't being influenced by executives.
So, to put it another way: If the only role the company plays is to provide paychecks to some Go developers, does it actually exercise or have any significant level of ownership?
 
2) The go team at Google has had processes that are not public. One example is the proposal review process. There has long been a group at Google that decides these. For a long time this wasn't documented publicly but happened. The public documentation on it came after the decision on go modules.

Note that the documentation still says "some members of the Go team". Not "the Google-employed members of the Go team" (i.e. not everyone at Google has access to those meetings) and not "a Google-internal set of people" (i.e. people outside Google aren't categorically excluded from them).

A charitable interpretation of this might be that some members of the Go team started, at some point, to semi-regularly meet informally to churn through the proposals. As it was informal and as everyone involved was working at the same company and was paid for this work, it made sense to do so during business hours in a meeting room at the office. When a project came up that was driven by people outside of Google, the need arose to specify better how proposals are reviewed and decided on, so the previously informal or semi-formal meeting was codified.

Personally, I don't see how this charitable interpretation would contradict claims that any process can be opened to people outside of Google when the need arises. On the contrary, it seems to confirm that; after all, the meeting was formalized and publicized based on the need of including outsiders in the process.
 
3) how has no one outside of Google qualified for the core team

I don't think this is true at all. There are several people who got hired into the Go team from outside of Google directly. See above hypothetical (and Ian's point): Google tends to try to hire people they think are qualified to work on Go. And it tends to succeed.

Seems a pretty reasonable answer to that question.
 
and why aren't more companies who are heavy users in on owning it?

As a concrete example: Cloudflare pretty heavily uses Go. When a cloudflare-employee started stepping up to work more and more on the Go crypto stack, they got hired by Google to do it fulltime. At least from the outside, that seems to what happened with Filippo Valsorda.

So, again, the explanation Ian gave seems pretty reasonable: Doing core work on Go is a fulltime job, Google seems willing to foot the bill for that fulltime job and people seem willing to let them.

Matt Farina

unread,
May 27, 2019, 9:17:21 PM5/27/19
to golang-nuts

Ian mentioned that "Google" as a company doesn't actually choose to do a lot. The Go team is largely autonomous in their decision making and isn't being influenced by executives.
So, to put it another way: If the only role the company plays is to provide paychecks to some Go developers, does it actually exercise or have any significant level of ownership?
 

I see a couple ways to look at the Go team. One is as a team that is independent of Google and is staffed with people who work at Google. The other is as a department within Google. As Google owns the trademark, Go sites are under the Google policies, only Google employees are on the team, there have been internal processes that are not public, and the governance isn't documented publicly I'm led down the road of it being a department withing Google. Like the GMail team is an organization within Google.

Then there is the issue of ownership, which provides the right of control. When it comes to this, I'm not entirely clear. I happy to believe Ian that senior execs have not exercised control over the project. That doesn't mean Google doesn't own the project. Has it relinquished it's right to control? Have the Googlers on the Go team relinquished control to members in the community? Google engineers have retained control including Russ who is a Principal Engineer (exec level?).

When I say I'm not clear that's because I'm reminded of a Steve Francia talk at a DrupalCon recently. He talked about Go and the community structure. What he would like to see. I don't see that happening in the community or with the Go team. I'm not sure of the relationship of the Go team to the community or the ongoing intent. For reference, the video is up at https://www.youtube.com/watch?v=EJo9tPXGPo8
 
2) The go team at Google has had processes that are not public. One example is the proposal review process. There has long been a group at Google that decides these. For a long time this wasn't documented publicly but happened. The public documentation on it came after the decision on go modules.

Note that the documentation still says "some members of the Go team". Not "the Google-employed members of the Go team" (i.e. not everyone at Google has access to those meetings) and not "a Google-internal set of people" (i.e. people outside Google aren't categorically excluded from them).

The Go team is only made of Googlers. Why is that? What does one need to do to join the Go team and not be at Google? None of this is publicly available knowledge. It's currently treated as a department within Google.
 
 
3) how has no one outside of Google qualified for the core team

I don't think this is true at all. There are several people who got hired into the Go team from outside of Google directly. See above hypothetical (and Ian's point): Google tends to try to hire people they think are qualified to work on Go. And it tends to succeed.

So, to join the Go team one needs to be hired into Google? So, Red Hat (as an example) can't have someone on staff who is on the Go team? That kinda speaks to the point that this is a Google project. If it wasn't someone from Microsoft, Red Hat, or one of the many other companies who are invested in Go could be on the core team without going to be employed by Google.
 

As a concrete example: Cloudflare pretty heavily uses Go. When a cloudflare-employee started stepping up to work more and more on the Go crypto stack, they got hired by Google to do it fulltime. At least from the outside, that seems to what happened with Filippo Valsorda.

That's fantastic. This shows some open source in action. It also highlights that this isn't open governance. If it did, Filippo joining the core team would have been a separate event from joining Google.


So, again, the explanation Ian gave seems pretty reasonable: Doing core work on Go is a fulltime job, Google seems willing to foot the bill for that fulltime job and people seem willing to let them.

I bet there are others who are willing for foot the full time bill for core Go work. The current state of things doesn't allow for that.

If this sounds like I'm arguing for open governance, that wasn't my intent. I'm just trying to continue the point that kicked all of this off. The Go is Google's project. It does not have open governance. If this is ok or not is an exercise for others to make.
 

Russ Cox

unread,
May 28, 2019, 11:53:09 AM5/28/19
to Matt Farina, Axel Wagner, golang-nuts
On Mon, May 27, 2019 at 7:08 PM Matt Farina <matt....@gmail.com> wrote:
1) when a company runs a project without much publicly documented process but does as they choose, isn't that a sign of a company run project?
2) The go team at Google has had processes that are not public. One example is the proposal review process. There has long been a group at Google that decides these. For a long time this wasn't documented publicly but happened. The public documentation on it came after the decision on go modules.

This is demonstrably false. We launched the proposal process at Gophercon in 2015, well before modules. We did it explicitly to open the process of contributing ideas - as opposed to code - and make it more accessible to new contributors. You can see the full commit history of the process description online. I tried to streamline the doc to make it more approachable in 2018, but I did not make semantic changes in that edit.

3) how has no one outside of Google qualified for the core team and why aren't more companies who are heavy users in on owning it?

It's unclear what you mean by "core team." If you mean the set of people who can approve (+2) and submit code changes, then as Ian said, there are more people outside Google than inside Google at this point.

On Mon, May 27, 2019 at 9:17 PM Matt Farina <matt....@gmail.com> wrote:
As a concrete example: Cloudflare pretty heavily uses Go. When a cloudflare-employee started stepping up to work more and more on the Go crypto stack, they got hired by Google to do it fulltime. At least from the outside, that seems to what happened with Filippo Valsorda.

That's fantastic. This shows some open source in action. It also highlights that this isn't open governance. If it did, Filippo joining the core team would have been a separate event from joining Google.

We did give Filippo the ability to +2 (review, approve, and submit) crypto CLs while he was still at Cloudflare, so in that sense it was a separate event. Filippo being at Google now means that working directly on Go can be his full-time job now. My understanding is that he had responsibilities at Cloudflare beyond contributing to the Go project.

A better example might be the various engineers who work at companies like Intel, ARM, and Microsoft on Go support for those companies' processors and operating systems. Many of them can now +2 code change as well, and they do so within their area of expertise.

Best,
Russ

Amnon Baron Cohen

unread,
May 28, 2019, 12:01:37 PM5/28/19
to golang-nuts
If it aint broke, don't fix it.

On Thursday, 23 May 2019 14:18:25 UTC+1, lgo...@gmail.com wrote:

Matt Farina

unread,
May 28, 2019, 12:46:49 PM5/28/19
to golang-nuts
Thanks for the details, Russ.


On Tuesday, May 28, 2019 at 11:53:09 AM UTC-4, Russ Cox wrote:
On Mon, May 27, 2019 at 7:08 PM Matt Farina <matt....@gmail.com> wrote:
1) when a company runs a project without much publicly documented process but does as they choose, isn't that a sign of a company run project?
2) The go team at Google has had processes that are not public. One example is the proposal review process. There has long been a group at Google that decides these. For a long time this wasn't documented publicly but happened. The public documentation on it came after the decision on go modules.

This is demonstrably false. We launched the proposal process at Gophercon in 2015, well before modules. We did it explicitly to open the process of contributing ideas - as opposed to code - and make it more accessible to new contributors. You can see the full commit history of the process description online. I tried to streamline the doc to make it more approachable in 2018, but I did not make semantic changes in that edit.

Let me be a little more clear. In the docs (see the version prior to the 2018 update at https://github.com/golang/proposal/tree/a16a937b3b39c4c42f063842407c30c4c451b524#process) there was no documentation on the proposal reviewers on the Go team. How proposals were reviewed was not documented. Numerous people, myself included, found this by seeing comments on issues that referred to this group. Saying something in a speech at a Gothercon is not documentation. People who were not paying attention, were not there, or forgot we also not able to come upon this information.

This is why I referred to it not being documented publicly.
 

3) how has no one outside of Google qualified for the core team and why aren't more companies who are heavy users in on owning it?

It's unclear what you mean by "core team." If you mean the set of people who can approve (+2) and submit code changes, then as Ian said, there are more people outside Google than inside Google at this point.

I think this highlights a documentation gap or place where people have different understandings. Is the organizational hierarchy of Go documented somewhere? Lots of phrases are thrown around and different people can throw different meanings on them. When I refer to that group I'm thinking of things like the Kubernetes Steering Committee. It is the core set of people responsible for the decisions on the project. This is a smaller group than the committers. It is the decision/direction makers for the project.

This group, as far as I'm aware, is all Googlers. It may not be documented and there may be assumptions. This is what I expect from a company run project.
 

On Mon, May 27, 2019 at 9:17 PM Matt Farina <matt....@gmail.com> wrote:
As a concrete example: Cloudflare pretty heavily uses Go. When a cloudflare-employee started stepping up to work more and more on the Go crypto stack, they got hired by Google to do it fulltime. At least from the outside, that seems to what happened with Filippo Valsorda.

That's fantastic. This shows some open source in action. It also highlights that this isn't open governance. If it did, Filippo joining the core team would have been a separate event from joining Google.

We did give Filippo the ability to +2 (review, approve, and submit) crypto CLs while he was still at Cloudflare, so in that sense it was a separate event. Filippo being at Google now means that working directly on Go can be his full-time job now. My understanding is that he had responsibilities at Cloudflare beyond contributing to the Go project.

A better example might be the various engineers who work at companies like Intel, ARM, and Microsoft on Go support for those companies' processors and operating systems. Many of them can now +2 code change as well, and they do so within their area of expertise.

Thanks for sharing the additional detail. This has more do to with ownership than reviewer/approver status.


I want to make something clear, I'm not suggesting Go change it's governance in any of these messages. I'm only attempting to provide evidence that Go is a Google owned project. Many open source projects are company owned. I use a bunch of them. I'll let other people have a debate on how things should be.

Russ Cox

unread,
May 28, 2019, 2:03:28 PM5/28/19
to Matt Farina, golang-nuts
On Tue, May 28, 2019 at 12:46 PM Matt Farina <matt....@gmail.com> wrote:
Let me be a little more clear. In the docs (see the version prior to the 2018 update at https://github.com/golang/proposal/tree/a16a937b3b39c4c42f063842407c30c4c451b524#process) there was no documentation on the proposal reviewers on the Go team. How proposals were reviewed was not documented. Numerous people, myself included, found this by seeing comments on issues that referred to this group. Saying something in a speech at a Gothercon is not documentation. People who were not paying attention, were not there, or forgot we also not able to come upon this information.

This is why I referred to it not being documented publicly.

The first commit of the proposal repo's README.md in 2015 had links to these talks:

To learn more about Go's origins and development process, see the talks
and [Go, Open Source, Community](http://blog.golang.org/open-source)
from GopherCon 2015.

More importantly, that initial README also lays out the proposal process, which aims to structure a community discussion that leads to overall consensus, not a judgement from a supreme court of Go. In 2016 we realized that we needed to document what happens when consensus cannot be reached but we still have to move forward, and we did that. That version said:

Once comments and revisions on the design doc wind down, there is a final discussion about the proposal.

The goal of the final discussion is to reach agreement on the next step: (1) accept or (2) decline.
The discussion is expected to be resolved in a timely manner.
If clear agreement cannot be reached, the arbiter (rsc@) reviews the discussion and makes the decision to accept or decline.

That last line is the last resort. And I wanted to make clear that even then I am discussing that discussion carefully and thoughtfully with others rather than just flying solo. So I added the text about the proposal review group in 2018. That text emphasizes first that proposal review is mainly about facilitating discussions:

Proposal Review

A group of Go team members holds “proposal review meetings” approximately weekly to review pending proposals.

The principal goal of the review meeting is to make sure that proposals are receiving attention from the right people, by cc'ing relevant developers, raising important questions, pinging lapsed discussions, and generally trying to guide discussion toward agreement about the outcome. The discussion itself is expected to happen on the issue tracker, so that anyone can take part.

The proposal review meetings also identify issues where consensus has been reached and the process can be advanced to the next step (by marking the proposal accepted or declined or by asking for a design doc).

And then it also elaborates on the last-resort decision-making to make clear that even if we can't get to consensus among all the people commenting on the issue, we still try to find a decision that all the proposal reviewers agree is appropriate (that is, I don't just do whatever I want):

Consensus and Disagreement

The goal of the proposal process is to reach general consensus about the outcome in a timely manner.

If general consensus cannot be reached, the proposal review group decides the next step by reviewing and discussing the issue and reaching a consensus among themselves. If even consensus among the proposal review group cannot be reached (which would be exceedingly unusual), the arbiter (rsc@) reviews the discussion and decides the next step.

It has never happened that the proposal review group was unable to agree about the next step for a given issue. The number of issues that even get that far is very small too. The vast majority have a clear outcome.
 
I think this highlights a documentation gap or place where people have different understandings. Is the organizational hierarchy of Go documented somewhere? Lots of phrases are thrown around and different people can throw different meanings on them. When I refer to that group I'm thinking of things like the Kubernetes Steering Committee. It is the core set of people responsible for the decisions on the project. This is a smaller group than the committers. It is the decision/direction makers for the project.

This group, as far as I'm aware, is all Googlers. It may not be documented and there may be assumptions. This is what I expect from a company run project.

As you noted, years ago I used to sign things by mentioning @golang/proposal-review, to try to make transparent who the review group was. Then it was pointed out to me that GitHub doesn't let people outside the golang org see the membership list, so I stopped. (If anyone knows how to make the membership 100% public in GitHub settings I would gladly do it. My options are "Secret" and "Visible" and it is set to "Visible".) But FWIW, my understanding is that because you, @mattfarina, are in the golang org, you should be able to see it at https://github.com/orgs/golang/teams/proposal-review/members. It is not all Google employees working on Go. 

The review group started out as Andrew Gerrand and Brad Fitzpatrick (who started the proposal process) and Robert Griesemer, Ian Lance Taylor, and Rob Pike (who started Go). I replaced Andrew when he wanted to step back. We've since added Andy Bonventre, our lead for the subteam focused specifically on the open source, and Steve Francia, our product manager. And we added Peter Weinberger, because he knows an incredible amount about computing generally and helps us reach better decisions.

Again, we spend the bulk of our time making sure the discussions are proceeding well, not being the deciders of last resort.

Best,
Russ

Russ Cox

unread,
May 28, 2019, 2:32:33 PM5/28/19
to Ian Lance Taylor, lgo...@gmail.com, golang-nuts
Hi all,

I spent a while trying to work out what I want to say about the general theme of Go and open source, but in the end I realized that my talk at Gophercon 2015 is a better articulation of what open source means for Go, and what Google's role is, than any email I can write in a few hours today. You can read the blog post version, “Go, Open Source, Community,” at https://blog.golang.org/open-source, and I am including a copy below. I reread it this morning, and I still believe everything I said then. One thing I talked about was how we try to focus on building a shared foundation for Go developers to build tools and programs that interoperate. A recent example of our continued focus on that theme is how the module proxy protocol enabled not just the Go module mirror but also the Athens project and JFrog GoCenter. The new go/packages API and gopls are smaller examples. In fact there is now a roughly biweekly “Go tools” meeting which is typically attended by more tool and editor integration authors from outside Google than from inside Google and organized by a contributor outside Google. (If you want to know more about that, email Paul Jolly, pa...@myitcv.io.)

Community participation is critical to improving Go. We can't make Go the best language it can be for as many users as possible (staying true to the original vision of Go) if we don't hear from users about what problems they are encountering. And good ideas come from outside Google as often as they come from inside Google. We work with people offering solutions, when they are interested, to revise and iterate on those solutions to lead to ones that are as simple as possible and fit well into the overall design of Go. But getting to yes on every suggested new feature is not and never has been a goal. See the talk for more about our approach.

I've noticed that people often use the term “the Go community” without being particularly clear about what they mean. To me, the Go community is all Go users, which is at least a million people at this point. As such, it's at the very least imprecise to say things like “the Go community wants (or did) X.” Some subset of the Go community wants or did X. 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.

At the start of the Go project we were only trying to build the language we wanted to use in our own work. Since the open source release we have been actively working to make Go something as many people as possible can use productively and effectively for their own work. Again, community involvement is critical for both understanding how well Go is working and for finding new, concrete ideas about how to make it better. We launched with clear instructions about how to contribute code, but without clear instructions about how to contribute ideas. Gophercon 2015 started with my talk and ended with Andrew Gerrand's talk “How Go was Made,” which introduced the proposal process.

As a bit of an update on the proposal process since the 2015 kickoff, it is essentially unchanged since the start. 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.

(Another update since 2015 is that while vendor directories alone did serve as useful shared infrastructure for a while, it became clear that we needed to agree on a bit more to make even more tools interoperate, which eventually led to modules.)

I thought Chris's post and his followup post were both quite thoughtful, but I disagree about the headline “Go is Google's language, not ours.” There are certainly senses in which Go is Google's language: it was created at Google, Google continues to fund most of the development, and a few people at Google are the final deciders about the language itself. But I disagree with the “not ours:” I think Go is also the Go community's language. We on the Go team at Google have demonstrated a strong preference for working with the worldwide Go community to make minimal changes that enable developers to do as much as possible on their own. Go is very much a collective effort, far beyond Google: everyone who publishes a package, teaches a class, writes a blog post or book organizes a meetup, or files an issue is contributing to Go and making it theirs. And, as Ian noted, the freedom to fork hopefully keeps me and the other current Go leadership honest. 

Best,
Russ

Go, Open Source, Community
8 July 2015
https://blog.golang.org/open-source

Welcome

[This is the text of my opening keynote at Gophercon 2015. The video is available here.]

Thank you all for traveling to Denver to be here, and thank you to everyone watching on video. If this is your first Gophercon, welcome. If you were here last year, welcome back. Thank you to the organizers for all the work it takes to make a conference like this happen. I am thrilled to be here and to be able to talk to all of you.

I am the tech lead for the Go project and the Go team at Google. I share that role with Rob Pike. In that role, I spend a lot of time thinking about the overall Go open source project, in particular the way it runs, what it means to be open source, and the interaction between contributors inside and outside Google. Today I want to share with you how I see the Go project as a whole and then based on that explain how I see the Go open source project evolving.

Why Go?

To get started, we have to go back to the beginning. Why did we start working on Go?

Go is an attempt to make programmers more productive. We wanted to improve the software development process at Google, but the problems Google has are not unique to Google.

There were two overarching goals.

The first goal is to make a better language to meet the challenges of scalable concurrency. By scalable concurrency I mean software that deals with many concerns simultaneously, such as coordinating a thousand back end servers by sending network traffic back and forth.

Today, that kind of software has a shorter name: we call it cloud software. It's fair to say that Go was designed for the cloud before clouds ran software.

The larger goal is to make a better environment to meet the challenges of scalable software development, software worked on and used by many people, with limited coordination between them, and maintained for years. At Google we have thousands of engineers writing and sharing their code with each other, trying to get their work done, reusing the work of others as much as possible, and working in a code base with a history dating back over ten years. Engineers often work on or at least look at code originally written by someone else, or that they wrote years ago, which often amounts to the same thing.

That situation inside Google has a lot in common with large scale, modern open source development as practiced on sites like GitHub. Because of this, Go is a great fit for open source projects, helping them accept and manage contributions from a large community over a long period of time.

I believe much of Go's success is explained by the fact that Go is a great fit for cloud software, Go is a great fit for open source projects, and, serendipitously, both of those are growing in popularity and importance in the software industry.

Other people have made similar observations. Here are two. Last year, on RedMonk.com, Donnie Berkholz wrote about “Go as the emerging language of cloud infrastructure,” observing that “[Go's] marquee projects ... are cloud-centric or otherwise made for dealing with distributed systems or transient environments.”

This year, on Texlution.com, the author wrote an article titled “Why Golang is doomed to succeed,” pointing out that this focus on large-scale development was possibly even better suited to open source than to Google itself: “This open source fitness is why I think you are about to see more and more Go around ...”

The Go Balance

How does Go accomplish those things?

How does it make scalable concurrency and scalable software development easier?

Most people answer this question by talking about channels and goroutines, and interfaces, and fast builds, and the go command, and good tool support. Those are all important parts of the answer, but I think there is a broader idea behind them.

I think of that idea as Go's balance. There are competing concerns in any software design, and there is a very natural tendency to try to solve all the problems you foresee. In Go, we have explicitly tried not to solve everything. Instead, we've tried to do just enough that you can build your own custom solutions easily.

The way I would summarize Go's chosen balance is this: Do Less. Enable More.

Do less, but enable more.

Go can't do everything. We shouldn't try. But if we work at it, Go can probably do a few things well. If we select those things carefully, we can lay a foundation on which developers can easily build the solutions and tools they need, and ideally can interoperate with the solutions and tools built by others.

Examples

Let me illustrate this with some examples.

First, the size of the Go language itself. We worked hard to put in as few concepts as possible, to avoid the problem of mutually incomprehensible dialects forming in different parts of a large developer community. No idea went into Go until it had been simplified to its essence and then had clear benefits that justified the complexity being added.

In general, if we have 100 things we want Go to do well, we can't make 100 separate changes. Instead, we try to research and understand the design space and then identify a few changes that work well together and that enable maybe 90 of those things. We're willing to sacrifice the remaining 10 to avoid bloating the language, to avoid adding complexity only to address specific use cases that seem important today but might be gone tomorrow.

Keeping the language small enables more important goals. Being small makes Go easier to learn, easier to understand, easier to implement, easier to reimplement, easier to debug, easier to adjust, and easier to evolve. Doing less enables more.

I should point out that this means we say no to a lot of other people's ideas, but I assure you we've said no to even more of our own ideas.

Next, channels and goroutines. How should we structure and coordinate concurrent and parallel computations? Mutexes and condition variables are very general but so low-level that they're difficult to use correctly. Parallel execution frameworks like OpenMP are so high-level that they can only be used to solve a narrow range of problems. Channels and goroutines sit between these two extremes. By themselves, they aren't a solution to much. But they are powerful enough to be easily arranged to enable solutions to many common problems in concurrent software. Doing less—really doing just enough—enables more.

Next, types and interfaces. Having static types enables useful compile-time checking, something lacking in dynamically-typed languages like Python or Ruby. At the same time, Go's static typing avoids much of the repetition of traditional statically typed languages, making it feel more lightweight, more like the dynamically-typed languages. This was one of the first things people noticed, and many of Go's early adopters came from dynamically-typed languages.

Go's interfaces are a key part of that. In particular, omitting the ``implements'' declarations of Java or other languages with static hierarchy makes interfaces lighter weight and more flexible. Not having that rigid hierarchy enables idioms such as test interfaces that describe existing, unrelated production implementations. Doing less enables more.

Next, testing and benchmarking. Is there any shortage of testing and benchmarking frameworks in most languages? Is there any agreement between them?

Go's testing package is not meant to address every possible facet of these topics. Instead, it is meant to provide the basic concepts necessary for most higher-level tooling. Packages have test cases that pass, fail, or are skipped. Packages have benchmarks that run and can be measured by various metrics.

Doing less here is an attempt to reduce these concepts to their essence, to create a shared vocabulary so that richer tools can interoperate. That agreement enables higher-level testing software like Miki Tebeka's go2xunit converter, or the benchcmp and benchstat benchmark analysis tools.

Because there is agreement about the representation of the basic concepts, these higher-level tools work for all Go packages, not just ones that make the effort to opt in, and they interoperate with each other, in that using, say, go2xunit does not preclude also using benchstat, the way it would if these tools were, say, plugins for competing testing frameworks. Doing less enables more.

Next, refactoring and program analysis. Because Go is for large code bases, we knew it would need to support automatic maintenance and updating of source code. We also knew that this topic was too large to build in directly. But we knew one thing that we had to do. In our experience attempting automated program changes in other settings, the most significant barrier we hit was actually writing the modified program out in a format that developers can accept.

In other languages, it's common for different teams to use different formatting conventions. If an edit by a program uses the wrong convention, it either writes a section of the source file that looks nothing like the rest of the file, or it reformats the entire file, causing unnecessary and unwanted diffs.

Go does not have this problem. We designed the language to make gofmt possible, we worked hard to make gofmt's formatting acceptable for all Go programs, and we made sure gofmt was there from day one of the original public release. Gofmt imposes such uniformity that automated changes blend into the rest of the file. You can't tell whether a particular change was made by a person or a computer. We didn't build explicit refactoring support. Establishing an agreed-upon formatting algorithm was enough of a shared base for independent tools to develop and to interoperate. Gofmt enabled gofix, goimports, eg, and other tools. I believe the work here is only just getting started. Even more can be done.

Last, building and sharing software. In the run up to Go 1, we built goinstall, which became what we all know as "go get". That tool defined a standard zero-configuration way to resolve import paths on sites like github.com, and later a way to resolve paths on other sites by making HTTP requests. This agreed-upon resolution algorithm enabled other tools that work in terms of those paths, most notably Gary Burd's creation of godoc.org. In case you haven't used it, you go to godoc.org/the-import-path for any valid "go get" import path, and the web site will fetch the code and show you the documentation for it. A nice side effect of this has been that godoc.org serves as a rough master list of the Go packages publicly available. All we did was give import paths a clear meaning. Do less, enable more.

You'll notice that many of these tooling examples are about establishing a shared convention. Sometimes people refer to this as Go being “opinionated,” but there's something deeper going on. Agreeing to the limitations of a shared convention is a way to enable a broad class of tools that interoperate, because they all speak the same base language. This is a very effective way to do less but enable more. Specifically, in many cases we can do the minimum required to establish a shared understanding of a particular concept, like remote imports, or the proper formatting of a source file, and thereby enable the creation of packages and tools that work together because they all agree about those core details.

I'm going to return to that idea later.

Why is Go open source?

But first, as I said earlier, I want to explain how I see the balance of Do Less and Enable More guiding our work on the broader Go open source project. To do that, I need to start with why Go is open source at all.

Google pays me and others to work on Go, because, if Google's programmers are more productive, Google can build products faster, maintain them more easily, and so on. But why open source Go? Why should Google share this benefit with the world?

Of course, many of us worked on open source projects before Go, and we naturally wanted Go to be part of that open source world. But our preferences are not a business justification. The business justification is that Go is open source because that's the only way that Go can succeed. We, the team that built Go within Google, knew this from day one. We knew that Go had to be made available to as many people as possible for it to succeed.

Closed languages die.

A language needs large, broad communities.

A language needs lots of people writing lots of software, so that when you need a particular tool or library, there's a good chance it has already been written, by someone who knows the topic better than you, and who spent more time than you have to make it great.

A language needs lots of people reporting bugs, so that problems are identified and fixed quickly. Because of the much larger user base, the Go compilers are much more robust and spec-compliant than the Plan 9 C compilers they're loosely based on ever were.

A language needs lots of people using it for lots of different purposes, so that the language doesn't overfit to one use case and end up useless when the technology landscape changes.

A language needs lots of people who want to learn it, so that there is a market for people to write books or teach courses, or run conferences like this one.

None of this could have happened if Go had stayed within Google. Go would have suffocated inside Google, or inside any single company or closed environment.

Fundamentally, Go must be open, and Go needs you. Go can't succeed without all of you, without all the people using Go for all different kinds of projects all over the world.

In turn, the Go team at Google could never be large enough to support the entire Go community. To keep scaling, we need to enable all this ``more'' while doing less. Open source is a huge part of that.

Go's open source

What does open source mean? The minimum requirement is to open the source code, making it available under an open source license, and we've done that.

But we also opened our development process: since announcing Go, we've done all our development in public, on public mailing lists open to all. We accept and review source code contributions from anyone. The process is the same whether you work for Google or not. We maintain our bug tracker in public, we discuss and develop proposals for changes in public, and we work toward releases in public. The public source tree is the authoritative copy. Changes happen there first. They are only brought into Google's internal source tree later. For Go, being open source means that this is a collective effort that extends beyond Google, open to all.

Any open source project starts with a few people, often just one, but with Go it was three: Robert Griesemer, Rob Pike, and Ken Thompson. They had a vision of what they wanted Go to be, what they thought Go could do better than existing languages, and Robert will talk more about that tomorrow morning. I was the next person to join the team, and then Ian Taylor, and then, one by one, we've ended up where we are today, with hundreds of contributors.

Thank You to the many people who have contributed code or ideas or bug reports to the Go project so far. We tried to list everyone we could in our space in the program today. If your name is not there, I apologize, but thank you.

I believe the hundreds of contributors so far are working toward a shared vision of what Go can be. It's hard to put words to these things, but I did my best to explain one part of the vision earlier: Do Less, Enable More.

Google's role

A natural question is: What is the role of the Go team at Google, compared to other contributors? I believe that role has changed over time, and it continues to change. The general trend is that over time the Go team at Google should be doing less and enabling more.

In the very early days, before Go was known to the public, the Go team at Google was obviously working by itself. We wrote the first draft of everything: the specification, the compiler, the runtime, the standard library.

Once Go was open sourced, though, our role began to change. The most important thing we needed to do was communicate our vision for Go. That's difficult, and we're still working at it.. The initial implementation was an important way to communicate that vision, as was the development work we led that resulted in Go 1, and the various blog posts, and articles, and talks we've published.

But as Rob said at Gophercon last year, "the language is done." Now we need to see how it works, to see how people use it, to see what people build. The focus now is on expanding the kind of work that Go can help with.

Google's primarily role is now to enable the community, to coordinate, to make sure changes work well together, and to keep Go true to the original vision.

Google's primary role is: Do Less. Enable More.

I mentioned earlier that we'd rather have a small number of features that enable, say, 90% of the target use cases, and avoid the orders of magnitude more features necessary to reach 99 or 100%. We've been successful in applying that strategy to the areas of software that we know well. But if Go is to become useful in many new domains, we need experts in those areas to bring their expertise to our discussions, so that together we can design small adjustments that enable many new applications for Go.

This shift applies not just to design but also to development. The role of the Go team at Google continues to shift more to one of guidance and less of pure development. I certainly spend much more time doing code reviews than writing code, more time processing bug reports than filing bug reports myself. We need to do less and enable more.

As design and development shift to the broader Go community, one of the most important things we the original authors of Go can offer is consistency of vision, to help keep Go Go. The balance that we must strike is certainly subjective. For example, a mechanism for extensible syntax would be a way to enable more ways to write Go code, but that would run counter to our goal of having a consistent language without different dialects.

We have to say no sometimes, perhaps more than in other language communities, but when we do, we aim to do so constructively and respectfully, to take that as an opportunity to clarify the vision for Go.

Of course, it's not all coordination and vision. Google still funds Go development work. Rick Hudson is going to talk later today about his work on reducing garbage collector latency, and Hana Kim is going to talk tomorrow about her work on bringing Go to mobile devices. But I want to make clear that, as much as possible, we aim to treat development funded by Google as equal to development funded by other companies or contributed by individuals using their spare time. We do this because we don't know where the next great idea will come from. Everyone contributing to Go should have the opportunity to be heard.

Examples

I want to share some evidence for this claim that, over time, the original Go team at Google is focusing more on coordination than direct development.

First, the sources of funding for Go development are expanding. Before the open source release, obviously Google paid for all Go development. After the open source release, many individuals started contributing their time, and we've slowly but steadily been growing the number of contributors supported by other companies to work on Go at least part-time, especially as it relates to making Go more useful for those companies. Today, that list includes Canonical, Dropbox, Intel, Oracle, and others. And of course Gophercon and the other regional Go conferences are organized entirely by people outside Google, and they have many corporate sponsors besides Google.

Second, the conceptual depth of Go development done outside the original team is expanding.

Immediately after the open source release, one of the first large contributions was the port to Microsoft Windows, started by Hector Chu and completed by Alex Brainman and others. More contributors ported Go to other operating systems. Even more contributors rewrote most of our numeric code to be faster or more precise or both. These were all important contributions, and very much appreciated, but for the most part they did not involve new designs.

More recently, a group of contributors led by Aram Hăvărneanu ported Go to the ARM 64 architecture, This was the first architecture port by contributors outside Google. This is significant, because in general support for a new architecture requires more design work than support for a new operating system. There is more variation between architectures than between operating systems.

Another example is the introduction over the past few releases of preliminary support for building Go programs using shared libraries. This feature is important for many Linux distributions but not as important for Google, because we deploy static binaries. We have been helping guide the overall strategy, but most of the design and nearly all of the implementation has been done by contributors outside Google, especially Michael Hudson-Doyle.

My last example is the go command's approach to vendoring. I define vendoring as copying source code for external dependencies into your tree to make sure that they doesn't disappear or change underfoot.

Vendoring is not a problem Google suffers, at least not the way the rest of the world does. We copy open source libraries we want to use into our shared source tree, record what version we copied, and only update the copy when there is a need to do so. We have a rule that there can only be one version of a particular library in the source tree, and it's the job of whoever wants to upgrade that library to make sure it keeps working as expected by the Google code that depends on it. None of this happens often. This is the lazy approach to vendoring.

In contrast, most projects outside Google take a more eager approach, importing and updating code using automated tools and making sure that they are always using the latest versions.

Because Google has relatively little experience with this vendoring problem, we left it to users outside Google to develop solutions. Over the past five years, people have built a series of tools. The main ones in use today are Keith Rarick's godep, Owen Ou's nut, and the gb-vendor plugin for Dave Cheney's gb,

There are two problems with the current situation. The first is that these tools are not compatible out of the box with the go command's "go get". The second is that the tools are not even compatible with each other. Both of these problems fragment the developer community by tool.

Last fall, we started a public design discussion to try to build consensus on some basics about how these tools all operate, so that they can work alongside "go get" and each other.

Our basic proposal was that all tools agree on the approach of rewriting import paths during vendoring, to fit with "go get"'s model, and also that all tools agree on a file format describing the source and version of the copied code, so that the different vendoring tools can be used together even by a single project. If you use one today, you should still be able to use another tomorrow.

Finding common ground in this way was very much in the spirit of Do Less, Enable More. If we could build consensus about these basic semantic aspects, that would enable "go get" and all these tools to interoperate, and it would enable switching between tools, the same way that agreement about how Go programs are stored in text files enables the Go compiler and all text editors to interoperate. So we sent out our proposal for common ground.

Two things happened.

First, Daniel Theophanes started a vendor-spec project on GitHub with a new proposal and took over coordination and design of the spec for vendoring metadata.

Second, the community spoke with essentially one voice to say that rewriting import paths during vendoring was not tenable. Vendoring works much more smoothly if code can be copied without changes.

Keith Rarick posted an alternate proposal for a minimal change to the go command to support vendoring without rewriting import paths. Keith's proposal was configuration-free and fit in well with the rest of the go command's approach. That proposal will ship as an experimental feature in Go 1.5 and likely enabled by default in Go 1.6. And I believe that the various vendoring tool authors have agreed to adopt Daniel's spec once it is finalized.

The result is that at the next Gophercon we should have broad interoperability between vendoring tools and the go command, and the design to make that happen was done entirely by contributors outside the original Go team.

Not only that, the Go team's proposal for how to do this was essentially completely wrong. The Go community told us that very clearly. We took that advice, and now there's a plan for vendoring support that I believe everyone involved is happy with.

This is also a good example of our general approach to design. We try not to make any changes to Go until we feel there is broad consensus on a well-understood solution. For vendoring, feedback and design from the Go community was critical to reaching that point.

This general trend toward both code and design coming from the broader Go community is important for Go. You, the broader Go community, know what is working and what is not in the environments where you use Go. We at Google don't. More and more, we will rely on your expertise, and we will try to help you develop designs and code that extend Go to be useful in more settings and fit well with Go's original vision. At the same time, we will continue to wait for broad consensus on well-understood solutions.

This brings me to my last point.

Code of Conduct

I've argued that Go must be open, and that Go needs your help.

But in fact Go needs everyone's help. And everyone isn't here.

Go needs ideas from as many people as possible.

To make that a reality, the Go community needs to be as inclusive, welcoming, helpful, and respectful as possible.

The Go community is large enough now that, instead of assuming that everyone involved knows what is expected, I and others believe that it makes sense to write down those expectations explicitly. Much like the Go spec sets expectations for all Go compilers, we can write a spec setting expectations for our behavior in online discussions and in offline meetings like this one.

Like any good spec, it must be general enough to allow many implementations but specific enough that it can identify important problems. When our behavior doesn't meet the spec, people can point that out to us, and we can fix the problem. At the same time, it's important to understand that this kind of spec cannot be as precise as a language spec. We must start with the assumption that we will all be reasonable in applying it.

This kind of spec is often referred to as a Code of Conduct. Gophercon has one, which we've all agreed to follow by being here, but the Go community does not. I and others believe the Go community needs a Code of Conduct.

But what should it say?

I believe the most important overall statement we can make is that if you want to use or discuss Go, then you are welcome here, in our community. That is the standard I believe we aspire to.

If for no other reason (and, to be clear, there are excellent other reasons), Go needs as large a community as possible. To the extent that behavior limits the size of the community, it holds Go back. And behavior can easily limit the size of the community.

The tech community in general and the Go community in particular is skewed toward people who communicate bluntly. I don't believe this is fundamental. I don't believe this is necessary. But it's especially easy to do in online discussions like email and IRC, where plain text is not supplemented by the other cues and signals we have in face-to-face interactions.

For example, I have learned that when I am pressed for time I tend to write fewer words, with the end result that my emails seem not just hurried but blunt, impatient, even dismissive. That's not how I feel, but it's how I can come across, and that impression can be enough to make people think twice about using or contributing to Go. I realized I was doing this when some Go contributors sent me private email to let me know. Now, when I am pressed for time, I pay extra attention to what I'm writing, and I often write more than I naturally would, to make sure I'm sending the message I intend.

I believe that correcting the parts of our everyday interactions, intended or not, that drive away potential users and contributors is one of the most important things we can all do to make sure the Go community continues to grow. A good Code of Conduct can help us do that.

We have no experience writing a Code of Conduct, so we have been reading existing ones, and we will probably adopt an existing one, perhaps with minor adjustments. The one I like the most is the Django Code of Conduct, which originated with another project called SpeakUp! It is structured as an elaboration of a list of reminders for everyday interaction.

"Be friendly and patient. Be welcoming. Be considerate. Be respectful. Be careful in the words that you choose. When we disagree, try to understand why."

I believe this captures the tone we want to set, the message we want to send, the environment we want to create for new contributors. I certainly want to be friendly, patient, welcoming, considerate, and respectful. I won't get it exactly right all the time, and I would welcome a helpful note if I'm not living up to that. I believe most of us feel the same way.

I haven't mentioned active exclusion based on or disproportionately affecting race, gender, disability, or other personal characteristics, and I haven't mentioned harassment. For me, it follows from what I just said that exclusionary behavior or explicit harassment is absolutely unacceptable, online and offline. Every Code of Conduct says this explicitly, and I expect that ours will too. But I believe the SpeakUp! reminders about everyday interactions are an equally important statement. I believe that setting a high standard for those everyday interactions makes extreme behavior that much clearer and easier to deal with.

I have no doubts that the Go community can be one of the most friendly, welcoming, considerate, and respectful communities in the tech industry. We can make that happen, and it will be a benefit and credit to us all.

Andrew Gerrand has been leading the effort to adopt an appropriate Code of Conduct for the Go community. If you have suggestions, or concerns, or experience with Codes of Conduct, or want to be involved, please find Andrew or me during the conference. If you'll still be here on Friday, Andrew and I are going to block off some time for Code of Conduct discussions during Hack Day.

Again, we don't know where the next great idea will come from. We need all the help we can get. We need a large, diverse Go community.

Thank You

I consider the many people releasing software for download using “go get,” sharing their insights via blog posts, or helping others on the mailing lists or IRC to be part of this broad open source effort, part of the Go community. Everyone here today is also part of that community.

Thank you in advance to the presenters who over the next few days will take time to share their experiences using and extending Go.

Thank you in advance to all of you in the audience for taking the time to be here, to ask questions, and to let us know how Go is working for you. When you go back home, please continue to share what you've learned. Even if you don't use Go for daily work, we'd love to see what's working for Go adopted in other contexts, just as we're always looking for good ideas to bring back into Go.

Thank you all again for making the effort to be here and for being part of the Go community.

For the next few days, please: tell us what we're doing right, tell us what we're doing wrong, and help us all work together to make Go even better.

Remember to be friendly, patient, welcoming, considerate, and respectful.

Above all, enjoy the conference.


Matt Farina

unread,
May 28, 2019, 3:32:30 PM5/28/19
to golang-nuts
Russ,

I'm happy you updated the public docs on the proposal review process. It is much more clear now. Thanks.

Thanks for publicly listing the people on the review process. It helps people have insights. And, thanks for listing Peter who is not on that GitHub team. He's a Googler I didn't realize was helping with the reviews.

I wonder, would it make sense to document this list of people in the proposal review process? Call it my over-documentation bias that I've gotten from CNCF projects. Where the people who own something are documented.

- Matt

Slawomir Pryczek

unread,
May 28, 2019, 10:12:27 PM5/28/19
to golang-nuts
Come on, open your minds a little. Once every 5 years it doesn't hurt to learn some new, better ways of doing things. And if someone wants to write java code untill he dies, then there's a great method of doing that called "stick to java" ;)

That same kind of thinking already marginalized nodejs. The code written in it is horrible because almost everyone is trying to emulate c++ and java instead of taking one week to learn the language a bit and JS is so flexible you can actually do that to some extent. Not sure why some people think that every language on the planet needs to be a bad clone of c++ or java.... probably putting "java" in its name doesn't help. Thanks GOD it's golang, not go++, we'd be doomed.

Seriously. For me - against generics because of amount of complexity and issues it'd introduce into the language. Would be cool to see a fork implementing it because maybe it can be done "nicely", however i doubt it... It brings to mind Rust's multithreading paradigms. That's actually great stuff...  but totally unfit for integrating with golang (for this im preety sure). Hopefully, if generics will be implemented it won't be integrated too tightly so i won't have to get back to writing code which is more jav'ish that it needs to be. Because, that's a crazy idea... if i liked how java works more i'd just use java ;) And introducing operator overloading into this beautiful design will be like putting readability back into medieval ages...

Max

unread,
May 29, 2019, 4:28:50 AM5/29/19
to golang-nuts
Although it's slightly off-topic, there are already some Go forks or variants that implement generics.

One is Fo https://github.com/albrow/fo - a source-to-source transpiler that converts "Go with generics" to plain Go
Another is my https://github.com/cosmos72/gomacro - a Go interpreter with generics (C++ style generics are complete; a second alternative implementation more closely following Go generics proposals is in progress).

I think there may be others I don't know about.

JuciÊ Andrade

unread,
May 29, 2019, 7:55:19 AM5/29/19
to golang-nuts
Registering Go as a trademark is important to protect it against improper use.
Let's not forget "Sun vs Microsoft" fighting to define what could be named "Java".


On Friday, May 24, 2019 at 3:49:18 AM UTC-3, Rob 'Commander' Pike wrote:
If that's true - and it might well not be - it's a surprise to me. When launching the language we explicitly made sure NOT to trademark it.

-rob


On Fri, May 24, 2019 at 10:50 AM Gerald Henriksen <ghen...@gmail.com> wrote:
On Fri, 24 May 2019 07:40:52 +1000, you wrote:

>The last sentence of the article is not correct. The name Go is not
>trademarked by Google, at least as a programming language trademark. There
>are other things Google makes called Go (an interesting signal on its own)
>and they might be trademarked, but Go the language is not a trademark.

The link provided in the blog post would seem to indicate otherwise.

If one scrolls down the list the following 2 entries are of interest:

Golang™ programming language
Go™ programming language

https://www.google.com/permissions/trademark/trademark-list/

Robert Engels

unread,
May 29, 2019, 8:02:22 AM5/29/19
to golang-nuts
Watch out, you must not mention java here - at a minimum spell it with lowercase so you can pretend you were talking about coffee  :)
--
You received this message because you are subscribed to the Google Groups "golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts...@googlegroups.com.

lgo...@gmail.com

unread,
May 29, 2019, 11:49:41 AM5/29/19
to golang-nuts
My thanks to all ... This thread has provided me a wealth of interesting and varied ideas regarding Go user community viewpoints on Go governance.

For what its worth here's my 'two cents' worth ...

In the end, every Go user has only one 'Go' he/she can choose to use....Regardless of how, why and who etc. determines future directions of the language, the only real alternative a user has is to accept Go 'as is' or move on to something else ..If you choose to stay with Go, you have to accept it for what it is , not what you'd like it to be.

If you decide to stay with Go, this doesn't mean you have to stop advocating /supporting  changes to the language and/or changes to how the language is governed. ....
As an aside, I'm one of the 'golang-nuts' who support adding a modernized version of the C ternary operator to Go, but many of my other golang-nuts think I'm 'nuts'  I also vote 'no' regarding generics.....

If a Go user decides to move on to something else,  you'll still end up with governance issues ..
At one extreme you can move on to Python  which is governed by the  BDFL Guido van Rossum philosophy. 
Did van R do great things for Python ?  ...Let me answer this by saying  that with I never got past the nightmare I experienced trying to install PIP, NumPy and SciPy packages on my Windows box.

At the other extreme you can move on to to something like C++ with a system of governance that can only be described as "Wild West"

For me the Governance issue is very much secondary to my more major issue which is the availability of packages I need to support the apps I want to develop.

For me, this is where Go ranks way above the other languages I've tried over my many years as a developer.
When I first moved over to Go the first package I wanted to get up and running was the Go "image" package.
It took me less that an hour to port one of my major C++ libPNG based image processing apps over to Go. 
This was enough to make me a Go believer considering the many months I wasted developing PNG image processing apps  using C++ and libPNG.

I could go on and on regarding similar experiences I've had with other Go packages, but my point is that, for me, 
Go's system of package management and its spectrum of available Go packages is what makes Go superior to other languages.

I'm am old timer with lots of C++ apps that I developed over the years before I switched over to Go.
I've ported many of these apps to Go, except for those that require too much time for me to convert, or those that require packages that are not available in Go.  So for now I have to live with both Go and C++.

Go governance is important but,  for me it is much less important than package availability and the ability to get packages up and running quickly.

So my my major issue is involves adding more packages to Go,  especially math-sci-engineering oriented packages so I can avoid having to switch over to Julia (or worse yet FORTRAN) when I need to develop these kind of apps.   
Yea, I've tried packages available on https://godoc.org/gonum.org/v1/gonum  but I find many of these Go packages are primitive compared to those available in C++ (and in some cases even FORTAN)

Any way, that's my "two pennies" worth


On Thursday, May 23, 2019 at 9:18:25 AM UTC-4, L Godioleskky wrote:

Sam Whited

unread,
May 29, 2019, 12:12:02 PM5/29/19
to golan...@googlegroups.com
On Thu, May 23, 2019, at 17:59, Ian Lance Taylor wrote:
> But (and here you'll just have to trust me) 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. Of
> course, there's no reason for them to. Go is doing fine, so why
> should they interfere? And what could they gain if they did
> interfere? So they leave us alone.

I wanted to further comment on this particular point, since I keep
seeing it brought up and have had it mentioned to me several times OOB
in the context of "why would you care if the Go team can push through
proposals and immediately merge implementations with limited community
input or without the opportunity for alternatives,?Google execs aren't
making these decisions, the Go team is!"

I believe you when you say that upper management has never interfered
with the direction of Go, but the point is that they could in the
future. Not having a community check on the Go core team means there is
no community check on the future Go core team, or higher up execs that
decide they want a finger in the pie. We don't know who will be in
charge of the Go team in 10 or 20 years, and they may be less principled
than the current team. We also don't know how Google will have changed,
or what kinds of pressures might be put on the Go team from a future over-
zealous Google executive who wants a hand in the proposal process pie.

—Sam

da4...@gmail.com

unread,
May 29, 2019, 1:20:06 PM5/29/19
to golang-nuts
A quick search of the USPTO trademarks database reveals:

Mark Image
Word Mark GO
Goods and Services IC 009. US 021 023 026 036 038. G & S: Computer programs and downloadable computer programs that implement a computer programming language for use in developing, building and managing other software
Mark Drawing Code (3) DESIGN PLUS WORDS, LETTERS, AND/OR NUMBERS
Design Search Code 26.17.01 - Bands, straight ; Bars, straight ; Lines, straight ; Straight line(s), band(s) or bar(s)
26.17.06 - Bands, diagonal ; Bars, diagonal ; Diagonal line(s), band(s) or bar(s) ; Lines, diagonal
Serial Number 88100957
Filing Date August 31, 2018
Current Basis 1B
Original Filing Basis 1B
Owner (APPLICANT) Google LLC LIMITED LIABILITY COMPANY DELAWARE 1600 Amphitheatre Parkway Mountain View CALIFORNIA 94043
Description of Mark Color is not claimed as a feature of the mark. The mark consists of the stylized word GO with three small lines to the left of the word.
Type of Mark TRADEMARK
Register PRINCIPAL
Live/Dead Indicator LIVE


Mark Image
Word Mark GO
Goods and Services IC 009. US 021 023 026 036 038. G & S: Computer programs and downloadable computer programs that implement a computer programming language for use in developing, building and managing other software. FIRST USE: 20091110. FIRST USE IN COMMERCE: 20091110
Standard Characters Claimed
Mark Drawing Code (4) STANDARD CHARACTER MARK
Serial Number 88100955
Filing Date August 31, 2018
Current Basis 1A
Original Filing Basis 1A
Owner (APPLICANT) Google LLC LIMITED LIABILITY COMPANY DELAWARE 1600 Amphitheatre Parkway Mountain View CALIFORNIA 94043
Type of Mark TRADEMARK
Register PRINCIPAL
Live/Dead Indicator LIVE

I wasn't able to check "golang" because the USPTO web site's search facility had a meltdown.



d

Ian Lance Taylor

unread,
May 29, 2019, 5:20:35 PM5/29/19
to Sam Whited, golang-nuts
The ultimate community check is to power to fork the project. I've
personally been involved in a successful fork of a significant free
software project (search for EGCS in
https://en.wikipedia.org/wiki/GNU_Compiler_Collection) so I know that
it is possible.

Of course that's not necessarily helpful in practice. I actually
agree with earlier comments by Matt Farina that Go is currently open
source but not open governance. What I'm not sure about is how much
it matters.

Also, the open source release of Go was (slightly) less than 10 years
ago. Languages like C and C++ did not have any sort of governance
model at this stage of their development. I don't know what the Go
ecosystem will look like in 10 years, but I know it will be different
than it is today.

Ian

Paul Jolly

unread,
May 30, 2019, 2:01:37 PM5/30/19
to golang-nuts
Just to expand on Russ' point about golang-tools:
 
In fact there is now a roughly biweekly “Go tools” meeting which is typically attended by more tool and editor integration authors from outside Google than from inside Google and organized by a contributor outside Google. (If you want to know more about that, email Paul Jolly, pa...@myitcv.io.)

More details available in the golang-tools wiki: https://github.com/golang/go/wiki/golang-tools, including links to YouTube recordings and notes from previous sessions. 

Our standards have slipped somewhat and we now meet on Hangouts once a month, but that somewhat belies the huge progress currently being made with gopls, go/packages, go/analysis and all the various editors integrations. 

The (now) monthly calls, mailing list and Slack channels are open to everyone.

Please feel free to email me (pa...@myitcv.io) or join https://groups.google.com/forum/#!forum/golang-tools if you have any questions.

Thanks


David Skinner

unread,
May 30, 2019, 7:33:30 PM5/30/19
to golang-nuts
I only rarely use generics in Go. When I do so, it is implemented using the +generate. The repos with my generics stuff is not public. If they were, they might be incomprehensible. While I rather like Fo, the thought of C++ style generics makes me cringe. Code must compile but it needs to be readable.

I am very old school, I started programming with 8008 machine code. If something does not meet my needs, I may complain, but I may just write what I need. Go does not have generics but it is very easy for any user to implement generics in a variety of ways on an as needed basis. The thing is, I am not committed to Go, I am willing to use whatever works best for me, and right now that is Go, and I believe that that is the result of the experience of the Go team residing at Google in working as a team.

I remember doing a code review at Sierra Online, it was a metrics project to evaluate employee performance, one programmer was so bad, I asked the head of the programming department to have him shot. He said, you want him fired? No, I want him shot, if you fire him, he will go and write bad code somewhere else. For some reason I do not understand, the company had a policy against shooting programmers that violated the style guidelines.

When this is your life and your livelihood, it is easy to