(Myself, I am usually just trying to build stuff people wrote in Go, and I usually end up fighting the tooling for a while and getting mystified by the error messages and having no idea where to look to solve them.)

It was an important lesson in a way, as it taught me that Google – or indeed, any organisation comprised of thousands of people – is not a single monolithic entity.

Also, feel free to drop me a line if you've got problems with a specific error, and I can perhaps point you in the right direction.

It was just that the error message I got really gave me nothing useful to search for. Literally was a "permission denied" error... while "go build"ing stuff with effective superuser. It wasn't really pointing me at what it didn't have permission to do or how I would go about getting it.

I think Debian ships with Go 1.11 in current stable (and by extension, Ubuntu too, I assume?). The entire GOPATH to modules switch is messy, ugly, broke a lot of stuff, and is confusing for newcomers, even though modules is clearly better. I think we're finally nearing the end of it though.

You probably want to just use Go 1.14 (the latest version) if you can. The language itself is very stable (just not the surrounding tooling).

And yeah, I believe Go 1.15 should be released in August. rc1 was released last week or so.

If all you have been building for the past 20 years are web services and you are surrounded by Kubernetes-but-the-internal-version and Postgres-but-the-internet-scale-version, is it any surprise that what comes out at the other end is invariably a centralized web service running on a bunch of Google proprietary infrastructure? And is it really that difficult to see how that is very different from the principles in Go, the language?

Git is very much the same thing. There is no doubt that in a world without Git, version control inside Google looks a lot more like Team Server than it does decentralized Merkle tree.

If employees hired as engineers, who work on engineering projects, don’t count as part of your company’s “engineering ethos” just because they were already engineers before you hired them, I’m not sure we have a shared agreement on what “engineering ethos” means. Are only fresh college graduates permitted to count as part of your “ethos”? How many years of experience can an engineer attain before their accomplishments at work are no longer part of their employer’s ethos?

Read carefully: the engineering culture of Google - it's practices, policies, principles, insiprations, and so on - did not make Go. The prior experiences of the Go authors, and a handful of specific and obvious influences, both of which are objectively not of Google, made Go. Google's engineering ethos does not get credit for Go, though maybe an argument can be made that their wallet gets credit. Personally, I don't agree with that, but it's beside the point.

Google hired the engineers who made Go. A company’s engineering ethos is the combined ethos of its engineers. The Golang developers are engineers who Google hired.

To attempt to draw a metaphor: if I operated an auto repair shop, and I wanted my shop’s “ethos” to be “we do high-quality repairs on cars”, one of the primary ways to do that would be to hire smart, already-experienced mechanics. And it would seem strange to me if people wrote blog posts saying that the work of those mechanics didn’t count towards my “ethos” because they were already good at their jobs; that’s why I hired them!

As a tangential comment, phrases like “Read carefully” seem extraneous, as does the accusation of “an awful lot of willful ignorance”. They just serve as jabs at the other commenters here.

So: Google gave a chair and a desk to a few talented people who applied experience and influences from entirely outside of Google to designing a programming language. In my book, Google doesn't get credit for that, and their engineering culture definitely doesn't get credit for that - it was barely involved, if at all.

Edit: They're not actually fellows it's been pointed out but high ranking ICs like that do have a lot of respect within Google and are treated deferentially, especially famous ones just based on my own experience with high ranking ICs.

This isn't true (and I don't believe it's ever been true).

> I saw this at least with other Google Fellows

This also isn't true in general, there are no Google Fellows that report directly to Sundar. Not to mention that neither Ken nor Rob is a Fellow.

> and don't go through perf in any real sense

Why do you believe this to be true? Many people of similar stature (VPs are approximately equivalent to Google Fellows, and there are tons of VPs) have a real perf process, although it doesn't quite resemble the one you or I would have.

If you mean that he has no incentive to "play perf games", then that's true only insofar as they don't want to advance, which is true for the average Google engineer starting at L4 or L5.

> At Google seniority is revered.

This hasn't been my experience at all, I've had quite reasonable experiences pushing back against my directors and questioning my VPs.

Do you have an actual example of ways in which their treatment by Google differs from other engineers? These seem like conjecture about what their work experience is like.

Regarding being a Fellow: finding out that people respect senior engineers and take into consideration their past experience isn’t shocking, or an example of the rules not applying to them. Similarly, if you told me that a head chef at a restaurant has more impact on the menu than a line cook, it wouldn’t be an indication that the rules don’t apply to head chefs, or that nobody cares about their performance. And nobody would make claims that restaurant’s menu didn’t reflect their “ethos” because it was designed by an experienced head chef.

I actually do think that Go in its adoption by Google is a reflection of Google engineering values. I still don't think that someone who comes in to Google at the level that the Go creators came in would have the same experience as someone who came in entry level cut their teeth moving up through Google but that's just my perspective. A lot of people I met had only been at 1 or 2 other companies before Google (my TL had actually been at Google his whole professional life) and a lot of their opinions about engineering were shaped by how Google did things.

Separately, the idea that a manager having influence on a good engineer’s work is “broken” is one I don’t understand.

But I think, based on this comment thread, it’s unlikely we’re going to reach a consensus.

FWIW, that doesn't seem strange to me. Hiring smart, already-experienced mechanics is a input to your ethos; presumably you hope that they will make the shop's culture better-suited to doing high-quality repairs. A example of a output of that culture would be if you also hired young, inexperienced mechanics, and they learned (presumably from their aforementioned seniors) to do high-quality repairs and went on to be the next generation's smart, already-experienced mechanics.

This kind of writing is not allowed on HN. Make your argument on its merits, not with innuendo.