Go 1.15 – Draft release notes | Hacker News Reader

Go 1.15 – Draft release notes

tip.golang.org

119 pointsazhenley38 comments

This article [1] describes the features in 1.15. The new linker is quite impressive in reducing executable size because it reduces more unused code:

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/

Ah I hadn't realized that he had retired! I assumed he'd still been working on golang.

Here is more on how they reduced the binary sizes: https://twitter.com/bradfitz/status/1256350305739915265

> Mostly https://go-review.googlesource.com/c/go/+/230544 and also https://go-review.googlesource.com/c/go/+/231397and lesser misc stuff like https://go-review.googlesource.com/c/go/+/228111

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).

I wonder how this will affect wasm targets. I’ve had relatively few errors when using a Golang wasm but depending on the project they wind up being massive!

I also hate having to serve a separate js file to simuLate the Golang runtime which probably isn’t going away but smaller and more efficient would be a marked improvement!

For reference https://github.com/golang/go/wiki/WebAssembly

Yes, it will be interesting how GC/runtime languages get along with WebAssembly in the future.

At the moment everything I saw looked rather bleak.

Did you have a look at https://tinygo.org/webassembly/ ?

I have! Given the compatibility of tiny go with community packages this isn’t ideal.

I think if I was using this I would be building from scratch in which case I would just use rust.

I despise Google Groups on mobile, as it usually requires me to log into my Google account. For those of you like me, the release notes[0] are easy to read in my phone.

[0] https://tip.golang.org/doc/go1.15

Mods, can we get the link updated to the actual release notes? https://tip.golang.org/doc/go1.15

Ok, changed from https://groups.google.com/d/msg/golang-announce/A0frTIl9W6Y/....

The GOPROXY API being either , or | makes me a tiny bit sad. Now, what was once simple, has given these characters new and not easily discernible semantic meaning. I really wish I had commented on this proposal but missed it until the feature was already in.

What would propose as an alternative? Even if it's too late for this particular thing, I'm curious anyway as there are similar problems that crop up here and there at $dayhob

Has there been any announced timeline on Go2?

I know one needs to refrain from being sarcastic here, but LOL. "Go2" is the typical exemple of an idea parking. It is not going to happen.

That's simply not true.

It was true for error handling improvements, which got added is just a small part of the original proposal.

And despite the 2nd attempt to the contracts proposal (now one year old with little visible progress, no updates since August on public git), or the Featherweight Go presented last week, there is still no guarantee that any of that will ever land on Go.

As a person who uses Go i don't need day by day updates to know that the Go team is working hard on generics. I trust that they are & indeed they are.

> now one year old with little visible progress, no updates since August on public git.

This is untrue.

In January this year the Go team wrote[1]; "Module support is in good shape and getting better with each day, and we are also making progress on the generics front (more on that later this year)."

If you looked at the draft/experimental[2] branch where generics development has been taking place, you can see that it has had activity as late as just last week.

In the featherweightGo presentation, Phil Wadler said Rob Pike wrote to him asking if he would be interested in working with the Go team so that they can figure out generics and try and get them right. And that is how featherweightGo came to be.

So a lot has/is been happening.

1. https://blog.golang.org/go1.15-proposals

2. https://go-review.googlesource.com/c/go/+/187317

3. https://youtu.be/Dq0WFigax_c

I stand corrected regarding the git updates.

As for the rest, it still has every chance to be shot down at last minute like it happened with the error proposal, regardless of what gets done.

The error proposal wasn't "shot down at the last minute". That is an entirely unfair and disinguous take on the matter.

So what is the fair way to address the community refusal and consequent introduction of a set of functions that achieve a subset of the initial proposal?

the error proposal was shutdown because the community rejected it due to the try function ergonomics sucking and not providing enough value.

the rest of the proposal went through just fine.

So who is to say that generics won't suffer the same fate?

current proposal might, but generics provide far more value than the try function from the errors proposal. they won't just stop attempting to figure it out.

> current proposal might, but generics provide far more value than the try function from the errors proposal. they won't just stop attempting to figure it out.

It doesn't matter how hard anybody tries when a vocal community rejects any attempt at changing Go type system.

What significant syntax or type system change has been implemented in Go for the last 5 years? alias, which was rather minor and a demand from googlers themselves. modules? this isn't a syntax or type system change. There won't be any syntax or type system change ever. Because it should have been done 10 years ago when the language was still new. It is now held hostage by a very conservative community for which no change will be good enough to be justified, that's simply the truth. Look at the facts, you can't deny them.

You are right and wrong at the same time. Go2 isn't a planned release, but stands for a possibly incompatible future revision of Go. A place, where new features can be experimented with. But any feature planned for "Go2", which turns out to not be incompatible with the Go1 compatibility promises, might just be merged into the Go mainline at a new dot release. So it is not clear, that or if when, a "Go2" release is going to happen. On the other side, new features are constantly added to the language from the "Go2" development, so in a sense part of it is already there.

Yeah, there's been a few plans announced:

https://blog.golang.org/go2-here-we-come

https://blog.golang.org/go2draft

https://blog.golang.org/go2-next-steps

Hm maybe I'll just have to write it as a Haskell eDSL. Should be straightforward and you get a better RTS & generics for free.

The decision at the moment is that while there may be backwards-incompatible language changes, referred to with the go2 label, Go is not planning to ever release a backwards-incompatible compiler. That means code written today will always be able to be imported by and linked against future Go programs, but there may be future language features you can't use without explicitly opting in. The go module system also has a way to declare language version, although it doesn't do anything right now.

Tangentially-related: does anybody know the status of go plugins? IIRC, only Linux and Darwin are supported, but is this a permanent state of affaires? Does the Go team intend to further develop this (e.g adding support for BSD and Win)?

I hope one day they will fix the reflect.StructOf.

Reply on news.ycombinator.com