Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Go 1.13 Release Notes

golang.org

Post reply on HN
Print view View original

81–90 of 264 posts

Re: Go 1.13 Release Notes

#81

Post by matahwoosh »

onei wrote: post #57
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/

Why do you need a proxy to fetch the modules in the first place? It seems a little odd for a package manager.

It's so that you can have a seamless module version checksum [1]. The checksum in proxy ensures that you don't "trust on first use" whenever you update a module.

[1] https://go.googlesource.com/proposal/+/master/design/25530-s...

Re: Go 1.13 Release Notes

#82

Post by meddlepal »

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.

> it's a better Java.

Ah ha ha ha ha ha ha. No. Just no.

I say this as someone who writes Go day in and day out and wrote Java for a decade.

Maybe it is if the last time you touched Java was 2001.

Re: Go 1.13 Release Notes

#83

Post by ainar-g »

omaranto wrote: post #74

I haven't been keeping up with Go. Is it still the case that the only datatype than can be used as keys to a map and is not of a fixed size is string?

I'm not sure what you're talking about. Map keys in Go can be strings, numbers, pointers, some structs, etc. And that was the case since at least Go 1.0.

Re: Go 1.13 Release Notes

#85

Post by typical182 »

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 prevent a package from 
  being published to a package registry (like crates.io) by mistake, 
  for instance to keep a package private in a company.

  [package]
  # ...
  publish = false
But I would be curious if someone more knowledgeable than myself would be interested in giving a quick summary of the approach?

Re: Go 1.13 Release Notes

#86

Post by nemo1618 »

omaranto wrote: post #74

I haven't been keeping up with Go. Is it still the case that the only datatype than can be used as keys to a map and is not of a fixed size is string?

Strings are fixed-size, though. A string is a pointer and a length.

It's true that you can't use a slice as a map key, though, even though slices are also fixed-size (pointer, length, and capacity). As I recall, the argument is that the equality rules for slices are unclear. (maps and funcs can't be used as keys either, for the same reason: they're not comparable.) Is a 0-length slice equal to a nil slice? Is a slice with len 3, cap 3 equal to a slice with len 3, cap 4?

In practice, this is rarely a problem. It most commonly comes up when you want to use []byte as a key, in which case you can convert the []byte to a string. This overhead of this conversion (specifically when it occurs in the context of a map key) has been optimized away for a few versions now.

Re: Go 1.13 Release Notes

#87

Post by alexbanks »

meddlepal wrote: post #82
littlestymaar wrote: post #53

Earlier quoted context omitted.

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

> it's a better Java. Ah ha ha ha ha ha ha. No. Just no. I say this as someone who writes Go day in and day out and wrote Java for a decade. Maybe it is if the last time you touched Java was 2001.

Can you explain why they're wrong?

Re: Go 1.13 Release Notes

#88

Post by dinkleberg »

meddlepal wrote: post #82
littlestymaar wrote: post #53

Earlier quoted context omitted.

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

> it's a better Java. Ah ha ha ha ha ha ha. No. Just no. I say this as someone who writes Go day in and day out and wrote Java for a decade. Maybe it is if the last time you touched Java was 2001.

I feel like there is a better way of posting this argument than laughing at them and dismissing what they say, and not providing any reasons why you disagree.

Re: Go 1.13 Release Notes

#89

Post by rvz »

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/

> This means a proxy, governed by the Google Privacy Policy, is now capturing everyone's module usage by default.

No surprise there, was even called a 'privacy nut' on the neighboring Android 10 thread for highlighting the nature of Google's 'privacy' stance. So essentially they turn on tracking / analytics on by default for module usage without consent or any notice except for the lengthy privacy policy. This reminds me of when Microsoft VC++ embedded analytics in the developer binary when using the compiler. [0]

But then again, Google can do what it pleases since Golang is authored by Googlers.

[0] https://www.reddit.com/r/cpp/comments/4ibauu/visual_studio_a...

Re: Go 1.13 Release Notes

#90

Post by mfer »

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

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

Third, when it came to making tradeoffs one was made here. I don't know if it was explicit or not. Protections from the global checksum database as a default were put ahead of privacy as a default.

I wonder what other designs could have kept a certain amount of the global checksum protection while keeping privacy. I came up with a few idea while considering my response here.

Fourth, to really speed up performance in things like CI it's much faster to cache the modules locally. This is something used across programming languages for dependencies and most of the major CI systems have this documented. I looked at using GoCenter months ago but didn't opt for it because caching in CI was so much faster.

We were looking at things holistically rather than just with a single tool.

As I said in the blog post, I appreciate the privacy policy being up front. It is the first link on the proxy website. And, I appreciate the configuration to customize the proxy.

A lot of this has to do with the default. Most people won't change it. A lot of people are going to leak proprietary information to Google without realizing it. Everyone here can decide if that is a good or bad thing for themselves. Hopefully, they will learn the config to customize things if they want.

Post reply on HN