
Go 1.15 – Draft release notes - azhenley
https://tip.golang.org/doc/go1.15
======
CalmStorm
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/](https://lwn.net/Articles/820217/)

~~~
weberc2
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?

~~~
fimbulvetr
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.

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

------
rudolph9
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!

~~~
PhilippGille
Did you have a look at
[https://tinygo.org/webassembly/](https://tinygo.org/webassembly/) ?

~~~
rudolph9
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.

------
conroy
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](https://tip.golang.org/doc/go1.15)

~~~
CGamesPlay
Mods, can we get the link updated to the actual release notes?
[https://tip.golang.org/doc/go1.15](https://tip.golang.org/doc/go1.15)

~~~
dang
Ok, changed from [https://groups.google.com/d/msg/golang-
announce/A0frTIl9W6Y/...](https://groups.google.com/d/msg/golang-
announce/A0frTIl9W6Y/mTgsOVCnAQAJ).

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

~~~
ithkuil
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

------
totalperspectiv
Has there been any announced timeline on Go2?

~~~
throw_m239339
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.

~~~
mseepgood
That's simply not true.

~~~
pjmlp
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.

~~~
RabbitmqGuy
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](https://blog.golang.org/go1.15-proposals)

2\. [https://go-review.googlesource.com/c/go/+/187317](https://go-
review.googlesource.com/c/go/+/187317)

3\. [https://youtu.be/Dq0WFigax_c](https://youtu.be/Dq0WFigax_c)

~~~
pjmlp
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.

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

~~~
pjmlp
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?

~~~
jatone
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.

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

~~~
jatone
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.

~~~
throw_m239339
> 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.

------
omginternets
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)?

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

