Go 1.5 is released | Hacker News Reader

Go 1.5 is released

blog.golang.org

559 pointsrsc103 comments

Congrats, this is a huge release.

We had some weird corruption of memory issues late in the 1.5RC cycle.

It's possible that https://github.com/golang/go/commit/3ae17043f7f29f0d745aa35b... fixed it, but each test for bisection cost us 4 hours, and the bug didn't always show. (When it did show, it definitely showed without -race mode on, contrary to the comments in the patch)

Anyway, if you have a large memory usage highly concurrent go app, I would still tread lightly and carefully with this release; we spent a goodly amount of time blaming our own code before realizing that 1.4.2 did not exhibit the problem.

To be fair, this is true of pretty much any major release of a new piece of software: tread lightly and test carefully before deploying to production.

The new GC, default GOMAXPROCS > 1, and changes to the scheduler may well expose latent bugs in code that worked fine in Go 1.4.

Totally. We've been mostly running tip for some time, and sending in bug reports when we can be useful, overall a big win for us, but not without its risks. :)

Honestly, I could have seen rebranding 1.5 to 2.0; there are major under the hood changes you guys have made.

I can see that, and I've been idly wondering over the past few days what the largest N will be for Go 1.N. The contrast with most version numbering, however, is that we've defined a meaning for Go 2: it breaks all your Go 1 programs. Being a Go 1.X release is actually a stronger statement about how your code will behave.

Waiting for the confusion when Go1 2.0 is released :). Or are you thinking of 1.10?

"Go1 2.0" is meaningless, Go X refers to Go X.Y.Z. Many FOSS programs treat X, Y and Z as numbers rather than digits, and increment X when there is a breaking change in the API or some serious restructuring/change (this is starting to change, recently we see programs incrementing major version periodically [most remarkably, Linux, Firefox, GCC have jumped on this bandwagon], these days only FOSS libraries are seriously sticking to that.) so yeah, it's probably going to be 1.10 and so on.

I would hope that 1.5 to 2.0 would have some semantic changes to the language as opposed to just implementation tooling.

I've learned not to even ask about type improvements. :(

>"The compiler tool chain was translated from C to Go, removing the last vestiges of C code from the Go code base."

This is really cool. Writing a compiler in the language that you're compiling seems kind of meta. The language has evolved to a point to where it can consume and build itself. Far out mannnnn.

Thanks Go team!

Perhaps this is a dumb question, but what language was used to compile the compiler? Was it compiled in C? Surely it must have had to of been compiled in a different language somewhere down the chain.

It is built with Go 1.4. Details: https://golang.org/s/go15bootstrap

The 1.5 build requires you to have a go1.4.2 build which is used as the bootstrapping compiler.

yes.. golang's compiler was originally in C. The process is called bootstrapping: https://en.wikipedia.org/wiki/Bootstrapping_(compilers)

well, it's actually turtles all the way down.

There is a good presentation from Pike talking all about the what/why/how of the C -> Go transition:

http://youtu.be/cF1zJYkBW4A

http://talks.golang.org/2015/gogo.slide

Although you can end up with fun situations like the C compiler backdoor: http://scienceblogs.com/goodmath/2007/04/15/strange-loops-de...

Haven't read the article you linked to, but the Brian Kernighan talk it discusses is fantastic, one of my favorite reads in the field:

https://www.ece.cmu.edu/~ganger/712.fall02/papers/p761-thomp...

That's ken, not bwk.

D'oh. Thanks.

You can start from the C version and move forward and check that you get the same result as starting with released Go binaries.

Unless you think Ken somehow backdoored the original C compilers to backdoor every C compiler in the world to backdoor the Go compilers that came about decades later. :-)

Seems simpler to just backdoor the linker/library archiver, that way almost all toolchains are backdoored. ;)

How has this affected compile speeds? Go proponents often tout the speed at which it compiles code as an important feature, so I wonder if there's been a noticeable regression.

> Builds in Go 1.5 will be slower by a factor of about two.

https://golang.org/doc/go1.5#performance

Perhaps things have improved since then, but this thread indicates build times will regress a little:

https://groups.google.com/forum/#!msg/golang-dev/6obxRcm-rqc...

Slower in the short term while the code remains transpiled from C. Will get faster as the team goes over it a couple times.

Yes, this is a good summary.

The small increase in build times doesn't bother me at all when I'm generating a binary, but unfortunately it's very noticeable and irritating when using tools like vim-go or syntastic which type-check/lint/gofmt your code. Using these now causes vim to be unresponsive for up to a second every time I save, whereas the delay used to be insignificant.

> which type-check/lint/gofmt your code

Those tools do not use the Go compiler. They're using go/ast or go/types. So the translation of gc from C to Go can't have affected them.

They also build the source file, which is indeed much slower, to about 2x.

>This is really cool. Writing a compiler in the language that you're compiling seems kind of meta.

It's been done before, for more than one language, IIRC.

The technique by which they make an executable of a compiler for language L on platform B, using an existing executable of the same compiler for L on platform A, together with the source code of the compiler for L on A, is also cool. I forget the full details right now. Maybe someone else will pitch in and explain. It's called bootstrapping. It's also related to cross-compiling.

Update: Looked it up in Google:

https://en.wikipedia.org/wiki/Bootstrapping_(compilers)

https://en.wikipedia.org/wiki/Cross_compiler

Also see Canadian Cross under above article - this is like the cool technique I talked about above, but more complex.

TypeScript does the same thing - its compiler is written in TypeScript. See https://github.com/Microsoft/TypeScript/tree/master/src/comp.... But yeah, darned cool, and very meta.

The term is self-hosting compiler, when a compiler can compile itself.

https://en.wikipedia.org/wiki/Self-hosting

As the old hacker snark says 'Any language that can't compile itself is a toy language'.

This might be a dumb question: What happens if you find a bug in the language? Let's say something that you had written in C was being misinterpreted, and now the go compiler still uses that byte-code to compile new versions of the compiler.

Or is that something that isn't really possible?

I think Russ showed the translated code produces the same binaries as the Go 1.4 C variant. So this isn't very likely given he has the option to pipe roughly any Open Source Go project through the compiler.

You should read Reflections on Trusting Trust, it expands on this idea in the most beautiful way: https://www.ece.cmu.edu/~ganger/712.fall02/papers/p761-thomp...

I am glad there is now support for vendor directories, albeit experimental at this stage.

https://go-review.googlesource.com/#/c/10923/

Go 1.5 vendor proposal:

If there is a source directory d/vendor, then, when compiling a source file within the subtree rooted at d, import "p" is interpreted as import "d/vendor/p" if that exists.

When there are multiple possible resolutions, the most specific (longest) path wins.

The short form must always be used: no import path can contain “/vendor/” explicitly.

Import comments are ignored in vendored packages.

agreed. That's the main reason I'm upgrading.

Is there any scoping on what vendoring means for forking projects? i.e. if I pull something full of packages like domain.com/user/pkg, would I now be better served just dropping the whole subdirectory tree in a /vendor/ directory?

We were excited enough we pivoted glide, the package manager, to directly support this new vendor setup.

Anyone interested can learn more at https://github.com/Masterminds/glide or where I posted about it at http://engineeredweb.com/blog/2015/glide-0.5-go-vendor-suppo....

I'm hopeful for this brave new vendor world.

Can't seem to get this to work no matter what I do. And yes, I've set the GO15VENDOREXPERIMENT=1 env variable.

If you use ARM devices, it might be worth pointing out that Dave Cheney has unofficial tarballs of _older_ versions here:

http://dave.cheney.net/unofficial-arm-tarballs

No 1.5 (yet), but if, like me, you do ARM stuff, you might want to bookmark this.

And of course the cross-compiler works, but still.

(edit: moved mention of ARM to first line)

Congratulations on the 1.5 release. I already updated my dev machine and everything looks to be still running without errors. Soon my servers will get updates, too!

PS: If you want to benefit from 1.5 improvements don't forget to recompile your go programs ;)

And you can recompile in shared object mode if you want tiny programs and shared linking too, though you'll lose the benefit of the single static binary.

    go install -buildmode=shared std
    go build -linkshared

We updated Splice's CI to 1.5 and rolled out our code to prod. The total GC pause time improvement is quite drastic for us: https://twitter.com/mattetti/status/634114976362291200

Throughput hasn't changed and average performance is about the same for us (slightly faster actually)

Same here! https://twitter.com/brianhatfield/status/634166123605331968

Thanks for sharing. How do you measure that? I also would like measure my Go 1.4 services first, and then with 1.5

So, who's gonna be the first to blog about compiling a Go lib as c-shared dynamic lib and call it from Rust for serious HN karma? Seriously though, there are several well-written Go libraries for accessing systems that I wonder if the runtime isn't too much baggage to keep the shared libs from being used outside of Go.

Still no real debugger?

https://golang.org/doc/gdb

https://github.com/derekparker/delve

gdb is not a real option at the moment. Being unable to easily parse through maps wipes and slices wipes out most of the actual use cases.

printf isn't good enough for you?

Logging can be of great practical utility, but being able to stop a program and freeze it in its state to figure things out is also pretty nice right. You can walk up and down the stack, inspect the scope and the state of things, walk through line after line of code to try and find things in a way that would take a really long time with logging.

So no, printf is not good enough. That's why people have created debuggers.

While I can see the argument for and against printf, with the cpu and memory profiling tools, you can basically figure out where most of the issues in your code are. I'd say for most applications, logging, printf, etc. can get you 80% of the way there. Profiling gets you another 10%. For those last mile apps, sorry, but you have to use GDB.

If you don't care how long it takes, sure, tracing with printf works. But a debugger accomplishes the same task in minutes rather than hours. Even if you know only the very basics of how to use a debugger, it's an extremely effective tool.

It's not always effective - many developers will often save minutes of thinking by spending hours dicking about in a debugger and setting up state.

But it is true that for some types of bugs a step debugger is damn handy. And for some types, mostly a distraction.

This attitude is so toxic, it's like saying isn't assembler good enough for you?

Good tools matter, there's nothing more painful then a platform where your only debugging is printf.

Good tools take time. Complaining about not having them is not very sporting behaviour. Fact is, if you don't have a tool, use printf-style debugging. It has worked for computers since before the very first debugger was ever made, and as a skill it should not be discounted in favour of more, shall we say .. consumer-ist .. attitudes about what 'should' and 'should not' be a normative in programming toolkits. No debugger? No problem. Debuggers are a luxury and a time-saver, but knowing your code-base well enough, because you printf-debug too, is also a time-saver.

If you read carefully, you'll see that I was saying the "good enough" attitude is toxic. I was not complaining about not having the tools(I don't even write Go) and a contributor mentioned above that it just wasn't a priority(which I have some beef with) but is a fair statement.

There are some problems that can't be solved by printf debugging. They include:

-GPU Performance profiling: All your commands are async and appear immediate, teasing out performance characteristics takes a massive suite of tests and may not even reproduce your issue.

-Thread concurrency issues: Adding a printf can actually make these bugs disappear as printf usually has some sort of memory fence or flush semantics that change behaviour.

-Platforms that can't handle large amounts of trace logging: Sony PSP was one of these where each printf() required the tcp ack before the buffer would clear after a trivial amount of logs.

One of the core tenants of comp sci and technology in general is building on what came before. That's where our productivity gains come from. Not taking that approach is a dangerous mentality that can have serious implications on your velocity and agility and is not a choice to be made lightly.

> Debuggers are a luxury and a time-saver

You must have only worked on toy applications before.

Because debuggers are essential on any non trivial application.

The funny thing is, in several years of using Go in production in what are certainly non-trivial applications, I was able to find any bug either through log-debugging, often with the help of isolating code in unit tests, or through pprof, in particular the net/pprof integration. Just looking at my own experience, I never _needed_ an interactive debugger, or deemed it essential, but then, that's just one data point.

On the contrary: in my domain, highly parallel distributed applications, debuggers are near useless.

Leaning on debuggers is something newbies and guru's do, when they need it, if they need it, if they have it. If they don't, it doesn't stop the debugging.

I agree and was being sarcastic.

> This attitude is so toxic, it's like saying isn't assembler good enough for you?

Real programmers don't need an assembler; ed(1) is sufficient and if you can't write a program without anything else, you shouldn't be allowed near computers.

https://xkcd.com/378/

The story of Mel: http://www.catb.org/jargon/html/story-of-mel.html

Hopefully my upvote helps counteract those who didn't realize you were being sarcastic! You made me laugh, at least :)

Even if the original post was sarcastic I've seen this expressed seriously enough in the wild that I think it still should be addressed.

I use printf-debugging the vast majority of the time. But that's fine if you know you have an alternative and you're just lazy to use it.

Recently I was working on an embedded platform which had no debugger support at all. There was some On-Chip debugger option, but it required some soldering and hacking some jtag cable, still too lazy.

Despite the laziness, I ended up implementing gdb support for that platform, over it's normal serial port: https://blog.cesanta.com/esp8266-gdb

Go at least has stack traces with no extra tooling, which is a big deal. Anyway, the more tools the better; you're gonna miss them when you need them most.

Not sure if he was sarcastic -- tons of people say the same thing with a straight face.

Ditto for me :)

Why, do we only strive for "good enough" in tooling?

Contrast your response to Russ Cox's answer: "We are well aware of the hole, though, and we'd like to plug it, but other work took priority this release cycle".

For school projects, it's more than enough. For a real world enterprise development, sadly, go without a debugger/supported environment, is a no-go.

The creators being Plan 9 fans, they might want you to use Acid[0]

[0] http://plan9.bell-labs.com/sys/doc/acidpaper.html

plan9port's version of acid(1) is currently limited, however: https://swtch.com/plan9port/man/man1/acid.html

See BUGS.

Acid is fantastic, but I really wouldn't wish it on anyone. Incredibly powerful but incredibly awkward language.

No, sadly. We are well aware of the hole, though, and we'd like to plug it, but other work took priority this release cycle.

Any comment on what we might be able to expect in 1.6?

No, sorry. Go 1.6 planning is just beginning.

At the last Gophercon Delve was presented as the go to tool, I remember the pres was fast but It was convincing enough. You're also free to add a vim or any IDE view with interaction based on it.

This is a pretty good cross platform Go debugger: https://github.com/mailgun/godebug

What is wrong with delve?

I'm continually surprised at how fast the Go team works.

Happy to see Travis-CI updated gimme[1] with 1.5 support just now!

I've been anticipating the change and had already updated my .travis.yml file in my stats package[2] which would fall back to tip.

[1] https://github.com/travis-ci/gimme/issues/19

[2] https://github.com/montanaflynn/stats

Kudos to the Golang team and its many contributors. The reduction in latency with concurrent GC is a massive step forward. I wouldn't be surprised to see Golang gain significant traction in the research and HPC communities in the near future.

Also glad to see wide adoption in Chinese consumer internet running at gargantuan scale: Tencent, WeChat, Didi Kuaidi and many more. Are you guys at all surprised to see it take off on the mainland?

I'm still a beginner with code. I've been learning HTML (not yet CSS, as far as I know) and Markdown, and I'm also in the middle of learning Python using free courses on Udacity. This is all in my free time. No courses taken. Would this be a good language to learn right now, or would I be better off waiting till I'm more experienced?

What's the state of dynamic linking in go? even with C libs , is it supported ? if yes does it work on Windows ? thx.

It is supported. So you can both compile your go packages as a shared object file and link against it and you can compile it into a shared library and load it from C.

I have no idea about windows support.

Very little of what was planned was implemented in 1.5. See the design doc: https://golang.org/s/execmodes

edited summary:

- Go code linked into, and called from, a non-Go program

In the Go 1.5 release this mode is implemented, using a .a file, for most Unix systems.

- Go code as a shared library plugin with a C style API

In the Go 1.5 release this mode is implemented for linux-amd64, linux-arm, darwin-amd64, and darwin-arm. When using gccgo it is implemented for any supported target.

- Go code as a shared library plugin with a Go style API

This is not implemented in the Go 1.5 release.

- Go code that uses a shared library plugin

This is not implemented in the Go 1.5 release.

- Building Go packages as a shared library

In the Go 1.5 release this is implemented for the linux-amd64 target only. When using gccgo it is implemented for any supported target.

- A Go program built as a PIE

This is not implemented in the Go 1.5 release.

Sounds like netgo is the default now? That is great -- no more having to remind people to use `-tags netgo`!

I'm very excited to see Go supported as a library for server and client development on iOS and Android. Are there any good case studies of app developers using Go as a full-stack language?

> Are there any good case studies of app developers using Go as a full-stack language?

It's been done, but the best use I'm aware of is under NDA.

Was it a joke when one of the core team guys said that he was looking forward to seeing the go compiler in the go standard library?

Is the compiler go gettable?

You mean go/types?

No, it's not. I don't believe there are any plans to put it into the standard library either. It's a standard tool, not a library.

lol... Just built 1.4.2 (or whatever latest 1.4 was) last night. I was wondering whether or not to go against master. I wonder if there were even any commits since then or just a tag.

Wow still no generics even after so many people asking for them

cool, looking forward to testing it out.

Still no user-definable generics? ;)

Trolling is a art.

Actually it's a sincere criticism.

We all know that generics are not coming any time soon. The debate is over, it isn't sincere.

That doesn't change the fact that the lack of user-defined generics is a valid (and sincere) criticism.

Reply on news.ycombinator.com