Go 1.13 Release Notes • Hacker News Board

Re: Go 1.13 Release Notes

#111

Post by rgbrenner » Tue, Sep 03, 2019, 9:54 PM UTC

FiloSottile wrote: post #78

mfer wrote: post #52

I started poking around and noticed that Go 1.13 now defaults to the Golang Proxy to fetch modules. This means a proxy, governed by the Google Privacy Policy, is now capturing everyone's module usage by default. Unless you change settings this includes proprietary/corp stuff. https://codeengineered.com/blog/2019/go-mod-proxy-psa/

The Modules Mirror and the Checksum Database are governed by this specific privacy policy: https://proxy.golang.org/privacy "go env -w GOPRIVATE=*.corp.example.com" was added to make it as easy as possible to configure private modules. If the environment is not set up, just the name of the module will reach the Google services, it will not be published, and an error will be returned. Anything else would have make it…

First programming language that I've had to read and understand a privacy policy to use.. and consider that it may change in the future.

The idea that the language I'm programming in now reports anything back to google is distressing.. and I say that as someone who has been programming in Go for about 7 years. What right does google have to collect usage information from modules hosted on github (or elsewhere)?

I checkout the code for the modules, review it, and commit it into my own repository. I don't need you to speed up the rare git checkout of a module. Not that I think some minor speed improvement is worth my privacy.

You talk about decentralization... while centralizing the entire thing around Google. You talk about git.apache.org being down, while you're willing to bring down the entire ecosystem across the board with your own special server.

This "feature" should have an option to disable it.. at the very least.

This is the first language in my 23 years programming that reports my usage back to the language authors. It's unprecedented. And the truth is, if this is ok to you, then there's really no limit what the code I write today, may report back to google tomorrow.

Re: Go 1.13 Release Notes

#112

Post by ngrilly » Tue, Sep 03, 2019, 9:55 PM UTC

pcwalton wrote: post #108

ngrilly wrote: post #99

Earlier quoted context omitted.

Rust is really great, but I feel like you are overselling it a bit here: - async/await is available in the nightly version of Rust (1.39), but not in the stable version (1.37). - 1:1 threading is not strictly equivalent to M:N threading (the main practical difference being that the stack size per OS thread is larger than the stack size per goroutine). Writing that "Rust has broadly the same concurrency support" is mi…

The features that each language offers are the same: threads, channels, and blocking I/O (though Rust has more features for safe concurrency--Rust prevents data races statically, while Go is not even memory safe in the presence of such races). What is different is the performance characteristics. In some cases, M:N will be more efficient; in some cases, 1:1 will be. But just as I wouldn't say Go is lacking FFI featur…

> blocking I/O

Rust I/O are strictly similar to Go when using 1:1 OS threading, but become conceptually different when using async/await.

> Rust has more features for safe concurrency--Rust prevents data races statically, while Go is not even memory safe in the presence of such races

Agreed. That's a big advantage of Rust.

> What is different is the performance characteristics.

Performance is a feature. It's significant enough to justify using one language or the other depending on the project at hand.

> In some cases, M:N will be more efficient; in some cases, 1:1 will be.

The main advantage of the M:N model, compared to the 1:1 model, is the memory usage, because each goroutine starts with a small stack (a few kB). It makes possible to start a larger number of M:N goroutines than 1:1 threads.

> But just as I wouldn't say Go is lacking FFI features because M:N makes cgo slow, I wouldn't say Rust is lacking concurrency features.

Go's FFI works but is slow. It's a well known fact. Rust's concurrency story is not stabilized yet (areweasyncyet.rs). It's a fact too. I don't see a problem with acknowledging both :)

Re: Go 1.13 Release Notes

#113

Post by TheDong » Tue, Sep 03, 2019, 10:08 PM UTC

rgbrenner wrote: post #111

FiloSottile wrote: post #78

Earlier quoted context omitted.

The Modules Mirror and the Checksum Database are governed by this specific privacy policy: https://proxy.golang.org/privacy "go env -w GOPRIVATE=*.corp.example.com" was added to make it as easy as possible to configure private modules. If the environment is not set up, just the name of the module will reach the Google services, it will not be published, and an error will be returned. Anything else would have make it…

First programming language that I've had to read and understand a privacy policy to use.. and consider that it may change in the future. The idea that the language I'm programming in now reports anything back to google is distressing.. and I say that as someone who has been programming in Go for about 7 years. What right does google have to collect usage information from modules hosted on github (or elsewhere)? I che…

> This is the first language in my 23 years programming that reports my usage back to the language authors

I suppose that means you haven't used any of:

1. nodejs, which reports your usage back to npm Inc with the exact same amount of detail (names of dependencies, ip of caller) (and stores much more, since it publishes 'downloads per month', etc)

2. rust, which does the same with crates.io

3. perl, which does that with cpan

4. python, which does that with pypi

5. ... etc

All of those languages have a central registry of packages that has the same level of detail in the metadata it can potentially collect as the go proxy does.

> This "feature" should have an option to disable it.. at the very least.

It does. Multiple options. You can run your own proxy, disable it entirely, or opt out of the go mod experiment and never run go get, but rather vendor by hand with `git clone` or whatever.

> And the truth is, if this is ok to you, then there's really no limit what the code I write today, may report back to google tomorrow.

Very much a slippery slope. They've communicated clearly how to disable it and what it does, it's in-line with what other language ecosystems do in terms of metadata reported to a central package repository, and I think it's very easy for someone to be okay with this, but to not be okay with any step beyond this line.

Re: Go 1.13 Release Notes

#114

Post by zadokshi » Tue, Sep 03, 2019, 10:10 PM UTC

The documentation makes clear, if someone accidentally commits something they shouldn't (i.e. a file containing your users personal details, credentials, etc...) then it is stuck in their proxy forever. It is clear that google employees believe we live in a perfect world where all employees never make mistakes.

https://proxy.golang.org :

> "...the mirror aims to cache content in order to avoid breaking builds for people that depend on your package, so this bad release may still be available in the mirror even if it is not available at the origin. The same situation applies if you delete your entire repository. We suggest creating a new version and encouraging people to use that one instead."

Re: Go 1.13 Release Notes

#115

Post by gjs278 » Tue, Sep 03, 2019, 10:11 PM UTC

FiloSottile wrote: post #78

mfer wrote: post #52

I started poking around and noticed that Go 1.13 now defaults to the Golang Proxy to fetch modules. This means a proxy, governed by the Google Privacy Policy, is now capturing everyone's module usage by default. Unless you change settings this includes proprietary/corp stuff. https://codeengineered.com/blog/2019/go-mod-proxy-psa/

The Modules Mirror and the Checksum Database are governed by this specific privacy policy: https://proxy.golang.org/privacy "go env -w GOPRIVATE=*.corp.example.com" was added to make it as easy as possible to configure private modules. If the environment is not set up, just the name of the module will reach the Google services, it will not be published, and an error will be returned. Anything else would have make it…

thanks but I don't want it

Re: Go 1.13 Release Notes

#116

Post by xvector » Tue, Sep 03, 2019, 10:13 PM UTC

zadokshi wrote: post #114

The documentation makes clear, if someone accidentally commits something they shouldn't (i.e. a file containing your users personal details, credentials, etc...) then it is stuck in their proxy forever. It is clear that google employees believe we live in a perfect world where all employees never make mistakes. https://proxy.golang.org : > "...the mirror aims to cache content in order to avoid breaking builds for peo…

If you commit and push your credentials, they have been compromised, full stop. This proxy should make no difference to how you handle such a compromise.

Re: Go 1.13 Release Notes

#117

Post by Zancarius » Tue, Sep 03, 2019, 10:15 PM UTC

rgbrenner wrote: post #111

FiloSottile wrote: post #78

Earlier quoted context omitted.

The Modules Mirror and the Checksum Database are governed by this specific privacy policy: https://proxy.golang.org/privacy "go env -w GOPRIVATE=*.corp.example.com" was added to make it as easy as possible to configure private modules. If the environment is not set up, just the name of the module will reach the Google services, it will not be published, and an error will be returned. Anything else would have make it…

First programming language that I've had to read and understand a privacy policy to use.. and consider that it may change in the future. The idea that the language I'm programming in now reports anything back to google is distressing.. and I say that as someone who has been programming in Go for about 7 years. What right does google have to collect usage information from modules hosted on github (or elsewhere)? I che…

> This "feature" should have an option to disable it.. at the very least.

You should be able to. It's not the ideal solution (or recommended for most use cases), but you can by setting GOPROXY=off. GOPROXY=direct will force it into its previous behavior.

The same should be true for the checksum DB with GOSUMDB=off. I don't remember specifically and can't find the page its options were documented on.

Also look at GOPRIVATE and GONOSUMBDB.

Re: Go 1.13 Release Notes

#118

Post by TheDong » Tue, Sep 03, 2019, 10:16 PM UTC

mfer wrote: post #90

FiloSottile wrote: post #78

Earlier quoted context omitted.

The Modules Mirror and the Checksum Database are governed by this specific privacy policy: https://proxy.golang.org/privacy "go env -w GOPRIVATE=*.corp.example.com" was added to make it as easy as possible to configure private modules. If the environment is not set up, just the name of the module will reach the Google services, it will not be published, and an error will be returned. Anything else would have make it…

First, I think proxies have their place. Please don't mistake my comment for any issue with proxies themselves. Second, the don't need Git part is a bit of misdirection. Other package manager (Composer for PHP comes to mind but there are others, too) can pull the source at a version right for GitHub. This is much faster than using Git and people have been doing it for some time. Typically it's pulled down as a tarbal…

> You don't need a proxy to have git out of the loop for downloads or install time stuff.

You do with go because go uses git tags for version information and must parse the `go.mod` file at various versions.

Go also supports git repositories hosted in places other than github, where there's no standardized way to fetch a single file at a tag (the go.sum file), or to perform a suitable search for a versoin and its metadata.

> This [pulling github archives] is much faster than using Git

That's only true if you only ever look at a single version of a library. If you have a 20MB git repo at v1.2.3, and ~100KB of files change for the v1.2.4 patch release, using the zip/tar archive means you have to download 40MB total to use it and update it to the new patch. Using the git repository in the first place means the update can only download 20MB since the new `fetch` will be effectively zero data, assuming you cache git stuff well.

Re: Go 1.13 Release Notes

#119

Post by geodel » Tue, Sep 03, 2019, 10:17 PM UTC

erik_seaberg wrote: post #95

alexbanks wrote: post #87

Earlier quoted context omitted.

Can you explain why they're wrong?

Java got async I/O in 2002, generics and "for (x : iterable)" in 2004, and lambdas in 2014. Vintage 2001 Java was drastically harder to read and slower, though error handling was always less cumbersome than Go.

When did Java get versioned modules, value types, installable binaries, dynamic heap size?

Re: Go 1.13 Release Notes

#120

Post by Groxx » Tue, Sep 03, 2019, 10:19 PM UTC

sime2009 wrote: post #32

sjroot wrote: post #29

Earlier quoted context omitted.

“Go is to services what Rust is to systems.”

Would it be fair to say that Go's concurrency support makes it a good match in the network services space? I see Go more often in Docker and cloud contexts.

Personal opinion: no. Go's concurrency is hard to control or monitor, and it's hard to make higher level abstractions that are both safe and convenient. It's of course possible, but the tradeoffs are rather severe.

Go's concurrency shines best in short-lived single-purpose processes, which is a near perfect fit for CLI tools. When you don't care if something gets abandoned or fails to make progress and can just ctrl-c, the relative simplicity is 100% worth it. Other parts of Go work well here too, especially the very low startup overhead (unlike, say, python). For long lived processes though, like most services, it feels very error-prone or very boilerplatey and manual.