Go 1.13 Release Notes • Hacker News Board

Re: Go 1.13 Release Notes

#121

Post by [deleted] » Tue, Sep 03, 2019, 10:23 PM UTC

Zancarius wrote: post #117

rgbrenner wrote: post #111

Earlier quoted context omitted.

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 GOPR…

[deleted]

Re: Go 1.13 Release Notes

#122

Post by zeeboo » Tue, Sep 03, 2019, 10:31 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…

> 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.

If the proxy goes down, by default the command falls back to directly fetching.

Re: Go 1.13 Release Notes

#123

Post by typical182 » Tue, Sep 03, 2019, 10:34 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.

The Go 1.13 Release Notes lead off with documentation links for how to disable and otherwise configure this:

"See https://proxy.golang.org/privacy for privacy information about these services and the go command documentation[1] for configuration details including how to disable the use of these servers or use different ones. If you depend on non-public modules, see the documentation for configuring your environment[2]."

[1] https://golang.org/cmd/go/#hdr-Module_downloading_and_verifi...

[2] https://golang.org/cmd/go/#hdr-Module_configuration_for_non_...

Re: Go 1.13 Release Notes

#124

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

ainar-g wrote: post #84

littlestymaar wrote: post #48

Earlier quoted context omitted.

Without cargo though

Genuine question: What does Cargo do that Go 1.11 modules can't?

Applying the bug fixes in a dependency I'm using when a new version of it is published… [1]

Sarcasm apart, I wasn't talking about features. But cargo is a really well-designed package manager. I've been using Rust full-time for 2 years now and it had never annoyed even once.

[1] the sarcasm was referring to the Minimum Version Selection algorithm used by go's package manager, which is a really bad case of NIH from Go's teams who decided to throw away a thriving community work to do their own stuff, ending up with something different from what everybody else has been for more than 20 years. And unsurprisingly, it's really bad…

Re: Go 1.13 Release Notes

#125

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

littlestymaar wrote: post #53

bsaul wrote: post #49

Earlier quoted context omitted.

Rust can't settle down right now, because it still has to make necessary changes to critical parts of the language, such as async. Go always had a very narrow and precise ambition and scope (a better C, aimed at server-side data plumbing). Which is the reason why it was able to nail a set of features from the start and keep it that way. Rust has a much wider ambition : all the modern languages facilities (generics, m…

> a better C, aimed at server-side data plumbing I agree with all what you said but this. Go isn't a better C, it's a better Java.

One day, when it has proper generics, interface validation without compiler error tricks, and an usefull portable UI library, it might be a better Java.

Re: Go 1.13 Release Notes

#126

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

typical182 wrote: post #85

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/

I've used Rust a bit, but not enough to know the details of how cargo and crates.io approach managing collected information. There seems to be an open issue and WIP PR with more details: Issue: https://github.com/rust-lang/crates.io/issues/955 PR: https://github.com/rust-lang/www.rust-lang.org/pull/919/file... The cargo manifest also supports things like: The publish field (optional) The publish field can be used to…

Publish isn't necessary for the Go version, since the model is on-demand pull driven. godoc.org is the same way: there's no way for private code to end up there unless your private code is actually public.

The privacy concern is entirely that Google may see the name of some module you attempted to download.

Re: Go 1.13 Release Notes

#127

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

xvector wrote: post #116

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.

Actually it does make a difference. If an employee accidentally commits a CSV file with customer private data, are you actually suggesting that it should not be possible to remove it?

I disagree. The quicker that the personal data can be taken down, the less chance there is for someone to discover that personal data. I can't imagine any large company being comfortable with developers choosing technology that makes this harder to deal with than it should be.

(I am not at all suggesting this scenario is ok, simply asking how one would deal with it if the scenario should occur.)

Re: Go 1.13 Release Notes

#128

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

geodel wrote: post #119

erik_seaberg wrote: post #95

Earlier quoted context omitted.

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?

Installable binaries, around 2000, when the first commercial JDKs started having AOT compilation to native code.

Currently available on PTC, Aicas, IBM, OpenJDK AppCDS (originally from BEA J/Rockit), GradleVM native images, Android ART AOT compilation.

Dynamic heap size, since ever. Every JDK vendor had their own specific switches to configure it.

Versioned modules, since Java 9 alongside Maven/Gradle.

Value types, yeah point taken. There were Azul and IBM specific extensions, ObjectLayout and PackedObjects respectively, and the 2nd experimental release for value types was just made recently available.

Re: Go 1.13 Release Notes

#129

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

zeeboo wrote: post #122

rgbrenner wrote: post #111

Earlier quoted context omitted.

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…

> 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. If the proxy goes down, by default the command falls back to directly fetching.

You can also pick your own proxy primary and fallbacks.

For example, this should in theory work to make the google-run proxy your fourth choice, with three other proxies attempted before the google-run proxy, and with direct (no proxy) access as the fifth and final fallback:

  go env -w GOPROXY=gocenter.io,goproxy.io,goproxy.cn,proxy.golang.org,direct

There is some geographic diversity in that example as well -- I think two mirrors in that list are primarily run in China.

Re: Go 1.13 Release Notes

#130

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

est31 wrote: post #104

pcwalton wrote: post #93

Earlier quoted context omitted.

Does the compiler bootstrap version matter though? Taking the principle that compilers should compile on the most easily accessible toolchain, writing the compiler in C++ would be the best option of all. But nobody wants to do that.

Yeah, if you take the principle further it would be even better to write it in C89 because this language is comparatively easy to write compilers for. But the principle is not absolute and it doesn't stand above everything else. There are major differences in how easy it is to write compilers in C++ vs C89. There are major differences between C++ and Rust with its ADTs and pattern matching. But are there major differ…

Why the odd one?

D has been replacing the C++ code with D, .NET made a major reboot with Rosyln where VB.NET and C# got bootstraped (F# was already bootstrapped), OCaml and Haskell have only the runtime in C due to convinience with everything else bootstraped, FreePascal is bootstraped, OpenJDK has the long term goal of replacing C++ with Java/Graal, Jikes was bootstraped in Java, ...