Putting aside the criticisms, I think a new word is needed to describe anti-Google sentiment of this flavor. The idea that Google is incapable of doing anything positive, so anything “good” coming out of Google must be attributable to influences outside of Google.
I’d like to think about it as a “no true Googler” argument. The Go team are not true Googlers, because they produce something useful. When they built that module proxy however, they were clearly so doing as Googlers. (As someone who works at Google, I can humorously imagine that when I’m acting as a true Googler, my only goal is to foist new crapware onto the world, get promoted, and kill it off.)
Or maybe we recognize that companies are collections of individuals, and all individuals bring their own history and influences. The culture shapes them and they shape it back. Playing semantic games to divide and attribute isn’t useful.
That would apply equally to quite literally any collective/group/company/society.
How does such poor reasoning end up voted so highly on HN?
The people doing things you like are just as much Googlers as all the people doing things you don’t like, and they all have an influence on the company and vice versa. In many cases, it’s even the same people.
So the distinctions you are trying to draw are silly. Just let the criticisms stand on their own.
(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.
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.
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.
This kind of writing is not allowed on HN. Make your argument on its merits, not with innuendo.
>> pkg.go.dev fetches the list of modules from proxy.golang.org: a closed-source proxy through which all of your go module fetches are being routed and tracked
>> pkg.go.dev hard-codes a list of centralized git hosting services [that are the only allowed ones]
So how in the world did git.lukeshu.com get to be on that list?
Also: hi Luke! And thank you!
Actually, pkg.go.dev needs to have some way of figuring out where to link to, so it's not necessarily easy to automatically make links that work for 100% of the sites. That's not "a blatant failure to comprehend the fundamentally decentralized nature of git hosting", that's having to deal with a large ecosystem spread out over thousands of domains. Go's model is a lot more decentralized than most other package systems (which also makes stuff like this harder).
Except being the key word here. My commentary is on the quality of their engineering approach and I have demonstrated that their approach is flawed. Their approach is wrong.
What is the goal of your post? To inform your readership, or to convince them that Google is bad? If it's the former, then you have done your readership a great disservice. If it's the latter – which seems to be the case – then congratulations: you've fooled your readship – or at least part of it – in to believing something that's not true.
And you've been misleading yourself: it's not a "single feature" - several features depend on this code. It is a second-class experience, and in ways that build upon other problems I've put into the article.
Cut the bullshit, dude.
Ehm, there is a massive difference between something not working at all and one feature not working. My car's headlights not working is not the same as my car not working. My laptop's trackpad not working is not the same as my laptop not working.
> And you've been misleading yourself: it's not a "single feature" - several features depend on this code.
I use pkg.go.dev almost daily (including for sr.ht repos on two occasions) and have never noticed this. It's fine to point out that there's a degraded feature-set and be angry about that (some people probably care about these features more than I do), but claiming that the entire thing isn't working is – and I feel like a broken record with this – just not true. It's just not. No matter what you say.
This is easily fixed by just changing a few words. I don't get how anyone can defend this. If someone would point out such a thing on my own website I would drop everything and promptly fix it, no matter how strongly I believed in the main point I was making (and I have actually done so) as I want to be as accurate as I can reasonably be.
You know, you actually inspired me to work on open source full-time last year? True story, that's what I do most days now, for almost a year to the day. This is what I wrote a year ago:
> Drew DeVault’s sourcehut in particular was inspirational in actually making the step. If Drew can do it, then why not me? [..] I know it’s a risk and that there’s a decent chance this will fail. That’s okay. I’d rather take a chance to try to achieve a goal and fail instead of always playing it on safe. Not doing anything is also a decision – which you can regret just as much as any other – and the worst thing that can happen is that I lose some money and end up taking a job again. Doesn’t strike me as so bad, in the grand scheme of things.
But with this like this – and this is not the first time I've seen you do it – you've lost a tremendous amount of respect. I don't care that you write rants (okay, it's not my preferred style, but whatever) but when you're being misleading and then defend that on account of "but my point was correct" then ... yeah nah... It's hard to be inspired by someone like that.
I don't expect that you'll care a great deal, but just so you know regardless. Do with it what you will.
There’s a big difference between requiring explicit site inclusion for full functionality and requiring inclusion for any functionality, and your post claims the latter.
One problem is that the import path doesn't really give you enough information to totally figure out how to fetch the package. It's treated like a URL, and then the go-source tag comes in to relate it to something VCS-controlled. If we encoded the VCS into the import, we could e.g. have "git+https://git.sr.ht/~sircmpwn/getopt" as the import path, or we could move the import details into a separate file (like go.mod).
But if we assume that the import path and go.mod formats are fixed, then we still have more things we could do. For example, why this:
<meta name="go-import" content="git.sr.ht/~sircmpwn/getopt git https://git.sr.ht/~sircmpwn/getopt" />
<link rel="alternate" type="application/x-git-http" "https://git.sr.ht/~sircmpwn/getopt" />
<link rel="alternate" type="application/x-git-ssh" "firstname.lastname@example.org:~sircmpwn/getopt" />
<meta name="go-source" content="git.sr.ht/~sircmpwn/getopt https://git.sr.ht/~sircmpwn/getopt
And furthermore, with the specific case of hardcoded software hosts on pkg.go.dev, why isn't it using the go-source meta tags to look up how to create links to files & line numbers? You guys forced this upon us and then don't even use it? There's no reason to hard-code regexes for various git domains when you could just fetch it like godoc.org does.
In the first case the go-import meta tag is totally unnecessary. The go tool and module proxy can discover git repos from an import path just fine. It’s only required for “custom” import paths where the path is some domain but the code lives somewhere else, like github.
In the latter case the decision to use go-source was actually made by the original author of godoc.org, not a google employee, and was done in coordination with another non-google initiative (gopkg.in) to make their source links work. So nothing to do with the go team really, sorry.
If pkg.go.dev isn’t respecting go-source meta tags then that should probably be fixed. It would also imo be worth considering devising a more general, well-known mechanism for doing this. Worth proposing I think!
The relevant docs are here:
You can explicitly put ".git" into your import path, but no one does this and it's not explained to new users. In order to have predictable import paths like people have been trained to use, you need go-import tags.
>In the latter case the decision to use go-source was actually made by the original author of godoc.org, not a google employee, and was done in coordination with another non-google initiative (gopkg.in) to make their source links work. So nothing to do with the go team really, sorry.
And yet, godoc.org is what you're replacing. Not taking into consideration is how you end up with what you've got: regression. And this only further betrays Google's warped worldview of "us and only us": this person has made an amazing contribution to Go and yet you consider them an other and don't take their design into account.
>If pkg.go.dev isn’t respecting go-source meta tags then that should probably be fixed. It would also imo be worth considering devising a more general, well-known mechanism for doing this. Worth proposing I think!
No, it's not worth proposing: it's worth doing, and should have been done in the first place. It should not take an outsider - it should happen naturally from a good engineering ethos. Playing well with others is your burden, not everyone else's.
I don’t even know where to begin with addressing this criticism. To say that you have a warped view of the situation is putting it mildly. I’m just going to back out of this conversation while the going is good.
Less snarky: it's quite disrespectful simply dismiss an entire group of people as a "cult". You seem to spend significant effort engaging based on the affiliation of the person, rather than what they actually have to say.
So that's not against pkg.dev. Did somebody look into why?
Anyway it seems that the repo was not added to pkg.dev automatically:
and the automatic fetching should work now:
The way this works (or rather, worked) is that you first need to "go get" a module and then it gets picked up by the pkg.go.dev system. This works like that for every site, and was kind weird and confusing, although as you mentioned this was improved on recently. Either way: not related to that module being on sr.ht; that's just coincidental.
It doesn't work on godoc.org not because they don't recognize your domain, but because cgit doesn't have go-source meta tags.
That is why they decided to turn it into an internal/source package inside pkgsite first to have test cases for a later go-source-2. If your site does not show source links on pkg.go.dev then add a comment to issue 40477 above and an exception will be added.
- internal/source: https://github.com/golang/pkgsite/blob/master/internal/sourc...
Note1: Maybe mention this on your website because that took a little to find. It does not fit into the narrative though.
Note2: Requiring frontends to offer meta tags is the only way to make code discoverable with the url alone. cgit not offering this is on cgit and not on Go/pkgsite (haven't checked whether they do)
Whereas AFAIK godoc.org only supported git. IMHO support for a variety of SCMs makes pkg.go.dev a huge improvement.
Support for "go get" and pkg.go.dev via fossil-scm does require some golang-specific meta tags, as TFA exclaims. But why is that a big deal, it's a golang repository after all?
Take what I'm saying with a grain of salt; slightly biased since I worked there for a bit in the past.
Fundamentally there is a hostility towards the philosophical aspect of software engineering which involves a careful consideration of the essential nature of the system as a whole as it relates to some ultimate end and the nature of logical components of the system and how they interact. Note that these considerations can occur prior to any code being written and also as part of an iterative process as the product and understanding of the product develops.
I believe this stems from three sources:
1. The criteria and process for getting promoted is very focused on shipping new and complex things which in practice is at the exclusion of all other considerations. This means that improving or maintaining existing systems or producing systems which are well architected at all is not as clearly valued. The promo committee is comprised of people who don't know the specifics of the systems you're working on so the easiest thing to convey is that feature X or product Y was shipped.
2. There is a hyper-rationalist, hyper-modernist, data-driven, anti-intuitionist view which pervades Google which completely discounts any sort of philosophical/qualitative thinking. People get really uncomfortable when you try to start even the most anodyne discussion about the product or service as it relates to some broader goal since those involve qualitative judgements that can't be reduced down a set of metrics. Some of this may be attributed to the CYA culture among management.
3. The interview process doesn't select for software engineering or software architecture skills (aka people who have developed an intuitive understanding of the art of software engineering) so there are many people within Google who lack the ability to effectively evaluate the architecture choices that are being made around them or that they themselves are making.
With all that said I did meet and work with many brilliant engineers and others who were very talented and did think deeply about things but those were relatively rare. And yes it is a big company with many different teams and subcultures but what the author and I have described are the patterns that one sees broadly across Google.
I’ve been at Google for six years, and I’ve never encountered a “hostility towards the philosophical aspect of software engineering”. What a bunch of hooey.
There are certainly problems with the promotion system (and incentives it creates), but it’s laughable to say that it rewards shipping “at the exclusion of all other considerations”. In two years, I imagine that you didn’t yet serve on promo committees (or see many successful and failed promotions of colleagues), so I’m not sure your criticisms are coming from a deep understanding of how they work.
I’m sorry that you had a bad experience, or that you felt your specific working group had some kind of CYA culture or anti-engineering vibe. But it upsets me to see people indirectly shitting on or commenting about tens of thousands of engineers that they had never worked with or even interacted with. I don’t know why it’s fashionable to do this with Google right now, but it just shouldn’t happen with any company.
If you want to describe your specific, concrete experience, I’m sure that would be much more helpful and constructive than saying “the culture is X”, “Google engineers are Y” without any connection to specifics. My 2c.
When I was there they added "Landing a product" as perf criteria as opposed to "Launching a product" and they added some lip service towards maintenance tasks being perfable which is a reflection of the problems I laid out.
I don't know you or your situation and there are always exceptions (e.g. Bram Moolenaar, of course, and others not as famous) but in my experience the more tenure an engineer had the worse they were. The best engineers I've met in my career were ex-Googlers who were only there for a few years (some of them became Xooglers while I was there).
My assertion is that generally speaking the people who stay are the ones who don't see the problems in the system because they don't have the talent, experience, or perspective OR they have other priorities in their life (raising a family) and Google makes it easier for them.
What I encountered was that many long time engineers just weren't aware of what else was out there, the advances in the state of the art, and how things could be better because they were cozily ensconced within the Google ecosystem for so long. It's an incredibly ossified environment.
I’ll point out the irony of having this discussion on this post. Many of the Go team engineers have a long tenure, but the author wanted to attribute “good” things only to “not Google” influences.
Yes, the promo system has issues. Yes, there are widely held beliefs about it. But not all widely held beliefs are accurate: there’s usually some truth, but as always, it’s complicated.
Yes, there are some echo chamber issues. But engineers are much more aware of the outside world that you’re implying.
I just think your assertions are pointlessly mean by virtue of being overly broad (in terms of who and what). I like to see specific criticisms of any company, even if backed by an anecdote, because you can learn something.
What’s anyone’s takeaway supposed to be here?
However, conditioned on Go existing and someone using it, the category of problems he's describing with the tooling are familiar.
To your point about engineers being more aware of the outside world, in my experience this only held for new engineers and the ones that try to bring in new practices tend to get shut down or pushed out. See: https://twitter.com/ThomasBurleson/status/128390216922628096...
Seeing this was so ironic because of all the engineers at Google, Rob actually came and gave a talk to our team about NgRx and he was one of the few engineers I encountered that really got engineering. Having him come give a talk to our team was like a breath of fresh air. I have no doubt there was some insane political BS he was subjected to and forced to leave.
As far as my assertions being "mean" because they are overly broad, the nature of speaking about anything requires some degree of generalization which I've tried to couch (and you're aware that I have). What a silly argument.
Another concrete example I can give you is that the people who run the Angular team also own support for Typescript at Google and they disabled .tsx support for Typescript (literally just a compiler flag that does simple desugaring) despite a ton of protest from a lot of teams using it. They did that to kill off and discourage React (which many people want to use) to consolidate political power. I had many private messages with new engineers that were upset when they got shut down for asking if they could use React. Obviously these people were trying to bring in practices from outside of Google.
The takeaway is whatever people want it to be.
googthrowaway's experience more closely matches my experience at Google, fwiw, but it's certainly the case that your experience depends on which org you're in. My org had a notoriously incompetent VP running things and it hemorrhaged staff to companies like Apple and Microsoft.
And I don’t know why you’re assuming I’m an IC; I didn’t say that either.
I don’t have any problems with people sharing their specific personal experience. I have a problem when people start claiming good engineers are “rare” — you’re just insinuating bad things about tens of thousands of people you have never even met.
Sure. I'll grant you Junio; he seems like a cool guy.
The rest of google though? Google's engineering culture is by and for google. They're not doing the rest of us any favors.
Googlers need to admit that. Not to me, but to themselves.
... a meaningless decision to have a transparent proxy in some network path some free code takes on its way to you?
If it's so meaningless, now that Drew has complained they can just make the alterative the default for their software right? Right? It is MEANINGLESS afterall.
When faced with a decision, someone chose the option that took extra operational expenses to keep services online. If you're going to call that a meaningless, then you've either a huckster or have got quite a lot to learn my friend.
Quite a few points in this article are highly misleading.
The only way for a non-hardcoded host to work would be for the import path to contain ".git", ".hg", etc -- which is so ugly pretty much nobody does that.
The entire thing is a bit hacky, but as mentioned in other comments godoc.org started as an independent project outside of Google and pkg.go.dev built on what was already in place. Was that the right decision? I don't know, I haven't looked at the matter and possible problems in-depth; all I do know it's far more nuanced than "Google being bad at engineering".
I forecast a lot of HN upvotes :)
Personally I don't find the fact, that a corporation built something out of their own interest surprising at all.
It's not surprising, but it is concerning given that Google is the steward of the joint interests of all Go users.
I'm aware of TinyGo, but not any other forks
That being said, some pieces of the Go standard library have been copied across where it makes sense to (and works).
There end up being some problems with this model. Popular modules might be hosted on some server that can't stand the load, and if you can't pull dependencies, the entire module system breaks down. So, you probably actually want the modules on a CDN, because high availability is important for CI systems. Before Go automatically pulled from Google's module proxy, I had my own. I had to, because Github rate-limited our pulls (and when it wasn't rate-limiting us, it was slow).
Setting that up was a few hours I had to spend for no good reason -- it didn't make my product better, except by making some incidental step between idea and deployment slightly faster. You can of course vendor your modules (now your git clone is slow), or add caching to your builds (go's caching is very good, but doesn't play well with Docker). All of them take your time and mental energy to do something unimportant. So, Google made a module proxy that Go pulls from by default. It works every time. It probably costs them almost nothing. There is no business value in it. Google doesn't need Go for anything. They just have some employees that want to improve the lives of average programmers. You can turn it off. You can host your own -- go/x has an example proxy, and there are full-fledged open source projects that add more features (Athens). It's actually a very good situation. You can be as centralized or as decentralized as you desire.
Going back to centralized package databases, they do have some really useful features. The main one I use is looking at users of a package that I'm reading documentation for. No example code in the repository? No problem. You can go see how other people are using it. The problem there is getting a list of all possible packages. You can poll common repository hosts for them. You can convince everyone to use a certain proxy that gets the names of the modules you are using so you can go index them. That's what Google does, and the user experience is great. You trade Google the information "the IP address 188.8.131.52 uses github.com/foo/bar" to get the knowledge of every Go module in the world. Seems like a good trade. And you can easily fork go and tell it to use your proxy, and make your own package database. The code is open. The license allows it. Go for it!
Would it make more sense for Go to be owned by something like the CNCF instead of Google? Sure. But they did make it, so it's kind of their choice. It is pointless for a large company to make a brand new programming language, but they did it anyway, and it's nice that we have it. They give us lots of free stuff and ask for nothing in return. The fact that your CI system pulled a Go module is not something that advertisers are salivating over. If you want to hurt Google because you don't like them, ask your lawmakers to make advertising illegal. That would show them! But caching Go modules is not a big moneymaker for Google, it's just kind of a nice thing they do because a few employees thought it would be good. I appreciate it. If you don't, set up Athens and forget about them. I am sure you can render godoc just as nicely as pkg.go.dev with only a few hours of work. The thing is, it's boring and nobody would care.
You can also use any registry you want.
Note that most other packaging ecosystems use centralised services, where you don’t even have the option of merely turning off the proxy.
Let's not muddy conversations about the default centralized goproxy with the existence of a global TOFU service. gosumdb would be perfectly possible to query without even revealing a module import path you're asking for (just like browser-side safe browsing can do).
I have a concrete example about why module caching is good. I have an example repository that shows what happens when upstreams exercise poor release hygiene. Clone github.com/jrockway/evil-module-user. Run "go run main.go". (It's not actually evil, it just prints a message.) You will find that with the Go module proxy turned on, it compiles and prints "This is a good module!". With the proxy turned off, though, you will find that the checksum in go.sum doesn't match for the upstream github.com/jrockway/evil-module, and that evil-module has been silently compromised to become evil. What happened here is that evil-module released v0.0.1 and the module cache cached it. Then someone edited the code, and forced pushed the v0.0.1 tag to the repository, pointing at the commit. When go get reaches out to Github to clone email@example.com, it gets code that doesn't match the checksum in github.com/jrockway/evil-module-user's go.sum, because it's not the v0.0.1 that the developer of github.com/jrockway/evil-module-user used when writing the code.
Obviously this example is intentionally contrived to demonstrate this exact problem. But when I first started using Go modules early on, this happened all the time. Different engineers got different "version 0.0.1" from many repositories, and didn't notice there was a problem until CI. They then loudly complained that go modules suck, when in fact the problem is that upstream authors were very fast and loose about retagging releases. They are sending your release system code that you've never even seen! That's good that the module system detects that. But annoying to fix :) The problem all went away when Google started caching the modules -- you get the old version of the code, but at least everyone gets the same version. (As an author, you can always release v0.0.2 to bust the cache.)
I actually thought until I investigated this in great detail recently that everyone had just embraced immutable version tags and were being smart about releases, as they learned more about Go modules. Turned out I was wrong -- people are as bad as ever, but they don't break your CI build because there is now a centralized cache that gives your workstation, your coworkers, and your CI system the same code. The upstream modules authors aren't doing that. They are force-pushing with abandon.
The checksum database is of course extremely important (you want to get a known-good copy the first time you use a module), but I stand by my assertion that it's beneficial for both to be turned on by default. Yes, it's a small privacy leak. But not one that is particularly personally embarrassing or useful to adversaries. So I think the go team made the right call.
Its design is similar to that of certificate transparency, in that changes or deletions (e.g. DMCA takedowns or FISA warrants) are supposed to be detectable; see:
I'm curious if anyone has actually tried to audit it.
While offline I remember a couple go command operations were surprisingly giving me proxy.golang.org or network unavailable errors. In the sense that it had no reason to touch the network. Can you refresh my memory what they were? Or if they are still present? I can't for the life of me find or remember the answer.
It was what made me discover some of the things the article mentions, like the package index.
You can override the proxy, and there are open source implementations of the module datastore, but it's not made clear front and centre to the end user that building software will call a Google owned service.
It was a source of contention for some when the default toolchain moved in this direction.
If it were me (or my company), I would refuse to use a programming language created by a surveillance capitalist like Google.
What's next? telemetry in the Go language?
Mostly the reason is probably, that this kind of software is only written with the most basic and common used in mind, not with the one, who wants to customize everything to their own personalized needs or a user, who does not require big corp to tell them "what they want". Google targets another group of people.
So I think the wording "crapware" pretty much covers it.
Of course ethical questions like the ones raised in the article … I guess they don't usually even enter the equation at Google.