31–40 of 51 posts
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…
"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.
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…
Any benchmarks yet?
https://golang.org/doc/go1.11#performance
Depends what you measure. Some parts if you microbenchmark them are 10x faster, or much more.
https://docs.google.com/presentation/d/1EwuJhEHR5Trr2aXBPQaj...
(See speaker notes for more context)
As listed on the blog page - 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://github.com/golang/go/wiki/Modules - https://research.swtch.com/vgo The wiki - https://golang.org/wiki/WebAssembly - provides information on how to get started with using Wasm with Go.
Earlier 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…
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.
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... "No there is no relative import in Golang."
- 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.
"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.
"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
Earlier 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…
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…
Finally the entire GOPATH nonsense is going away...
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.
I disagree. Gopath was the most brain-dead idea being implemented in a current programming language. It handled the problem in a far worse manner than any other programming language in current use. This problem was then made far worse by the way the language developers insisted in forcing it upon go users in spite of all the repeated compains.