Live data from Hacker News

Go 1.11 released

golang.org

21–30 of 51 posts

Re: Go 1.11 released

#21

"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

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.

Re: Go 1.11 released

#22
post #18

"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

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.

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.

Re: Go 1.11 released

#23

"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

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.

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

Re: Go 1.11 released

#24
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

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

Re: Go 1.11 released

#25

"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

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.

init-time load has become a pet project of mine lately:

https://github.com/golang/go/issues/26775

A new person on the compiler might be working on that too as a warm-up task.

Re: Go 1.11 released

#26

Earlier quoted context omitted.

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.

init-time load has become a pet project of mine lately: https://github.com/golang/go/issues/26775 A new person on the compiler might be working on that too as a warm-up task.

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

Re: Go 1.11 released

#27

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]

Re: Go 1.11 released

#28

"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

You can’t compare images with code. 500kb is a ton of code.

Re: Go 1.11 released

#29
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!

Re: Go 1.11 released

#30
post #9

Earlier quoted context omitted.

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.

> 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 w…

I vaguely recall wanting relative imports back when I first started dabbling with Go. Then I moved on and really have completely forgotten it was an issue.

If you want to fork a project, I'm pretty sure there's a program (gorename maybe?) that rewrites these import paths for you, but I've always just used `sed`.

I haven't used Elm, but Node's `node_modules` folder has always been a hassle. Grepping for anything is a pain, and regularly the directory seemed to just get borked so you'd have to `rm -rf $(find . -name node_modules) && npm install`. I don't want to overstate this problem; Node wasn't what I had in mind when I was thinking of difficult project conventions.

Post reply on HN