Go 1.11 released(golang.org) |
Go 1.11 released(golang.org) |
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.
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)
Thank you very much!
considering it includes the runtime, this isn't a large file compared to images / videos you find on the web today
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 ...
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.
https://github.com/golang/go/issues/26775
A new person on the compiler might be working on that too as a warm-up task.
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.
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.
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 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...
"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."
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.
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.
Most exciting thing [which isn't really a thing] is that they've reserved RISC-V GOARCH values!!!!!!!!!!!! Looking forward to RISC-V everywhere!
Thanks everyone at golang.
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.
----
Yes, it is easy to forget that we use vendoring to get around these issues (and for other reasons).
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.
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?