Re: [go-nuts] Interesting public commentary on Go...

[Paul Jolly]

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 (p...@myitcv.io) or join 
https://groups.google.com/forum/#!forum/golang-tools if you have any 
questions.

Thanks


-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/beefdd05-b5b9-41cc-881e-878f2e8325d0%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Interesting public commentary on Go...

[Ian Lance Taylor]

On Wed, May 29, 2019 at 12:11 PM Sam Whited  wrote:
>
> 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.

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

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAOyqgcUofZ2_WLaR6T8XhD3pAzyqcou6CQvs-aswVda5XtHqHQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Interesting public commentary on Go...

[Sam Whited]

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

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/1358d19f-b7a6-46db-b970-35c0f7c640d7%40www.fastmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Interesting public commentary on Go...

[Matt Farina]

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

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/af37f0f7-74b6-496c-952a-600cdfded3f8%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Interesting public commentary on Go...

[Russ Cox]

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, p...@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 

Re: [go-nuts] Interesting public commentary on Go...

[Matt Farina]

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  > 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  > 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.*

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/55d512bb-5afd-4487-9a5c-cc9f48ba683d%40googlegroups.com.
For 

Re: [go-nuts] Interesting public commentary on Go...

[Russ Cox]

On Mon, May 27, 2019 at 7:08 PM Matt Farina  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  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

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAA8EjDR_qT0HCT%3DCiZbOW2NrkyD6gCQ3_5gPTH12MVK71GQyYA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Interesting public commentary on Go...

[Matt Farina]

> 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.
 

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/555dbcc3-0c51-4a03-b261-b57a79a740a9%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Interesting public commentary on Go...

['Axel Wagner' via golang-nuts]

On Tue, May 28, 2019 at 1:08 AM Matt Farina  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.


> 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
> mattfarina.com
>
> Go in Practice  - A book of Recipes for the
> Go programming language.
>
> Code Engineered  - A blog on cloud, web, and
> software development.
>

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAEkBMfEVzrqYPoDDRgVtJFL9mL9gSLLv6usC0guPB-RJLDdTSA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Interesting public commentary on Go...

[Matt Farina]

>
>
>> 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
mattfarina.com

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

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

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAMPAG2qWS4j4gMJVuPc5EJqSDkE5%2BMhL1crUDqNJ2UXX%3Dt8y9w%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Interesting public commentary on Go...

[Wojciech S. Czarnecki]

On Mon, 27 May 2019 12:31:22 -0700 (PDT)
Liam  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

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/20190527224113.5f5554b0%40zuzia.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Interesting public commentary on Go...

['Axel Wagner' via golang-nuts]

On Mon, May 27, 2019 at 9:16 PM Matt Farina  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+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/a6669e65-acd5-47bc-bdf2-d2cbe3c3d205%40googlegroups.com
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAEkBMfHCdNSHS7ead01DoxZ4q0Wc4w38%2B29T0jFy6KeECLX4RQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Interesting public commentary on Go...

[Ian Lance Taylor]

On Mon, May 27, 2019 at 1:35 AM Axel Wagner
 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  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

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAOyqgcWPZ6NZHk8QdGpLaM4vg0dWu7Q0_S-LC5w6EjLh8KwaRQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Interesting public commentary on Go...

[Ian Lance Taylor]

On Thu, May 23, 2019 at 8:50 PM  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=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

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAOyqgcVaQCD4A%2BBcLyT3Cy%3Dv5eBmiLuMDZq9ii_jvU2X8S4JmA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Interesting public commentary on Go...

[Liam]

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
https://github.com/golang/go/issues/29860

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.


On Thursday, May 23, 2019 at 5:50:22 PM UTC-7, 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 . 
>
>

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/113be4cf-9273-4a49-82f1-636ba1930ea2%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Interesting public commentary on Go...

[Matt Farina]

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.

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/a6669e65-acd5-47bc-bdf2-d2cbe3c3d205%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Interesting public commentary on Go...

['Axel Wagner' via 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).

On Mon, May 27, 2019 at 9:44 AM Space A.  wrote:

> 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 <
> golang-nuts@googlegroups.com>:
>
>> 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  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.
>>
>>
>>>
>>> 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 

Re: [go-nuts] Interesting public commentary on Go...

[Space A.]

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 <
golang-nuts@googlegroups.com>:

> 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  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.
>
>
>>
>> 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 

[go-nuts] Interesting public commentary on Go...

[stephen]

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

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/2a1f94f7-8f33-4b69-9a40-6af7ff6ae5e4%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Interesting public commentary on Go...

[lgodio2]

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.  


On Thursday, May 23, 2019 at 1:59:57 PM UTC-4, Ian Lance Taylor wrote:
>
> On Thu, May 23, 2019 at 9:18 AM > 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 

Re: [go-nuts] Interesting public commentary on Go...

[Sam Whited]

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

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/5f44b16e-d79a-446c-876c-9d4d222f595d%40www.fastmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Interesting public commentary on Go...

[Anthony Martin]

Sam Whited  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

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/20190523222743.GA28121%40alice.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Interesting public commentary on Go...

[Tom Mitchell]

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  wrote:

> https://utcc.utoronto.ca/~cks/space/blog/programming/GoIsGooglesLanguage
>
> --
> 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+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/ac6843c0-38fc-4388-a1dd-2dd2b78c0ac3%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>


-- 
   T o mM i t c h e l l

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAAMy4URk2teSF6x3Uqd-ABcZ-FWU-To8mCQzEKZZejtuJVRhYg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Interesting public commentary on Go...

[Sam Whited]

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

On Thu, May 23, 2019, at 19:22, 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).
>
> 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

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/8e351aff-da3f-4db0-b9a0-7f54c1cf73c5%40www.fastmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Interesting public commentary on Go...

[Sam Whited]

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.

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/3c68c1ce-53bd-4f17-be48-d8bd0f69%40www.fastmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Interesting public commentary on Go...

[Daniela Petruzalek]

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
github.com/danicat
twitter.com/danicat83


Em qui, 23 de mai de 2019 às 18:59, Ian Lance Taylor 
escreveu:

> On Thu, May 23, 2019 at 9:18 AM  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 

Re: [go-nuts] Interesting public commentary on Go...

[Ian Lance Taylor]

On Thu, May 23, 2019 at 9:18 AM  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, 

[go-nuts] Interesting public commentary on Go...

[lgodio2]

https://utcc.utoronto.ca/~cks/space/blog/programming/GoIsGooglesLanguage

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/ac6843c0-38fc-4388-a1dd-2dd2b78c0ac3%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.