Live data from Hacker News

Go 1.9 is released

blog.golang.org

51–60 of 131 posts

Re: Go 1.9 is released

#51
post #41

In case someone cares about these things, I compared the build times and the binary sizes for 1.9 vs 1.8.3 using the open source project we maintain [1]. This is on a 6-core i7-5280K: Build time with 1.8.3: real 0m7.533s user 0m36.913s sys 0m2.856s Build time with 1.9: real 0m6.830s user 0m35.082s sys 0m2.384s Binary size: 1.8.3 : 19929736 bytes 1.9 : 20004424 bytes So... looks like the multi-threaded compilation ind…

Aren't go programs statically linked? The change in binary size might be completely unrelated to changes in the compiler.

Runtime has changed too... slightly

Re: Go 1.9 is released

#52

Earlier quoted context omitted.

Standard practice is to use a mutex to guard against concurrent usage.

also necessary for reads? Also, do you have any good references to proper best practices around concurrent and parallel programming? (in Go.) Like just basic things. Code I can copy and paste without it having obscure race conditions because that use of mutex is absolutely correct, and something that lets me understand the limitations. I feel like it is very easy to do things "wrong" or not notice some edge cases. In…

I would suggest you to read the book "Concurrency in Go", by Katherine Cox-Budai, 2017: http://shop.oreilly.com/product/0636920046189.do

Re: Go 1.9 is released

#53
post #41

In case someone cares about these things, I compared the build times and the binary sizes for 1.9 vs 1.8.3 using the open source project we maintain [1]. This is on a 6-core i7-5280K: Build time with 1.8.3: real 0m7.533s user 0m36.913s sys 0m2.856s Build time with 1.9: real 0m6.830s user 0m35.082s sys 0m2.384s Binary size: 1.8.3 : 19929736 bytes 1.9 : 20004424 bytes So... looks like the multi-threaded compilation ind…

Aren't go programs statically linked? The change in binary size might be completely unrelated to changes in the compiler.

> Aren't go programs statically linked?

Not by default. You have to set CGO_ENABLED=0 to statically link libc.

Re: Go 1.9 is released

#54
post #41

Earlier quoted context omitted.

Aren't go programs statically linked? The change in binary size might be completely unrelated to changes in the compiler.

> Aren't go programs statically linked? Not by default. You have to set CGO_ENABLED=0 to statically link libc.

Do native Go programs use libc?

Re: Go 1.9 is released

#55
post #47

Earlier quoted context omitted.

Errors can be anything. It's just an interface.

Except you don't get to control the specific error type returned by packages you import. So sure, you could get stack traces for your code, but not for your dependencies. It infuriates me when go proponents try and sweep bad language decisions under the rug with half-fixes. https://twitter.com/codebeeCA/status/885302657178587136

It's worth noting that nobody is saying you can't fix that problem in your dependencies.

When you rely on dependencies you have to expect that not all of them will carry the same quality of code which you create yourself.

Re: Go 1.9 is released

#58

In the release notes it says: "Mutex is now more fair." Source: https://golang.org/doc/go1.9#sync Does anyone know what that means?

You piqued my curiosity :) A comment in the source for the release notes (https://github.com/golang/go/blob/master/doc/go1.9.html#L922) points to the relevant change: https://go-review.googlesource.com/c/go/+/34310, which in turn links to this issue: https://github.com/golang/go/issues/13086

Re: Go 1.9 is released

#60
post #54

Earlier quoted context omitted.

> Aren't go programs statically linked? Not by default. You have to set CGO_ENABLED=0 to statically link libc.

Do native Go programs use libc?

For a few things like system DNS resolver in net package (can be switched to the pure Go version with compile-time or run-time switch) and getting user's home directory in os/user package.
Post reply on HN