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

Go 1.7 is released

blog.golang.org

Post reply on HN
Print view View original

41–50 of 141 posts

Re: Go 1.7 is released

#41

Post by mintplant »

namelezz wrote: post #25
mattetti wrote: post #21

Earlier quoted context omitted.

The faster compilation time & speed up is quite real in our real life prod application. From Go 1.6 to 1.7: Test suite (CI), from 3:34 to 1:48 Docker image building, from 3:05 to 1:50 https://twitter.com/mattetti/status/763913903600349184

Following the twitter link and got this: "Something is technically wrong. Thanks for noticing—we're going to fix it up and have things back to normal soon."

I've noticed this too on random pages. Seems Twitter is having issues today.

Re: Go 1.7 is released

#42

Post by [deleted] »

woah wrote: post #31
ufmace wrote: post #22

Earlier quoted context omitted.

I suggest giving Ruby a try too. I find it great for both web dev and local automation scripts. You can do pretty much anything you can do in bash but with clearer and shorter code. I've been writing all my non-trivial automation code in Ruby for years. Rails is just a popular web framework for Ruby, there's a lot more the language can do.

It's annoying to have to install the ruby interpreter onto everything. Go feels a lot like a scripting language, but produces binaries.

[deleted]

Re: Go 1.7 is released

#43

Post by Cidan »

sfrailsdev wrote: post #8

vendor directories are no longer optional, which is nice. Go get now update submodules... I'm honestly not sure what the current hack is for package management, but I assume people are still doing wrappers around go get to pin to commits/versions, (or else building your own repos for funsies), and I'm wondering if that breaks anything.

To be clear, vendor directories are still optional to use, you just don't have to enable them by default.

We use a unirepo for all of our Go work, and being forced to use the vendor directory would be a massive headache.

Re: Go 1.7 is released

#44

Post by voltagex_ »

Scaevolus wrote: post #20
cm3 wrote: post #18

Earlier quoted context omitted.

BTW, what does one have to do to get fully statically linked executables? The binaries I've created with go get SOMETHING are linking against libc, but I remember that go doesn't rely on the system libc. Has that changed? For instance I just installed git-appraise, and it's a dynamically linked executable. What am I doing wrong?

Go generally links to libc to use the system's getaddrinfo-- some OSes override it to do special things with dynamically discovered hosts on local networks, interfacing with LDAP/AD, etc. If you use `CGO_ENABLED=0 go build`, it should make a statically linked executable.

By some OSes, you mean any Linux distro with Avahi installed, right? I'm assuming getaddrinfo checks NSS for where to look up hostnames.

I should also check how Windows with Bonjour behaves.

Re: Go 1.7 is released

#45

Post by loosescrews »

cm3 wrote: post #18
oxplot wrote: post #4

Earlier quoted context omitted.

And smaller binary size too. For a statically linked blob, that's a big plus.

BTW, what does one have to do to get fully statically linked executables? The binaries I've created with go get SOMETHING are linking against libc, but I remember that go doesn't rely on the system libc. Has that changed? For instance I just installed git-appraise, and it's a dynamically linked executable. What am I doing wrong?

It is probably the net package. The net package depends on cgo and libc for some DNS resolution. There is a pure Go implementation, but the cgo one is used if cgo is available. If you disable cgo as the other comments say, the pure Go implementation will be used instead. Alternatively, you can not include the net package.

Search for systemConf().canUseCgo()

https://github.com/golang/go/blob/master/src/net/lookup_unix...

Re: Go 1.7 is released

#46

Post by cyphar »

The one thing that really pisses me off about the way Go handled vendoring is that they did it in a way that makes it incompatible with GOPATH. Previously in runC and Docker, we had build hacks that would symlink (or full copy) the current directory into vendor/src/ and then set the GOPATH to vendor/. This was compatible with every go version. In addition, many other projects did the exact same thing.

But the way that vendoring works in Go 1.5 and up is that you make vendor not a valid GOPATH and you have to now either create a fake GOPATH and move your current directory into it, or you have to do some symlink stuff within vendor/ that doesn't really work. Why was such a small cosmetic change seen as a good idea? It's needlessly incompatible with previous ways of making vendoring work seamlessly with Go.

I'm hoping that the packaging discussions that are going to be happening over the next few months don't result in a similar decision that "we know best".

Re: Go 1.7 is released

#47

Post by cyphar »

Yay, s390x support is finally in mainline! Finally we (SUSE) no longer needs to use gcc-go to build Go binaries on some platforms (we've had nothing but issues from gcc-go, half of the patches we apply to Docker are to make it behave when built with SLE's gcc version).

Re: Go 1.7 is released

#48

Post by kyrra »

Scaevolus wrote: post #20
cm3 wrote: post #18

Earlier quoted context omitted.

BTW, what does one have to do to get fully statically linked executables? The binaries I've created with go get SOMETHING are linking against libc, but I remember that go doesn't rely on the system libc. Has that changed? For instance I just installed git-appraise, and it's a dynamically linked executable. What am I doing wrong?

Go generally links to libc to use the system's getaddrinfo-- some OSes override it to do special things with dynamically discovered hosts on local networks, interfacing with LDAP/AD, etc. If you use `CGO_ENABLED=0 go build`, it should make a statically linked executable.

I don't believe that has been true for a few releases now. I believe go defaults to a pure Go resolver implementation now. You have to force enable the cgo resolver.

https://golang.org/pkg/net/

Re: Go 1.7 is released

#49

Post by hacknat »

cyphar wrote: post #46

The one thing that really pisses me off about the way Go handled vendoring is that they did it in a way that makes it incompatible with GOPATH. Previously in runC and Docker, we had build hacks that would symlink (or full copy) the current directory into vendor/src/ and then set the GOPATH to vendor/. This was compatible with every go version. In addition, many other projects did the exact same thing. But the way tha…

I just wish they would add tagging support.

Re: Go 1.7 is released

#50

Post by jadbox »

mattetti wrote: post #21
travjones wrote: post #7

Great work, Go team! Standout points in my opinion: Overall performance improvements: >> "We observed a 5–35% speedup across our benchmarks." Decreased compile times and binary size: >> "While these changes across the compiler toolchain are mostly invisible, users have observed a significant speedup in compile time and a reduction in binary size by as much as 20–30%." Vendoring dependencies by default: >> "...and in…

The faster compilation time & speed up is quite real in our real life prod application. From Go 1.6 to 1.7: Test suite (CI), from 3:34 to 1:48 Docker image building, from 3:05 to 1:50 https://twitter.com/mattetti/status/763913903600349184

How large-ish is your codebase?
Post reply on HN