
Go 1.11 Rc1 released - soroso
https://golang.org/dl/go1.11rc1
======
benesch
Release notes are available at:
[https://tip.golang.org/doc/go1.11](https://tip.golang.org/doc/go1.11)

Headline features (as judged by me) are:

* A new WebAssembly backend, js/wasm, for the gc compiler.

* Preliminary support for modules, i.e., the first step towards a package manager built into the Go command.

* Improved support for debuggers, especially Delve.

* Removal of many direct system calls from the macOS runtime. Unlike on Linux, the macOS system call interface is not considered stable. Go 1.11 binaries are now less likely to break when you upgrade your macOS version because system calls are made through the proper channel (libc).

------
kjeetgill
To get a test of what's actually in the release candidate check out
[https://github.com/golang/go/milestone/62](https://github.com/golang/go/milestone/62)

A lot of new stuff with the new go modules work including vgo and some
interesting wasm work.

------
chx
Extremely relevant: We need to talk about Go modules
[https://www.youtube.com/watch?v=7GGr3S41gjM](https://www.youtube.com/watch?v=7GGr3S41gjM)

------
agnivade
There has been some tremendous improvements for ARM architecture. If you run
some serious code on raspberry PIs, get ready to be amazed.

~~~
imrehg
I skimmed the release notes, and only a little mention there ARM specific
changes, can you elaborate on what tremendous improvements are made? Very
curious!

~~~
agnivade
Yes, the release notes are a bit humble about it.

Specifically, optimized assembly instructions are used now in crypto code and
also lot of optimizations have gone into the ARM assembler.

One example -
[https://gist.github.com/carlosedp/f85274ef2a9bacc773cf8ddeed...](https://gist.github.com/carlosedp/f85274ef2a9bacc773cf8ddeedaee821).

------
vesak
What is the current recommendation for dependency management in Go for a new
project?

~~~
azhenley
dep was the tool I used. There are a few other solutions but this one was most
popular when I last looked.

[https://github.com/golang/dep](https://github.com/golang/dep)

------
shawn
Go is still one of the most difficult and counter intuitive build systems ever
devised. Usually you’d expect a project to build out of the box. Go seems to
take a stance of “Haha nope, get ready to figure out which version of the
standard library this 4 month old project was written against, then have fun
trying to update it to the latest.”

I like the language though. Their green threads are still the best.

~~~
irfansharif
From Go's 1.0 compatibility guarantee[0]:

> It is intended that programs written to the Go 1 specification will continue
> to compile and run correctly, unchanged, over the lifetime of that
> specification. [...] Go programs that work today should continue to work
> even as future "point" releases of Go 1 arise (Go 1.1, Go 1.2, etc.).

I've found this to be upheld in practice, especially so for the standard
library. I have yet to come across a case where I was concerned with which
"version" of the standard library some project was written against. Are you
perhaps talking about non-stdlib packages?

[0]: [https://golang.org/doc/go1compat](https://golang.org/doc/go1compat)

~~~
ovao
My experience has been the same, so it’s hard to understand where shawn is
coming from. There have been impressively few breaking changes to the Go
standard library since 1.0.

Even when bringing in a number of third-party packages, the only trouble I’ve
had building Go projects has been in Windows (which is often treated by
Gophers as a second-class platform).

