Hacker News Reader

> the tedium of dealing with the unwashed masses -- typical NIH syndrome

If you've managed a large OSS project with a wide userbase before, you know how annoying it can be to deal with large numbers of repetitive requests from folks who don't have the full context of what's going on in the project. It's time consuming at best, and at worse some small minority of those folks take up a toxic attitude that sucks the happiness out of your work. There's no need to accuse maintainers of arrogance or NIH syndrome. This stuff is hard, and we all try to do the best we can.

> ...repetitive requests from folks who don't have the full context of what's going on in the project

Write some FAQ's, so that people are made aware of that context. An openly-developed project can actually be very successful at dealing with this, because pointing folks to the centralized discussion in which the pros and cons of commonly-requested feature X are dealt with becomes second nature after a while. We saw an example of this very recently with the surprisingly-mild brouhaha about Rust's choice of a postfix .await syntax.

There's an FAQ: https://golang.org/doc/faq

For generics specifically, there's a "Summary of Go Generics Discussions", which is quite comprehensive: https://docs.google.com/document/d/1vrAy9gMpMoS3uaVphB32uVXX...

From my experience as oss developer on several different projects (small to medium ones),a lot of people don't bother to read FAQ's.

There are some people that hit the problem, start googling, and trying to find information, and some that just fire off email or stack overflow question (often so badly, you need several back and forth)

"I think I've mentioned this a while back, but one only needs to look to the Guava library team to see what Google's general position is on community contribution:"

Can you explain why it makes sense to generalize a company of 50k developers, which has released 4000+ open source projects, on the basis of precisely 1 of them?

Why doesn't it make sense that it will end up with a variety of projects with a variety of models? Especially given that is true of the world writ large?

I simply do not understand this fixation with trying to rigidly pigeonhole Google on open source.

The idea is to embarrass Google as an organization into changing their culture or at least the optics surrounding that culture.

I think the point rmrfrmrf is making is that Guava is a typical example of Google's attitudes towards the two-way relationship of open source. Google developers (and many other big software companies) are more than happy to open their code and promote it as something that the community should adopt, but seem rigidly dismissive of any code contributions to the project from outside. That may not be the case for every Google project but it does feel like it's a common one to me.

What Google projects would make good counterpoints by demonstrate a welcoming attitude to external contributions?

Kubernetes, probably.

https://github.com/kubernetes/community/tree/master/contribu...

Kubernetes is a CNCF project. That's different than a project that Google runs.

Kubernetes is a reaction to that state of closeness, and was explicitely designed to bring Google’s philosophy (Borg) to the world. Its strong focus on getting outside people involved is the core reason of its existence, so it’s a bit of a special case IMO.

An issue is copyright ownership. Even if a contributor assigns copyright, it is ineffective if they didn't hold copyright. This opens the project to legal peril.

That sounds reasonable except Google could write some boilerplate for maintainers to include in a project's README.md, contributing.md or license file that explicitly states they won't accept community contributions because copyright would be an issue, and they don't appear to have done anything like that.

Yeah, it's just "an" issue, perhaps contributing to their attitude.

Except it's not typical, it's just the one OP picked to support his biased position.

Please stop trying to attribute singular motivations behind a company with thousands of projects and many thousands more developers, it's so silly.

It's certainly not atypical.

AOSP for another example.

As is Kotlin and Android tooling. We currently have: Gradle, Soong, Android Build System, Bazel and Dart.

Of those, only Gradle is external but the Android plugin is in house and it shows.

Kotlin its ran by an essentially two party Kotlin Foundation of Google and JetBrains.

Angular for example. They even hire non Google contributors to work more closely with them and have contributors programs to include the community

> Go core would go on ignoring community progress

Any examples? Perhaps you mean either Generics or the module system (the two elephants in the rather large and accommodating room)? I read almost all proposals for Generics, and, perhaps to my inexperienced eyes, the problem seems hard. The ramifications on the language design are not trivial, and the benefits, again, from my quite limited world view, are not so easy to quantify, otherwise how can one justify the extreme productivity spawned by the language? In the cloud business no less.

I have almost no stake in this, I don't even use the language professionally, but I find the supposed criticism a bit over the top. I'd wager that an example implementation of Generics that fits nicely with the language and works for a big and healthy code base would absolutely not go unnoticed by Russ and the other core members, but we have to accept that it is not easy.

Yet other language communities managed to do it since the mid-70's.

I put it to you that most other language communities do not deliberate as much on generics.

Consider the document that Ian Lance Taylor put out: https://github.com/golang/proposal/blob/master/design/15292/...

More research here: https://docs.google.com/document/d/1vrAy9gMpMoS3uaVphB32uVXX...

I have also given it a bit of thinking on the tradeoffs: https://blog.chewxy.com/2017/09/11/tensor-refactor/#some-tho...

The Go community may be stuck on an analysis paralysis mode, but it's much better than ad hoc implementation that will stay forever.

There's a proverb in these here parts that goes like "He who doesn't want to kneed dough, keeps sifting flour".

Perhaps a modern dev-friendly version would be, "He who doesn't want to code, keeps configuring their text editor".

That seems to be the case with Generics and the endless "documents" and "analysis" in Go. If you don't particularly want to do something, you keep analyzing different ways of doing it...

Most of these "analyses" especially from Ian has backing code changes.

This for example, is my experiment with trying to give Go a backing calculus that supports generics https://asciinema.org/a/166748

The runtime changes yielded over 20k lines of changes - basically about 1/4th of the Go runtime has to change. Not to mention a large amount of semantics changed too - essentially a different language

>The runtime changes yielded over 20k lines of changes - basically about 1/4th of the Go runtime has to change. Not to mention a large amount of semantics changed too

Well, isn't it a major typesystem change? Makes sense for it to apply to a big part of the runtime and semantics.

There’s another proverb that I think applies better: “measure twice, cut once”.

Having buggered up a half-lap joint the other month even though I measured things several times, I'd like to propose a change to this proverb.

"measure twice, think twice, cut once"

(or even "think twice, cut once" if you want to generalise it to other spheres)

In the Russian version of this proverb you'd need to measure seven times)

You mean the usual documents that get thrown into generics discussions, where he keeps talking about C++ and Java, while ignoring all other programming languages designed since CLU and ML in the 70's?

"In retrospect, we were biased too much by experience with C++ without concepts and Java generics. We would have been well-served to spend more time with CLU and C++ concepts earlier."

https://go.googlesource.com/proposal/+/master/design/go2draf...

This has been acknowledged and addressed. What is your proposal?

I don't know, that they actually implement them, instead of doing proposal after proposal?!?

Even the ideas that eventually die on the Web, C++, Java and .NET happen to have preview implementations available to try out at one point, instead of dead paper.

I don't think it is efficient to implement a dozen of ways to handle generics.

People who need generics will use code generation until the issue is addressed, I don't really see the need to rush.

Attention to details is something I like about go.

Just like C++ MS-DOS compilers used to do before ANSI/ISO started to work on templates, about 30 years ago, talk about progress.

C++ has concepts now. What's the excuse?

There are plenty of people, myself included, who would prefer no generics than bad generics.

The big reason for me to use GO is it's simplicity. I can pick any programmer, give him a few days to a week, and he will be productive.

Python used to be somewhat simple (never really that simple) with goal of having 1 "obvious" way of doing anything.

I think GO is better at that, than python ever was, and I think that is one of the bigger reasons for it's success.

Bad generics is what happens to any programming language not designed with them from the start, specially when one ignores 30 years of experience.

Except that they admitted that they didn't really look beyond C++ and Java implementations. Their aversions to modern language design and type theory are pretty obvious.

Also, lots of code can be written in a bad language. And a language can be practical without being good from a language design perspective, the difference is in the richness of the ecosystem, the stdlib, and 'meeting programmers where they are'.

> lots of code can be written in a bad language

That's actually the problem. Bad languages require reading and writing too much repetitive code, just to replace missing abstractions.

> I think I've mentioned this a while back, but one only needs to look to the Guava library team to see what Google's general position is on community contribution: contributors need not apply.

This claim is belied by the fact that half of the people who have committers in Go are non-Googlers, isn't it?

It's probably less than half due to people using person email addresses instead of @google.com. The author didn't verify that people who had non-google addresses didn't actually work for Google.

One thing I'd be curious to know is how many of the committers didn't ever work for Google. I suspect some of the non-Googlers on the committer list maybe former Googlers...

In the context of this discussions why would it matter if someone never worked at Google vs someone who used to work at Google. They're not acting on behalf of Google when they make the contribution.

I don’t think it would necessarily matter.

But it might be an indication of how “open” Google is to complete outsiders as opposed to people who were insiders but now just happen to not work for Google. Whether or not that matters is another question entirely.

But like I said, I don’t think it matters in the context of how much control Google has over the language. Many successful languages are either driven by an individual benevolent dictator or a company. As far as I can tell, languages controlled by community/committees tend to evolve more slowly. That’s okay at some point in a project. But there is something to be said for a person/company having the ability to rapidly push through changes.

You need to sign a CLA to work on Go, like most Google projects. You can't accidentally use your personal email address, and setting up the CLA signing stuff is somewhat involved.

But you can (and are encouraged to?) sign up using your personal email while still employed at Google.

The opposite is true. You are explicitly asked to make all contributions while at Google (to all projects) under your @google email.

Ok that's curious, cus I've spent the last two years working on a project at Google that's half open source, and the guidance we got was to use an existing non-google github account for contributions if you had one and wanted to.

But this is also like a developed-in-open-source project, not a built-internally-and-copied-outside, so maybe the guidance differs there?

Or is that a go team specific thing?

> and the guidance we got was to use an existing non-google github account for contributions if you had one and wanted to.

This is correct. Use an existing github account, but your contributions should be under your @google email address. There's nothing that ties your github account to a git email. I've committed through github from like 4 different email addresses (@google, @gmail, @uni.edu, and a shared organizational one for a project from a shared machine).

Ah gotcha, yes we're agreed then. The underlying commits are supposed to be tied to your @google account (though a not insignificant number slip through)

The maintainers there blogged at-length about the inferiority of non-Googlers and the tedium of dealing with the unwashed masses -- typical NIH syndrome -- this is the same philosophy that the Go team is influenced by, perhaps with only a less hostile tone.

NIH syndrome was widely cited as one of the major flaws of the Smalltalk community back in the day. In any human endeavor, one has to fight the tendency of a group turning something which isn't a club, into a club.

That said, golang isn't a field. It isn't a genre. It's a computer language, a collection of libraries, and a number of online communities. In large part, it's a collection of tools with support around it, people interested in using it, and a company behind it. There are lots of things like this. Leica cameras. Rigol oscilloscopes. Chevy LS3 crate engines. Harley Davidson Motorcycles. These things live and die by continuing to garner the goodwill of the market and staying honest with themselves.

On the flip side, many of those things also live or die through good design, and good design also needs gatekeepers and visionaries. It's a balancing act. Golang in particular needs to watch its step. Since it has a syntax on the minimalist side with few surprises and easy access to its AST, it's going to be one of the easier languages to port off of.

Any OSS project can be relatively closed to outside contributors based on how opinionated the core owners of the repo are, it isn't just corporate open source.

You think the Guava team has a low opinion of patches? Does that mean Linux isn't a community project because Linus wields an iron fist when it comes to accepting patches?

Yet Linux is full if half-assed undocumented cruft despite Linus' vigilance. It's just gigantic. He doesn't care much about how great your new LSM, IO scheduler, FS is, if it's relatively sane, and you don't do crazy things elsewhere in the code, he'll pull it. (Nowadays it's not directly him.)

How much of it is device drivers for arcane devices though?

Right. For better or for worse, Go is not a community-driven project. It is a project driven by a (largely independent) team within Google.

Open source =/= community driven.

A counter-example I've seen is Bazel; the Bazel core team seems very receptive to outside contributions and feedback from my experience (I've contributed PRs to Bazel).

(I don't use Go, so I don't have much insight into the overarching discussion. Just wanted to add my 2c).

The set of people that make decisions about Guava is mutually exclusive from the set of people that make decisions about Go, and the two projects have markedly different goals.

It's also worth noting that Guava lives in a very different world from Go - the way we distribute Guava is (unfortunately) not designed for non-Google contributors and Guava needs to support multiple Java ecosystems/platforms (Android and servers, at least).

(Googler that works on neither Guava nor Golang.)

Can you point us where Guava library team made such claims?

I believe the author is referring to this post, https://web.archive.org/web/20181209143223/https://plus.goog...

Guava was always made available as Google's Java core utilities. I think it was always a misunderstanding to expect external contributions, like Apache Commons, as that was not its original intent. Rather it was to reduce internal duplication and ad hoc code with a shared standard. It then became useful for open-sourced Google projects (like API clients) and recruiting (new hires would be familiar with Google's libraries). Many suggestions are best spun off into new libraries, rather than donated to Google to maintain.

Java's many flaws have been papered over by a large ecosystem of libraries. As a non-gopher, I'm not sure if that same spirit exists. Perhaps that is due to the dependency debates, whereas Maven Central was quickly adopted when managing jars (via Ant) became too burdensome. Perhaps modules will help, as the language doesn't have to be batteries included.