
Go 1.11 released - soroso
https://golang.org/doc/go1.11
======
bradfitz
One of the other exciting things in this release is the almost entirely
rewritten "prove" pass in the compiler:

[https://golang.org/doc/go1.11#performance-
compiler](https://golang.org/doc/go1.11#performance-compiler)

> The compiler now performs significantly more aggressive bounds-check and
> branch elimination. Notably, it now recognizes transitive relations, so if
> i<j and j<len(s), it can use these facts to eliminate the bounds check for
> s[i]. It also understands simple arithmetic such as s[i-10] and can
> recognize more inductive cases in loops. Furthermore, the compiler now uses
> bounds information to more aggressively optimize shift operations.

~~~
weberc2
Any benchmarks yet?

~~~
bradfitz
Generally faster.

[https://golang.org/doc/go1.11#performance](https://golang.org/doc/go1.11#performance)

Depends what you measure. Some parts if you microbenchmark them are 10x
faster, or much more.

------
bradfitz
Of possible interest, I gave a talk about "Go 1.11 & Beyond" (read: "Go 2") a
couple weeks ago:

[https://docs.google.com/presentation/d/1EwuJhEHR5Trr2aXBPQaj...](https://docs.google.com/presentation/d/1EwuJhEHR5Trr2aXBPQajZ2Hcoh29tm_LQCpgfrCnuRk/view#slide=id.g33148270ac_0_143)

(See speaker notes for more context)

~~~
tandr
Brad, is this presentation available anywhere else (say, exported to PDF)? Our
company blocks all sharing sites, so docs.google.com is no go for me (and I
cannot reshare it with my team). Would it be possible for you to drop it on
golang.org somewhere?

Thank you very much!

~~~
bradfitz
Nope, sorry. I guess you can read it from home or on your phone if you
employer doesn't trust you. :)

------
dlojudice
"Go programs currently compile to one WebAssembly module that includes the Go
runtime for goroutine scheduling, garbage collection, maps, etc. As a result,
the resulting size is at minimum around 2 MB, or 500 KB compressed."

considering it includes the runtime, this isn't a large file compared to
images / videos you find on the web today

~~~
bradfitz
And this is temporary. In the future we should be able to both do better size-
wise & also to generate multiple WebAssembly output modules, perhaps one per
Go package, to enable better (more fine-grained) caching.

~~~
bradrydzewski
I really enjoyed following the WASM CLs. A huge effort from both neelance and
the reviewers. Thanks to everyone that donated their time to make this happen!

If the compiler output is deterministic perhaps the Go runtime and Go standard
libraries could be bundled as modules, allowing for aggressive cache policies.
Maybe even served from a central CDN. Just a thought ...

------
gaddferreira
Go does a lot of things right without having to carry legacy mistakes like
other languages, it's such a breath of fresh air in a landscape of constant
change and competing implementations.

I'm very optimistic that the modules system is another step in the right
direction, however long it took to get here. Thanks everyone working on Go.

------
0xmohit
As listed on the blog page -
[https://blog.golang.org/go1.11](https://blog.golang.org/go1.11) \- two
exciting features are modules and WebAssembly support.

Information about modules can be found at:

\- [https://golang.org/cmd/go/#hdr-
Preliminary_module_support](https://golang.org/cmd/go/#hdr-
Preliminary_module_support)

\-
[https://github.com/golang/go/wiki/Modules](https://github.com/golang/go/wiki/Modules)

\- [https://research.swtch.com/vgo](https://research.swtch.com/vgo)

The wiki -
[https://golang.org/wiki/WebAssembly](https://golang.org/wiki/WebAssembly) \-
provides information on how to get started with using Wasm with Go.

~~~
otagaram
There's also this great tutorial[0] that has been making the rounds these last
couple of weeks.

[0] [https://roberto.selbach.ca/intro-to-go-
modules/](https://roberto.selbach.ca/intro-to-go-modules/)

------
int_19h
> Go 1.11 supports the upcoming OpenBSD 6.4 release. Due to changes in the
> OpenBSD kernel, older versions of Go will not work on OpenBSD 6.4.

I wonder when Go is planning to stop using the kernel ABI on BSDs and macOS
directly - in direct contradiction to stability guarantees (or lack thereof)
by those platforms - and start using the appropriate APIs, such as libc. Or is
it going to be stuff like this or
[https://github.com/golang/go/issues/16606](https://github.com/golang/go/issues/16606)
forever? Right now, I stay away from Go partly because of this - it feels like
a bad idea to use a software stack that is guaranteed to be broken on future
OS releases by design. Especially when that stack is advertised specifically
for system programming...

~~~
mseepgood
[https://golang.org/doc/go1.11#runtime](https://golang.org/doc/go1.11#runtime)

"On macOS and iOS, the runtime now uses libSystem.so instead of calling the
kernel directly. This should make Go binaries more compatible with future
versions of macOS and iOS."

~~~
int_19h
Good to see this getting fixed for macOS; but then why not on BSD as well?

------
alexandernst
Finally the entire GOPATH nonsense is going away...

~~~
weberc2
Eh, it wasn’t the best, but it was still better than any other language’s
equivalent except for Rust’s. In any case, modules have worked wonderfully for
me so far.

~~~
always_good
> but it was still better than any other language’s equivalent except for
> Rust’s

I'd say almost any language with project-specific deps folder (e.g. Node, Elm)
are better than GOPATH and its module system.

For example, can't just write `import "./util"`. It needs to be fully
qualified, every import depending on full project fs hierarchy including even
the project user/name on github. This is hilarious when you just want to fork
a project from github and get it running.

~~~
cpuguy83
You can write `import "./util"`

Also, it's really not that bad considering that go works (`go get` grabs git
repo) with git repos. So you can go into your GOPATH (or vendor dir) and
checkout your fork in place of the origin. In the end, a little pain to get
started to get used to it, then it's second nature.... but I suppose if you
primarily work in other languages it is likely tiresome.

~~~
always_good
All three replies to me suggest that you can do relative imports in Go.

Can you link me to documentation that demonstrates them?

I don't understand. Either relative imports are not supported or they only
work in some context that nobody uses. BTW I'm not a Go beginner, and my
issues with Go aren't just an issue with "getting started" as you suggested.

I just tried them in an existing Go project and I get the usual "can't load
package" error.

Two random links:

\- [https://stackoverflow.com/questions/38517593/relative-
import...](https://stackoverflow.com/questions/38517593/relative-imports-in-
go) "No there is no relative import in Golang."

\-
[https://github.com/golang/go/issues/20883](https://github.com/golang/go/issues/20883)
"Support relative imports in Go 2.0"

> So you can go into your GOPATH (or vendor dir) and checkout your fork in
> place of the origin

Imagine the real-world case where you're working on more than one project at a
time. Project X and Project Y both depend on a Util project on GOPATH, but
they require different versions of Util.

Each time you switch projects, you cd into GOPATH and check out the right
version of Util?

I'm sure this stuff works for a megarepo like the one Google has. But for the
rest of us, this stuff was solved by package managers. A lesson Go ended up
having to learn in the end.

~~~
cpuguy83
Relative imports work, but keep in mind the import works based on package
name. So "import ./foo", you must have a package called "foo" in "./foo"

\----

Yes, it is easy to forget that we use vendoring to get around these issues
(and for other reasons).

------
lsllc
Congrats & thanks to the Go team! I'm a big fan of Go and use it extensively.

Most exciting thing [which isn't really a thing] is that they've reserved
RISC-V GOARCH values!!!!!!!!!!!! Looking forward to RISC-V everywhere!

------
Sileni
Modules release is definitely a "we told you so" moment. Depending on outside
packages has always bothered me, and kept me from doing more with the
language.

------
mathnode
Release notes > binaries;

[https://golang.org/doc/go1.11](https://golang.org/doc/go1.11)

Thanks everyone at golang.

~~~
sctb
Thanks! Updated from
[https://golang.org/dl/#go1.11](https://golang.org/dl/#go1.11).

