* A new WebAssembly backend, js/wasm, for the gc compiler.
* Preliminary support for modules, i.e., the first step towards a package manager built into the Go command.
* Improved support for debuggers, especially Delve.
* Removal of many direct system calls from the macOS runtime. Unlike on Linux, the macOS system call interface is not considered stable. Go 1.11 binaries are now less likely to break when you upgrade your macOS version because system calls are made through the proper channel (libc).
Go is still one of the most difficult and counter intuitive build systems ever devised. Usually you’d expect a project to build out of the box. Go seems to take a stance of “Haha nope, get ready to figure out which version of the standard library this 4 month old project was written against, then have fun trying to update it to the latest.”
I like the language though. Their green threads are still the best.
> It is intended that programs written to the Go 1 specification will continue to compile and run correctly, unchanged, over the lifetime of that specification. [...] Go programs that work today should continue to work even as future "point" releases of Go 1 arise (Go 1.1, Go 1.2, etc.).
I've found this to be upheld in practice, especially so for the standard library. I have yet to come across a case where I was concerned with which "version" of the standard library some project was written against. Are you perhaps talking about non-stdlib packages?
My experience has been the same, so it’s hard to understand where shawn is coming from. There have been impressively few breaking changes to the Go standard library since 1.0.
Even when bringing in a number of third-party packages, the only trouble I’ve had building Go projects has been in Windows (which is often treated by Gophers as a second-class platform).
Try building this. I have no idea what's wrong with it, but it doesn't work. It's cool tech, I want it, but I don't want to immerse myself in the world of hurt^WGo just to get it.
in fairness, Java has an excuse that it’s ancient in language terms and expectations were different then.
Go, not so much - it came out in 2012. Pip and CPAN and Gem had been around for years. Go’s lack of a sane packaging solution this far into its lifetime remains a serious weakness of an otherwise solid platform.
One could argue that golang is a solid platform because they focused on the platform first, instead of the package management. It is all about priorities.
The `go get` command was never marketed as a versioned package management tool. `go get` also works just fine if you point it at forked repositories that you control.
I skimmed the release notes, and only a little mention there ARM specific changes, can you elaborate on what tremendous improvements are made? Very curious!
28 comments
[ 3.7 ms ] story [ 66.8 ms ] threadHeadline features (as judged by me) are:
* A new WebAssembly backend, js/wasm, for the gc compiler.
* Preliminary support for modules, i.e., the first step towards a package manager built into the Go command.
* Improved support for debuggers, especially Delve.
* Removal of many direct system calls from the macOS runtime. Unlike on Linux, the macOS system call interface is not considered stable. Go 1.11 binaries are now less likely to break when you upgrade your macOS version because system calls are made through the proper channel (libc).
A lot of new stuff with the new go modules work including vgo and some interesting wasm work.
I like the language though. Their green threads are still the best.
I'm currently working on building all the coreclr/corefx repos for .NET Core. Their build system is incredibly convoluted.
> It is intended that programs written to the Go 1 specification will continue to compile and run correctly, unchanged, over the lifetime of that specification. [...] Go programs that work today should continue to work even as future "point" releases of Go 1 arise (Go 1.1, Go 1.2, etc.).
I've found this to be upheld in practice, especially so for the standard library. I have yet to come across a case where I was concerned with which "version" of the standard library some project was written against. Are you perhaps talking about non-stdlib packages?
[0]: https://golang.org/doc/go1compat
Even when bringing in a number of third-party packages, the only trouble I’ve had building Go projects has been in Windows (which is often treated by Gophers as a second-class platform).
Look, maybe the stdlib is rock solid. But every time I try to build a Go project, `go build` finds ten ways not to work.
Case in point: https://github.com/cretz/tor-dht-poc
Try building this. I have no idea what's wrong with it, but it doesn't work. It's cool tech, I want it, but I don't want to immerse myself in the world of hurt^WGo just to get it.
I did however at least attempt to fix the problem: https://github.com/cretz/tor-dht-poc/pull/2
Fortunately that's changing.
Go, not so much - it came out in 2012. Pip and CPAN and Gem had been around for years. Go’s lack of a sane packaging solution this far into its lifetime remains a serious weakness of an otherwise solid platform.
Because the Go team kept pushing the ridiculous idea that versioning doesn't matter.
> `go get` also works just fine if you point it at forked repositories that you control.
And at that point, what value does `go get` add?
Specifically, optimized assembly instructions are used now in crypto code and also lot of optimizations have gone into the ARM assembler.
One example - https://gist.github.com/carlosedp/f85274ef2a9bacc773cf8ddeed....
https://github.com/golang/dep