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

Go 1.9 is released

blog.golang.org

Post reply on HN
Print view View original

71–80 of 131 posts

Re: Go 1.9 is released

#71

Post by dullgiulio »

valarauca1 wrote: post #23
ivan4th wrote: post #16

I was looking forward to the fix for the dreaded Linux namespace handling problem: https://www.weave.works/blog/linux-namespaces-and-go-don-t-m... which kind of makes Go suck for many important container-related tasks. But apparently the effort has stalled... https://go-review.googlesource.com/c/go/+/46033

There really aren't great solutions to this in C/C++ having one application share state/memory across namespaces/users is a v hard problem

This has been discussed and the discussion derailed very quickly ("Go is a joke, my language has it bigger, blah blah".)

Reality is that the Linux Kernel makes a big confusion between processes and threads in the userspace APIs.

Locking to threads is a solution that works but also sucks and defeats the niceties of Go N:M model. But that's the only way: if you use that broken system calls API you should know better.

Re: Go 1.9 is released

#72

Post by zimpenfish »

_ph_ wrote: post #69
randomdata wrote: post #63

Earlier quoted context omitted.

To be fair, the Go authors have always strongly promoted that you fork and maintain your dependencies. That may be a bad operational decision (outside of Google), but is technically unrelated to the language itself. Mind you, if third party code needs debugging, you're going to have to fork it in order to apply your fixes in a timely manner anyway. Perhaps their stance is not as crazy as it may originally seem.

And with my professional experience, sometimes maintaining a program over a decade, I have to agree. When you are using an external library, you have to at least have a copy of the version you are using. Repositories might go away without a warning. Also, you want to go to a new version only after some review. Ideally, you don't have any local modifications - if you patch libraries, you should donate the changes back…

> Also, you want to go to a new version only after some review

Happened here recently - modules used in the core build aren't versioned which means when someone external updated a module with an incompatible change, the build broke.

Moral: Never build direct from CPAN / GOPAN / CCAN / WHATEVSPAN without pinned versions.

Re: Go 1.9 is released

#73

Post by arghwhat »

agnivade wrote: post #53
pvg wrote: 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.

Well, Go code is statically linked, but the runtime may try to dynamically load libc for DNS resolving. Use of cgo of course drastically change everything.

Re: Go 1.9 is released

#74

Post by arghwhat »

pvg wrote: post #41
old-gregg wrote: post #22

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.

Yes, the other guys are just being pedantic because libc is attempted loaded dynamically (but it is not required—DNS behaviour just may change without it).

Re: Go 1.9 is released

#75

Post by issaria »

alphaalpha101 wrote: post #50
pvg wrote: post #40

Earlier quoted context omitted.

They're discouraged from complaining about downvoting.

It was not a complaint, it was a question , just like my top-level comment. Was that interpreted as a complaint as well? Is that the problem?

A concurrent map in my understanding, is a map that can be accessed concurrently without explicit synchronization, not each coroutine has a piece of it. Check java ConcurrentHashMap.

Re: Go 1.9 is released

#76

Post by ptman »

riobard wrote: post #70

I'm wondering if we could abuse type alias to fake generics somehow? E.g. // file tree.go type T = YourConcreteType type TreeNode struct { Value T } // rest of tree implementation Then you can just copy the file and replace YourConcreteType at the top and voila! Seems simpler to use than the unicode hack here https://www.reddit.com/r/rust/comments/5penft/parallelizing_...

What if I want both TreeNode and TreeNode?

Re: Go 1.9 is released

#77

Post by baq »

hueving wrote: post #67
amenghra wrote: post #29

Earlier quoted context omitted.

Unless you perform a proper statistical analysis it's unfair to draw a conclusion from a single run. Furthermore, when I see a second run that's faster than the first one, I immediately wonder if it's the cache being cold for the first run and warm for the second. While I have your attention, https://zedshaw.com/archive/programmers-need-to-learn-statis... is worth reading.

"Programmers Need To Learn Statistics Or I Will Kill Them All"... What an insufferable asshat. PSA: There is no reason to behave like this and this is an incredible way to alienate a bunch of people. You either offend people directly with the murder implication or they don't take you seriously because you sound like you're throwing such an extended temper tantrum that you managed to write it all in a blog.

or you can stop being offended by words put out on the internet by strangers... which is what i always recommended to basically everyone.

Re: Go 1.9 is released

#78

Post by JosephRedfern »

fredmorcos wrote: post #62
old-gregg wrote: post #39

Earlier quoted context omitted.

Thanks :) I'm no stranger to the scrutiny of Hacker News, I did 3 builds in a row and threw out the 1st one (cache), the last two were within 0.1s of each other, so I copied & pasted the latter.

So basically there's no speedup.

I'm pretty sure he means the last two runs of the same compiler.

Re: Go 1.9 is released

#79

Post by ptman »

sebcat wrote: post #66
aleksi wrote: post #60

Earlier quoted context omitted.

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.

To expand on this: $ cat foo.go package main import ( "fmt" ) func main() { fmt.Println("Hello") } $ go build foo.go $ file foo foo: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), statically linked, not stripped compared to: $ cat bar.go package main import ( "os/user" "fmt" ) func main() { u, err := user.Current() fmt.Println(u, err) } $ go build bar.go $ file bar bar: ELF 64-bit LSB executable, x86-64, versio…

You can usually build fully static by doing

    CGO_ENABLED=0 go build
even when using os/user or net/
Post reply on HN