"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
Go 1.11 released
11–20 of 51 posts
Re: Go 1.11 released
#12"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
Re: Go 1.11 released
#13Earlier 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…
Afaik thats actually possible. Or at least it was for a while. But there are good reasons why you shouldnt.
Re: Go 1.11 released
#14Earlier quoted context omitted.
> 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…
> 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.
Wonder why, care to explain?
Re: Go 1.11 released
#15Earlier 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…
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.
Re: Go 1.11 released
#16"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
Re: Go 1.11 released
#17"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.
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 ...
Re: Go 1.11 released
#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
Re: Go 1.11 released
#19Finally the entire GOPATH nonsense is going away...
Re: Go 1.11 released
#20I'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.