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

71–80 of 264 posts

Re: Go 1.13 Release Notes

#71

Post by privateSFacct »

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 think they chose a default that was designed to provide a better user experience. If you can't even let the google know what your dependencies / stack is then I think you can run your own as well.

Would be interesting to test the security at some of these companies where this is managements worry. How do these companies worry about dependency leaks but then leave huge S3 / remote exploitable web holes totally open?

If google as an adversary is your worry:

What about all the folks your org emails with that use google in various ways (including perhaps their email stack that they've turned over to google?). How many users are using google single sign on lots of places? How many of their users are using android with telemetry? Browse websites using google chrome? Browse websites that themselves use google analytics.

Google / Apple / AWS / Microsoft are at the root of trust for a lot of what happens online these days.

Re: Go 1.13 Release Notes

#72

Post by orhmeh09 »

purple_ducks wrote: post #13
abtinf wrote: post #7

Earlier quoted context omitted.

I hadn’t thought of this before, but I think you are onto something critical about Go. In a different life, I worked deep in C# and the bowels of the CLR. New versions of C# were both exciting (woo, LINQ, anonymous things, lambdas, and a dozen others each release) and frustrating (ugh, visual studio doesn’t have specialized tools to handle this new stuff). I’ve been writing Go for 8 or 9 years now and I value the too…

> I like the way Go proceeds as a language, with features added very very slowly and the compiler and tools regularly improving > I value the tool chain improvements far more than the language features Java 6 may be right up your alley ( https://en.wikipedia.org/wiki/Java_version_history )

What do you mean by this reference to an older Java version?

Re: Go 1.13 Release Notes

#73

Post by earenndil »

root_axis wrote: post #67
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.

I think in practice it has become something closer to a better python than a better java.

Personally, I don't think it's better than any of those languages.

Re: Go 1.13 Release Notes

#75

Post by meowface »

root_axis wrote: post #67
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.

I think in practice it has become something closer to a better python than a better java.

More like a "different Python" than a better one. Way more performant, way more verbose, and (IMO) way better concurrency.

Not to go off on too much of a tangent, but I think asyncio is a huge mess and was a mistake. I still use gevent for everything in Python. https://glyph.twistedmatrix.com/2014/02/unyielding.html is frequently cited as an argument for why goroutines and gevent and green threads suck and why explicit asyncio-style concurrency is better, but I have a lot of issues with this article and find the former two way easier, simpler, and faster to work with.

Re: Go 1.13 Release Notes

#76

Post by sacado2 »

zubspace wrote: post #40
ra7 wrote: post #36

Earlier quoted context omitted.

> Why does go need := with the colon? I know it's a declaration, but I haven't figured out the reason for the colon.. Seems weird.. It's called a short variable declaration that can be used in place of `var` and the type is implicit. var s string s = "foo" vs s := "foo"

I know. The question is, why does it need a colon? It seems completely superfluous, from a syntax perspective.

It's to avoid typos. Imagine there is no colon. When you type

    foo = 3
    fooo = foo + 1
Did you mean to create a new variable called `fooo` or was it a typo? Did you mean this:

    foo := 3
    fooo = foo + 1 // oops, typo found at compile-time
or that:

    foo := 3
    fooo := foo + 1 // Yep, new var, everything is ok

Re: Go 1.13 Release Notes

#77

Post by mfer »

privateSFacct wrote: post #71
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 think they chose a default that was designed to provide a better user experience. If you can't even let the google know what your dependencies / stack is then I think you can run your own as well. Would be interesting to test the security at some of these companies where this is managements worry. How do these companies worry about dependency leaks but then leave huge S3 / remote exploitable web holes totally open?…

With different companies there are different agreements. For example, when a company stores something in a private S3 bucket that company has an agreement between it and AWS on who has access to that bucket and for what reasons. The agreements allow companies to know and document risk, SLA, and many other things.

Many companies have not turned their email over to Google. Many companies are in competition or at least coopertition with Google. Many are trying to get a competitive advantage these days.

All of this was a big enough deal for Mozilla that they got a special contract with Google before using Google Analytics that says Google cannot use the data collected on Mozilla sites for other purposes.

Some won't worry or care about the implications of this. There are a bunch who will. It is not an all or nothing thing. It depends on your business if you are building stuff for a business.

Re: Go 1.13 Release Notes

#78

Post by FiloSottile »

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 possible to bypass the protections of the new Checksum Database (https://golang.org/design/25530-sumdb), a state-of-the-art authentication system that provides auditable proof that the operator is behaving honestly.

For an example of why the Mirror is valuable, beyond the 10x performance gains (depending on number of dependencies and connection latency) and security gains from not using git on the client, look no further than git.apache.org, which has been down for days breaking a number of builds (https://status.apache.org/incidents/63030p4241xj).

I really think this architecture brings together the best of the decentralized module ecosystem that Go had (with its lack of regularly compromised registry accounts, and no mismatch between code and package origin) and the centralized registries of other languages (with their better performance and reliability).

Particularly proud of how the Checksum Database provides even more security than the centralized registries (because it's cryptographically accountable for its actions, while registries can sign anything they want) without requiring authors to manage keys, register an account, or change their workflow at all.

[Note that I work on the Go team, and co-designed the Checksum Database. But of course I don't speak for the company.]

EDIT to add: I should also mention that the sumdb allows the use of any untrusted proxy, easily configured with "go env -w GOPROXY", for users that can't or don't want to use the Google provided one. The proxy can also opt-in to mirroring the Checksum Database, in which case no user requests at all need to reach the Google services, while still providing all the integrity guarantees that proxy.golang.org users benefit from.

Re: Go 1.13 Release Notes

#79

Post by sime2009 »

pcwalton wrote: post #35
sime2009 wrote: post #32

Earlier quoted context omitted.

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.

Rust has broadly the same concurrency support, with a more powerful compile-time race detector (but one that also comes with a learning curve). The main difference is that Go uses M:N threading, while Rust uses 1:1 threading with optional explicit async/await constructs.

For the threading difference, do you mean that Rust needs 'normal' threads plus async/await support, but Go can just lean on its built in concurrency support for both cases? i.e. Go threads instead of explicit async style code.

Re: Go 1.13 Release Notes

#80

Post by gameswithgo »

derefr wrote: post #30
gameswithgo wrote: post #2

I like the way Go proceeds as a language, with features added very very slowly and the compiler and tools regularly improving. I hope Rust can settle down into a similar focus soon.

I feel like Go is the way it is, mostly because its maintainers are also responsible for the continued productivity of thousands of engineers working on Google's numerous Go codebases. Any "breaking change" that requires rewriting Go code is a tangible negative for them, in that it'll interrupt Googlers from getting real work done, and the blame will come back to them. In a sense, Go is more like a corporate-internal…

Rust doesn't really introduce breaking changes. There is just a lot of cognitive power required to keep up with everything, which can make it hard to read other people's code, or know which is the 'best' way to do a thing, etc. People who disagree with this may simply have more cognitive power/time to devote to keeping up with everything in Rust. I have a day job in an entirely different universe, so keeping up with Rust is hard.
Post reply on HN