7 ms·

Go 1.11 released

238 points by soroso 8y ago

mathnode 8y ago
Release notes > binaries; https://golang.org/doc/go1.11 https://golang.org/doc/go1.11 Thanks everyone at golang.
- sctb 8y ago
  Thanks! Updated from https://golang.org/dl/#go1.11 https://golang.org/dl/#go1.11.
deleted 8y ago
[deleted]
dlojudice 8y ago
"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
- rounce 8y ago
  Or even some JS bundle sizes.
- bradfitz 8y ago
  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 8y ago
    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 ...
  - kodablah 8y ago
    > generate multiple WebAssembly output modules, perhaps one per Go package With Go disallowing circular package refs and WASM support for func imports this should be doable. However, they'll all essentially have to share a single imported memory instance, so there'll be some central runtime heap coordination which is plenty reasonable.
  - iamgopal 8y ago
    May be they can host all built in module to provide caching.
- MatthewPhillips 8y ago
  Images and videos are less important though.
- xienze 8y ago
  That sounds to me like the size of Hello World. Start including more and more of the runtime and it’ll get quite a bit bigger, much the same as native Go binaries.
  - kodablah 8y ago
    IIRC, hello world that uses println is actually smaller. It's once you import fmt and unicode directly or indirectly (most libs) where those reported sizes start from.
  - bradfitz 8y ago
    It grows but not super fast. Like the other comment said, once you include the runtime and Unicode tables, that's a fair bit of it.
- kodablah 8y ago
  I still think it's too big and look forward to size reduction. One of the things I found was also a bit heavy is init with tens of thousands of instructions to initialize the unicode package with those dozens of structs.
  - bradfitz 8y ago
    init-time load has become a pet project of mine lately: https://github.com/golang/go/issues/26775 https://github.com/golang/go/issues/26775 A new person on the compiler might be working on that too as a warm-up task.
    - kodablah 8y ago
      Nice. Looking at what's exposed in the unicode package (did a tad bit of research [0]), there may be limited opportunities to reduce that since the structs are exposed. Maybe fewer goroutine suspend points between cpu-only tasks inside init, I dunno, not very familiar. Maybe a bunch of structs initialized with only const exprs in their fields could be eval'd at compile time and become a data section in the binary (until mutated maybe or just copied from the data section since there're no public immutable vars). 0 - https://github.com/golang/go/issues/26622 https://github.com/golang/go/issues/26622
- adamnemecek 8y ago
  You can’t compare images with code. 500kb is a ton of code.
  - codycraven 8y ago
    You're right, but 500kb of Wasm is nowhere near as bad as 500kb of JS.
- e3b0c 8y ago
  Now that the binary size issue has finally come into the spotlight thanks to the WebAssembly, hopefully, embedded devs could benefit from the future efforts of size reduction too.
Sileni 8y ago
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.
alexandernst 8y ago
Finally the entire GOPATH nonsense is going away...
- weberc2 8y ago
  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 8y ago
    > 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.
    - GeertJohan 8y ago
      > can't just write `import "./util"`. Afaik thats actually possible. Or at least it was for a while. But there are good reasons why you shouldnt.
      - rqs 8y ago
        > But there are good reasons why you shouldn't. Wonder why, care to explain?
    - cpuguy83 8y ago
      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.
0xmohit 8y ago
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 8y ago
  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/
gaddferreira 8y ago
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.
- deleted 8y ago
  [deleted]
bradfitz 8y ago
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 8y ago
  Any benchmarks yet?
  - bradfitz 8y ago
    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.
lsllc 8y ago
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!
bradfitz 8y ago
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/1EwuJhEHR5Trr2aXBPQajZ2Hcoh29tm_LQCpgfrCnuRk/view#slide=id.g33148270ac_0_143 https://docs.google.com/presentation/d/1EwuJhEHR5Trr2aXBPQaj... (See speaker notes for more context)
- tandr 8y ago
  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 8y ago
    Nope, sorry. I guess you can read it from home or on your phone if you employer doesn't trust you. :)
  - kristianp 8y ago
    You can export it as a powerpoint (for example) at home, and send it to work.
int_19h 8y ago
> 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 8y ago
  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 8y ago
    Good to see this getting fixed for macOS; but then why not on BSD as well?

Go 1.11 released

238 points by soroso 8y ago

mathnode 8y ago

Release notes > binaries; https://golang.org/doc/go1.11 https://golang.org/doc/go1.11 Thanks everyone at golang.

sctb 8y ago
Thanks! Updated from https://golang.org/dl/#go1.11 https://golang.org/dl/#go1.11.

deleted 8y ago

[deleted]

dlojudice 8y ago

"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

rounce 8y ago
Or even some JS bundle sizes.
bradfitz 8y ago
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 8y ago
  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 ...
- kodablah 8y ago
  > generate multiple WebAssembly output modules, perhaps one per Go package With Go disallowing circular package refs and WASM support for func imports this should be doable. However, they'll all essentially have to share a single imported memory instance, so there'll be some central runtime heap coordination which is plenty reasonable.
- iamgopal 8y ago
  May be they can host all built in module to provide caching.
MatthewPhillips 8y ago
Images and videos are less important though.
xienze 8y ago
That sounds to me like the size of Hello World. Start including more and more of the runtime and it’ll get quite a bit bigger, much the same as native Go binaries.
- kodablah 8y ago
  IIRC, hello world that uses println is actually smaller. It's once you import fmt and unicode directly or indirectly (most libs) where those reported sizes start from.
- bradfitz 8y ago
  It grows but not super fast. Like the other comment said, once you include the runtime and Unicode tables, that's a fair bit of it.
kodablah 8y ago
I still think it's too big and look forward to size reduction. One of the things I found was also a bit heavy is init with tens of thousands of instructions to initialize the unicode package with those dozens of structs.
- bradfitz 8y ago
  init-time load has become a pet project of mine lately: https://github.com/golang/go/issues/26775 https://github.com/golang/go/issues/26775 A new person on the compiler might be working on that too as a warm-up task.
  - kodablah 8y ago
    Nice. Looking at what's exposed in the unicode package (did a tad bit of research [0]), there may be limited opportunities to reduce that since the structs are exposed. Maybe fewer goroutine suspend points between cpu-only tasks inside init, I dunno, not very familiar. Maybe a bunch of structs initialized with only const exprs in their fields could be eval'd at compile time and become a data section in the binary (until mutated maybe or just copied from the data section since there're no public immutable vars). 0 - https://github.com/golang/go/issues/26622 https://github.com/golang/go/issues/26622
adamnemecek 8y ago
You can’t compare images with code. 500kb is a ton of code.
- codycraven 8y ago
  You're right, but 500kb of Wasm is nowhere near as bad as 500kb of JS.
e3b0c 8y ago
Now that the binary size issue has finally come into the spotlight thanks to the WebAssembly, hopefully, embedded devs could benefit from the future efforts of size reduction too.

Sileni 8y ago

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.

alexandernst 8y ago

Finally the entire GOPATH nonsense is going away...

weberc2 8y ago
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 8y ago
  > 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.
  - GeertJohan 8y ago
    > can't just write `import "./util"`. Afaik thats actually possible. Or at least it was for a while. But there are good reasons why you shouldnt.
    - rqs 8y ago
      > But there are good reasons why you shouldn't. Wonder why, care to explain?
  - cpuguy83 8y ago
    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.

0xmohit 8y ago

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 8y ago
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/

gaddferreira 8y ago

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.

deleted 8y ago
[deleted]

bradfitz 8y ago

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 8y ago
Any benchmarks yet?
- bradfitz 8y ago
  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.

lsllc 8y ago

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!

bradfitz 8y ago

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/1EwuJhEHR5Trr2aXBPQajZ2Hcoh29tm_LQCpgfrCnuRk/view#slide=id.g33148270ac_0_143 https://docs.google.com/presentation/d/1EwuJhEHR5Trr2aXBPQaj... (See speaker notes for more context)

tandr 8y ago
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 8y ago
  Nope, sorry. I guess you can read it from home or on your phone if you employer doesn't trust you. :)
- kristianp 8y ago
  You can export it as a powerpoint (for example) at home, and send it to work.

int_19h 8y ago

> 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 8y ago
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 8y ago
  Good to see this getting fixed for macOS; but then why not on BSD as well?