Hacker News Reader

I'd wager that nobody would complain if Google donated Go to an open organization such as CNCF [1]. The CNCF is a good fit because it already hosts the world's most prominent Go projects, including Kubernetes and Prometheus.

While Google is certainly a big bish in that pond, there are plenty of other big fish to balance them out, including Cisco, Red Hat/CoreOS, Github, IBM, Intel and Docker.

Or invent a new organization. Call it "the Go Foundation". Make sure it's independent and has the bylaws and administrative structure to prove it. It's worked out pretty well for Python [2].

[1] https://www.cncf.io/

[2] https://www.python.org/psf-landing/

I kind of get what you (and the articles) are driving at. Who will be the people that run it under that umbrella? You need some community buy in and corporate buy in.

Who will run it? Activists ? You want the top talent working in/on go to be the people that run it. Now if GvR (python) or equivalent was contributing to go and he is hey I’m an awesome developer and an awesome language designer what gives with side lining me.

That would be a point. But now most top go talent that are working on the language are at google

Just like with k8s google may create a foundation for it or donate to one of the existing one when there is diversity in top contributors. I assume hope. Perhaps this activism is early

If go wasn't a strongly opiniated language curated by the core team, I fear it wouldn't be the same go.

Example: I don't like all the things gofmt does, but if I accept what gofmt gives me, I can learn to live with it, and eventually be super happy :)

If go isn't opinionated, then what's the point? Whether owned by Google or a foundation, if the core team isn't small and opiniated, then aren't we just reinventing C++, hehe :)

Disclaimer: I work for Google, this is my personal opinion. (I actually haven't used golang since joining Google, but that's a different story)

There are two kinds of control: control via stewardship and control via contribution. Stewardship is the process of making final decisions. That could be done by some foundation, but if it's the same people, the decisions would be the same. But even when the stewards make the final decisions about what goes in, someone has to contribute the work. For large/complex open source projects, much of the contribution comes from people who are paid to work full-time on the project, and someone has to pay their salary; that someone is often a corporation. Even if a corporation does not have direct control via stewardship, they can still decide what kind of contributions they're willing to pay their full-time engineers to work on. For example, Linux stewardship is done by a foundation, but most of the contribution is done by corporations.

We see something similar in the Java world. Even though the Java stewards are mostly Oracle employees, Oracle does not exert direct control over stewardship; the OpenJDK lead is elected by the OpenJDK board (whose chairmanship is reserved for Oracle, but has non-Oracle members). However, Oracle also funds 90% of the OpenJDK contributors, and the company can decide they want to fund work in certain areas but not in others. E.g. Oracle has reduced investment on client-side Java; some of that work is now contributed by another corporation (Gluon), but the total resources for client work are still reduced.

Because Google has many people working on OpenJDK (I think about the same number as those working on Go), it also has a lot of influence, as it can contribute large features (like the thread sanitizer they're now contributing).

Here is an explanation of Java's governance by Mark Reinhold, who is the OpenJDK lead and also Chief Architect of the Java Platform Group at Oracle: https://youtu.be/HpbchS5kmio

> impact on core features of a language platform, like package management

In this specific case (which is important to the discussion) there effectively was nothing you could call "management" in what the core tooling provided for resolving and fetching dependencies. I think the reason it wasn't there, was because that wasn't very important to Google which famously operates a company-wide mono repo. Dependency management wasn't a problem Google had, so an official solution was a very long time coming, and left the interim solution providers feeling quite raw.

"There effectively was nothing you could call 'management'" is hyperbole. I know what you mean: you don't like the way they managed it. Ok. But this is a pretty good illustration of how there's no winning for the Go core team in responding to this stuff.

I honestly don't think its hyperbole. What we had with go get, would install different versions of dependencies each time you checked out your repository and built it. That isn't managed. Managed is what they recommended you to do, which is vendor all the dependencies, but that isn't something provided by the go tooling.

Honestly, that's a community problem.

If the code is guaranteed to work with the current version of the dependency and packages were built to not break their API, there would be no problem

I disagree with the idea that sticking with a specific version of a dependency is a good solution, it creates more problems than it solves

> packages were built to not break their API

That's a lovely sentiment, but it doesn't help much when you've got no consistency between checkouts and builds are failing because of upstream changes that the code you're trying to work with doesn't even know it's using, and to try to fix an issue first requires you to spend days dealing with bitrot.

Here are some principles: 1. only the team working on a component should be able to break the build of that component. 2. Components should not break outside of commits.

The truth is, that your 'API' ends up being every part of your behavior that is relied on by your dependents and their dependents, ad infinitum, and it's almost impossible to make improvements without breaking such an API. Sometimes bugs are part of your de facto API.

It's one thing to say 'people shouldn't depend on these features, look it even says so in the doc', but should and shouldn't are moral judgements, what is and what is not are the distinctions that drive whether your development and release process are fit for purpose.

> I disagree with the idea that sticking with a specific version of a dependency is a good solution, it creates more problems than it solves

Well, there can be debate on the volume of problems on either side, but some other ecosystems attack this with tooling that can automate the process of getting notified that there's an upstream change, rebuilding with the new version, running the automated tests, and making it super easy to accept a commit updating the dependencies if the tests all work.

> I disagree with the idea that sticking with a specific version of a dependency is a good solution, it creates more problems than it solves

Semver addresses this. You stick with a specific major version (or minor version for a 0.x release, where "minor" version changes can in fact introduce major breaks), and your dependency tool enforces this. However, it does still warn you if a newer version is available, so that you can start depending on it. (Of course, switching to a newer release is easier said than done if other modules might still depend on the previous one, and your build tool doesn't support the concurrent use of both in the same build!) This is essentially a solved problem.

I think it's disingenouous to call this a solved problem. Regardless of their appearance, very few projects actually follow this consistently, because it's a lot of work and almost impossible to be sure.

I'm with @jeremyjh on this one. There was no management. There was a "fuck it. works for me." kind-of half-assed implementation that was frankly terrible when compared to ANY of its contemporaries. It spawned a ton of competing "package managers" that attempted to do a better job but none of them "won" (probably because none were officially sanctioned) so you ended up dealing with like six of them in order to manage the dependencies of whatever random project you tried to work with.

No-one "managed" the problem. They just sat and watch the community flail around for years.

That's exactly what happens when a tool is left open to community

If the community cannot agree on a simple thing like the package manager, imagine what'll happen if it was in charge of evolving the language

That what's happen if the community has no say in what package manager is used or how it works and the community is not forced to use the official one and the community is not organized properly.

I would say it's what happens when a community is explicitly not allowed to solve a problem.

PHP, for all its warts, is 1) very community driven and 2) solved their package management problems via the community (with Composer). Go was not allowed to do that, because everyone knew that any solution had to be blessed by Google.

> If you don't want to use a project affiliated with Google, don't code in Go.

For what it's worth (and I say this is an outside observer who's never written any Go, so, grain of salt, etc.), I don't think the original post this responds to disagrees with your point. To wit, from that post:

> Or in short, Go has community contributions but it is not a community project. It is Google's project. This is an unarguable thing, whether you consider it to be good or bad, and it has effects that we need to accept. For example, if you want some significant thing to be accepted into Go, working to build consensus in the community is far less important than persuading the Go core team.

and

> PS: I like Go and have for a fair while now, and I'm basically okay with how the language has been evolving and how the Go core team has managed it.

I don't think he's saying "Go is bad" or even "the management of Go is bad," but rather something more like "people should be honest about the nature of the management of Go, and choose how to engage with the community and the process accordingly."

I believe everything that Russ Cox says here and don't think it will make a whit of different either. But thats because he does not refute the assertion in the original document.

Go _is_ Google's project. They may let other people contribute but if Google's interests are not maintained, and further if the small core group who run it inside of Google disagree, you should not assume there is any way to override that. That's literally the point of what the original document was saying.

Lots and lots of us can live with that, but it would be much better if the golang contribution process was more explicit about that.

I guess I just don't see the practical difference between "if Google's interests are not maintained" and "if the small core group who run it disagree". The latter describes lots of things! Very much Clojure, too! The former sounds ominous, but really means the same thing.

And with that lack of difference in mind: when the Go team says "Google's interests have little to do with how we're running Go", I'm strongly inclined to believe them, because what difference does it make? Why would they just make it up?

But really my point here is just: there's no point in the Go team engaging on this, because I literally can't think of a single thing Russ Cox could say to defuse this drama.

Perhaps, he could be honest and say, yeah, it's true. We don't think it's a problem because ... but it's something you'll have to live with if you are to use Go.

There's precedence, for instance, C# is Microsoft's turf.

Seems to me to be a basic human thing - if people are worried, downplaying their worries backfires.

He could simply agree. There is nothing wrong with the model they are cultivating.

But by not acknowledging it’s what they are doing they leave space for drama. Worse is if they think they are doing something else, because they are missing their intentions by a wide mark.

> But really my point here is just: there's no point in the Go team engaging on this, because I literally can't think of a single thing Russ Cox could say to defuse this drama.

As others, I think the easiest thing Cox could say in response to these posts is: "Yeah, you're right. Go is open source but it's not community driven. There's a small, insular core team, we have full control over the language, we have a clear vision, we're going to follow that vision, and we think the results so far have justified this approach. We hope you choose to continue to use and, where appropriate, contribute to the project and the larger ecosystem."

Go is a very impressive project, and the core team does have very tight control over it, and (very plausibly) that tight control is responsible for the quality of the language. I don't think it necessarily needs to change; certainly not any time soon. Why not embrace it?

And I think, if he did that, it would end the drama in a heartbeat, because what's left to discuss?

The words you put after "Yeah, you're right" don't actually square with the accusation being leveled at them. You're right, I think, that there's a small insular core team with full control and a clear vision. That doesn't make it "Google's project". Put differently: if Russ Cox resigned from Google, I imagine he'd probably remain involved with Go and have the same amount of influence.

My impression is that most criticism (certainly the criticism I've found valid and troubling) has been focused on whether Go is community driven, or controlled by a small team of core developers who just happen to currently work for Google.

Certainly there is some criticism than seems to focus on the idea that Go is controlled by Google, but I feel like that's, at most, a vocal minority. Then again, perhaps I just discount it because I find it pretty silly!

> Put differently: if Russ Cox resigned from Google, I imagine he'd probably remain involved with Go and have the same amount of influence.

I agree 100%.

(Of course, if your concern is how Russ Cox is managing Go, that probably doesn't make you feel better. If your concern is how Sundar Pichai is managing Go...well, I think we can both agree that's not a real issue.)

Is this not how it works for pretty much more – if not all – projects? Good luck trying to land a patch in Python if the small group of core developers don't agree. Or PHP. Or Ruby. Or Firefox. Or Linux. Or anything else really.

Quite a few of the core Go devs aren't hired by Google out of the general programming pool, they were already contributing to Go and then Google asked "hey, cool stuff; why not come work on Go for us?" Again, this is pretty much how you join any core group of developers: make good contributions, get asked. Except here you actually get paid.

>Good luck trying to land a patch in Python if the small group of core developers don't agree.

Well, Python has this: https://www.python.org/dev/peps/pep-8016/#electing-the-counc... and you can also get to be a core team member (and many have). What about Go?

as mentioned in another comment, a number of people have been hired by Google "from the community" (including e.g. spf13/Steve Francia, the Go product manager). I don't have access to their HR accounts, so I can't tell you how many exactly. But if you do good work, there's a non-zero chance you'll get hired.

I think voting and whatnot are implementation details. That PEP says only core team members can vote who can join the core team, so core team choosing vs. core team voting is not all that different in practice.

Hired employee implies control, it's not like becoming a part of a group of equals.

So everyone is "equal" in Python?

Even if they're not equals, they're not employees of the owner of the project, which is the point.

So there's an higher chance they could leave without notice for lack of funding or because their full time job leave them not enough time

Yes, and hence a higher chance that they are not a hardened paid-for core team, but a looser team where people can come and go, and where an outsider can get influence.

This always reminds me of this

https://www.youtube.com/watch?v=Pw9gaEiQAxY

people should be paid to work to a product under some direction, if you want some professional outcome

teams where people come and go rarely have built solid products

Take for example the Linux kernel, Alan Cox has been working on it non-stop from 1991 to 2009, and even after resigning as TTY maintainer, he was still heavily involved up to 2014

From 1999 to 2009 he was employed by RedHat and after That by Intel until 2013

I can't honestly say he did RedHat or Intel interests more than he did Linux community as a whole interests

He's a big advocate and activist for free software, but he also said "Yearn for the good old days when you knew every contributor by name and the source code fitted on a single floppy disc ?"

In a way or another, a small group of "directors" is always better for the good of both the product and the users

Google doesn't "own" the project in any meaningful sense. That was Russ' entire point of this post. Could Google assert control if they wanted to? I guess. But that's no unique to just Go. Remember the XFree86 drama, for example? Probably a number of other examples to be found.

The issue here seems to be primarily one of trust. I can relate to that, as I don't like Google either, and actually mostly avoided Go for exactly that reason until I got hired as a Go developer a few years ago. I found that the Go project in particular is developed and managed in a fairly reasonable way; certainly much better than some other popular Google projects such as Android (the open parts of it anyway) or Chromium.

In other words, I think you should give them a chance, rather than immediately go "corporate Google overlords".

What is omokase?

A horrible Rails-speak affectation. But it is well documented!

https://dhh.dk/2012/rails-is-omakase.html

it's a great idea if you ask me

Just to add to the explanation, "omakase" is Japanese for "I'll leave it to you". It's relatively common in sushi restaurants to have 2 ways to order - a la carte (or in japanese "tampin") where you choose exactly what you want, or "omakase" where you essentially say, "Give me what you recommend". One of the reasons for this is that there are definite seasons for fish. You can often get certain fish at most times of the year, but in winter it will have more fat, etc, etc. Similarly, the chef knows the quality of the fish that has been bought for the day and knows what's best. If you want the best, then usually you go for omakase, because you, as the customer, don't have a good way of judging the quality of the fish for the day. In some restaurants you even just say how much money you want to spend and the chef will try to fill you up with the best possible fish for the price.

The parallel, of course is that you can choose a language or framework that provides you with a lot of choice, but where you need to have have a corresponding amount of expertise in order to make good choices. Or you can choose a language or framework that is designed to more or less work out of the box without you needing to understand all of the details.

Where I think it breaks down is that in a sushi restaurant, ordering "omakase" every time you go will result in a completely different experience each time -- all tuned to give the absolutely best possible experience from an objective perspective. "Omakase" in a framework gives you a homogenised experience which will bring you up to a particular baseline, but which is almost certainly not tuned for your situation.

I don't think it really 'breaks down', it's just a mildly wanky analogy and he explains what the design philosophy of Rails is without relying on the reader's familiarity with sushi ordering. I'm also generally sympathetic to Rail's desire to avoid crufty enterprise-y terminology. Their unchecked enthusiasm for it, though, makes reading anything Rails-related feel like dumbly leafing through a picture-less IKEA catalogue of an MLM company for personal growth and wellness products. But that's just me - being told to be happy by a web framework gets me like, right here, in the resentful Slavic soul.