Some other minor improvements that made my shortlist:
> On a Unix system, if the kill command or kill system call is used to send a SIGSEGV, SIGBUS, or SIGFPE signal to a Go program, and if the signal is not being handled via os/signal.Notify, the Go program will now reliably crash with a stack trace. In earlier releases the behavior was unpredictable.
> Allocation of small objects now performs much better at high core counts, and has lower worst-case latency.
Plus some usability improvements to the flag lib. I’d love to see this get closer and closer to spf13’s, taking the best and most stable parts. I love spf13’s contributions to the Go community, and a lot of these ideas deserve to be in stdlib in my view.
Anyways, I love how each line item in these updates is a small and unambiguous step forward. There’s something very satisfying about tools that systematically get better with every release.
I was just measuring the size of Terraform earlier today--it's a program with 733 dependencies and it weighed in at 63 mb without stripping symbols or compressing when compiled with go 1.13. I was comparing it to our Python executable bundle that weighed in at 260mb with only 104 dependencies and had become too big to run in a lambda, and I found myself jealous of everyone who is fussing over their 10mb Go binaries. Anyway, I rebuilt Terraform and it's now I'm 6mb more jealous of everyone fussing over their Go binary sizes.
EDIT: If I compress the Terraform binary and the Python lambda, they become 14mb and 250mb respectively. At least Python is fast, right?
I noticed your sarcasm there re: python being fast.
Many of my company's tools have been moved from python to go for both speed and size reasons, as well as because it's much easier to distribute. Even python exec bundles can have significant problems on random workstations, yet the go tools always just work.
Yeah, I have considerable experience with Go and Python, and my experience with Go has been consistently positive for all of the problems we're facing with Python; however, my org is not interested in considering other languages presumably because of the beliefs that it will take years to come up to speed on a new language and even then a statically typed language will be inherently slower to iterate with than a dynamically typed language (these assumptions are probably overfit to senior engineers' experiences with C++/Java in college or early in their careers).
For more realistic programs, binary sizes go down by 3.5% or as much as 22%.
The original linker was written by Ken Thompson, who is now retired.
[1] https://lwn.net/Articles/820217/