15 ms·
Go 1.10 Release Notes
- 0xmohit 9y agoRelease notes: https://golang.org/doc/go1.10 https://golang.org/doc/go1.10
- dang 9y agoWe've changed to that URL from https://blog.golang.org/go1.10 https://blog.golang.org/go1.10.
- lobster_johnson 9y agoMaybe merge with this: https://news.ycombinator.com/item?id=16395607 https://news.ycombinator.com/item?id=16395607
- dang 9y agoThanks! Done.
- danielvf 9y ago> "If the environment variable $GOROOT is unset, the go tool previously used the default GOROOT set during toolchain compilation. Now, before falling back to that default, the go tool attempts to deduce GOROOT from its own executable path. This allows binary distributions to be unpacked anywhere in the file system and then be used without setting GOROOT explicitly." At last! Yes!
- xiaq 9y agoOne thing not mentioned in the release note is that the plugin package now supports macOS: https://godoc.org/plugin https://godoc.org/plugin Also, "[this package] has known issues" was removed from the doc.
- badrequest 9y agoI don't know why they left it out, it's the best news I could have hoped for from 1.10. All this after I set up a semi-complicated series of make targets to compile these plugins in Docker containers and use volumes pipe them out.
- wahern 9y agoIt's buried in the release notes: Compiler Toolchain ... ... plugin now works on linux/ppc64le and darwin/amd64
- cube2222 9y agoBarely anybody uses them though.
- cweagans 9y agoThey were previously linux only. When Windows support lands, there's a lot we'll be able to do in our open source product in terms of modularity. It's a pretty big deal for us.
- deleted 9y ago[deleted]
- alexandernst 9y agoHave they fixed already the GOPATH crap?
- konart 9y ago>The GOPATH environment variable now has a default value if it is unset. It defaults to $HOME/go on Unix and %USERPROFILE%/go on Windows. If this is what you are talking about - they 'fixed' it in 1.8 a year ago.
- egeozcan 9y agoIMHO, fixing it would be being able to build go code on random directories without env hackery.
- gschier 9y agoI think this is on the roadmap but I'm not sure the priority. Check out this proposal https://gist.github.com/sdboyer/def9b138af448f39300cb078b0e94cc3 https://gist.github.com/sdboyer/def9b138af448f39300cb078b0e9... EDIT: Found the proposal on the dep roadmap: https://github.com/golang/dep/wiki/Roadmap https://github.com/golang/dep/wiki/Roadmap
- macrael 9y agoThey fixed compilation caching not to install in $GOPATH/pkg anymore which feels like a good step toward getting rid of it all together, eventually.
- xstartup 9y agoI am using Deps with Visual Studio Code. My project builds from any directory even if it's not in the GOPATH.
- teacpde 9y agoThe go test command now caches test results: if the test executable and command line match a previous run and the files and environment variables consulted by that run have not changed either, go test will print the previous test output, replacing the elapsed time with the string “(cached).” This is my favorite part of the release.
- kasey_junk 9y agoI don't understand the utility. Why am I running tests again if nothing has changed? Is this just to speed up multipackage testing use cases?
- ben_jones 9y agoI imagine if you're working on a project with 3 packages and only 1 package changed then the test will automatically skip the other 2 with no flags or changed command needed? Or perhaps if your working on one large package and only one file changed?
- kasey_junk 9y agoYes that’s my understanding.
- kjksf 9y agoAtom's Go integration re-runs tests after save to a .go file. It's very convenient because you can see test failures and test coverage changes immediately. But it's slow if you modified a file that is not involved in tested code paths. This is just one concrete example. In general when the code size grows, very quickly it becomes impossible to tell if a given edit could possibly affect tests or not. So you want to run `go test` just in case so making it faster is a good thing.
- kasey_junk 9y agoBut this isn’t doing ‘intelligent’ caching, just like go doesn’t do intelligent test checking. If the test binary changes (I think that implies basically any change in the package) the tests rerun.
- Rickasaurus 9y agoDoes it have generics yet?
- erik_seaberg 9y ago> There are no significant changes to the language specification. I'll continue hoping goderive becomes a language that displaces go.
- mirekrusin 9y agoGo++
- konart 9y agoNo, still isn't Java.
- O_H_E 9y agoAn honest question, why was the flagged?
- ordinaryradical 9y agoAs someone with no skin in the game, it seems to me that the philosophical conundrum of Go is whether one needs to use a language designed to produce the kind of code consistency it gives to Google-scale orgs or if you're better off working with a more "dangerous" or harder-to-read language which may create more technical debt but also allow you forge your own path as your devs prefer. I keep looking at languages like Go and frameworks like Angular as being steered for huge-org problems, but I wonder if startups are better off incurring the debt of riskier, less conservative languages and paradigms and worrying about the technical debt only once they've reached the scale where it a) actually matters to your agility in delivering customer value and b) you have the capital to make it worth solving the problem. Maybe this is reading too much into the generics kerfluffle, but I would love to be enlightened if anyone can clarify this further.
- kasey_junk 9y agoI don't have a strong opinion about your premise about large vs small orgs. But what I will say is that I largely dislike go as a language, yet I still usually pick it for solving problems even if they are just for myself. The reason for that is largely the 'come back to it' factor. I'm reasonably able to identify go code I wrote and put away. I can't say the same for other languages I've used professionally.
- stcredzero 9y agoIf you have enough irons in the fire, all of those different versions of "you" might qualify as a "large org," depending on your definitions of "large" and "org."
- gameswithgo 9y agoMy experience from a host of language experiments of late: ranging from F#, to Rust, to Nim, to C#, to Go, to C++ Is that it just doesn't matter very much. F# has very powerful generics, and there are particular circumstances where that saves me a lot of typing. But you can still get it done in C# with less powerful generics, or Go with none. F# has sum types, and replaces null with an option type - great ideas, but you can approximate these ideas in any language if you need to. Similarly, Nim's metaprogramming has let me do some really clever things, but again, it just saves some typing. I've found that language features and properties are often given more weight than they deserve. The really hard problems I've had when coding are just the actual problems. And while a particular language can be life-changing in particular problem domains, its rare that they are life changing in general. Go is maybe the language I think is least interesting of all of the ones I've played with but I currently prefer it over the others because 1. stable, mature language and tools (unlike nim) 2. fast compile times (unlike rust) 3. compiles to native executables F# might be my favorite if it had fast compile times and native compilation. Rust might be my favorite if I ever grok the borrow checker. But if someone said I had to use language X to do project Y I would almost always be fine with it, unless there were insurmountable performance problems caused by the language.
- nextstepguy 9y agoThere are no significant changes to the language specification This is my least favorite part of the release.
- gameswithgo 9y agoIt is already turing complete! :D
- mkromkamp 9y agoThis my most favorite part of this release ;).
- ValentineC 9y agoWould anyone be able to explain to me what this means (from the release notes [1])? > Go 1.10 is the last release that will run on OS X 10.8 Mountain Lion or OS X 10.9 Mavericks. Go 1.11 will require OS X 10.10 Yosemite or later. Would Go programs just not compile on those OS versions, or not run entirely? [1] https://golang.org/doc/go1.10 https://golang.org/doc/go1.10
- justincormack 9y agoNot run at all I think. Go is more strongly coupled to systems than most languages as it implements a lot itself, eg it directly uses the (non stable) syscall interface on osx.
- bradfitz 9y ago> Would Go programs just not compile on those OS versions, or not run entirely? It means we are not going to test on those old systems anymore, so we make no promises about either.
- felixfbecker 9y agoAlso, how is this not a breaking change? They talk so much about BC but cut minor releases that don't run on the same OS versions as the previous release? Same with FreeBSD: > As announced in the Go 1.9 release notes, Go 1.10 now requires FreeBSD 10.3 or later; support for FreeBSD 9.3 has been removed.
- discoursism 9y agoThis is what the Go 1 Promise has to say about operating systems. They very specifically call that out as an area where they do not guarantee compatibility. https://golang.org/doc/go1compat#operating_systems https://golang.org/doc/go1compat#operating_systems
- petre 9y agoFreeBSD 9 has been EOLed a while ago.
- karmakaze 9y ago
- old-gregg 9y agoQuickly tested it on our OSS repo [1] and based on several averaged runs, 1.10 is both faster to compile (even not taking caching into account) and produces smaller executables, a welcome reversal of the past trend. Compile times on Intel(R) Core(TM) i7-7820X CPU @ 3.60GHz: Go 1.9.2 7.2sec avg Go 1.10 6.1sec avg -15.3% Binary sizes: Go 1.9.2 50,727,552 bytes Go 1.10 49,604,128 bytes -2.2% [1] https://github.com/gravitational/teleport https://github.com/gravitational/teleport if you want to try it yourself, run `make clean` followed by `time make`
- gameswithgo 9y agoDo you executables run faster, or slower?
- lima 9y ago> Options specified by cgo using #cgo CFLAGS and the like are now checked against a whitelist of permitted options. This closes a security hole in which a downloaded package uses compiler options like -fplugin to run arbitrary code on the machine where it is being built. How strong is the guarantee of "no code execution during build"? I'm currently working on a Go build system and my understanding is that the Go compiler was designed for compiling untrusted code. You'd have to exploit the compiler on order to get RCE, right? (I'm sandboxing it either way, but it's good to know for risk assessment)
- kjksf 9y agoHere's how it works. `go build` on a pure Go code only executes the compiler and linker of the go toolchain. If you add cgo to the mix, `go build` might invoke system C++ compiler (gcc, clang, mingw) to compile the C part of the code and system C++ linker. The issue was that gcc allows arbitrary plugins and if the right cgo flags were provided, gcc would load and execute such plugin, leading to executing whatever code was in the plugin. That hole was plugged in 1.10. This is the whole story. There are no other vectors of executing code that is not part of Go toolchain. Then again, what is your threat model? If you worry that blindly compiling my evil package will execute my evil code during build, you should also worry that linking my evil package will execute my evil code when you run your compiled executable.
- lima 9y agoThreat model is building (but not executing) untrusted code.
- ivan4th 9y agoOne of the most important changes in Go 1.10: Go is now suitable for working with the containers! Hooray! What I mean here is that this problem is finally fixed: https://www.weave.works/blog/linux-namespaces-and-go-don-t-mix https://www.weave.works/blog/linux-namespaces-and-go-don-t-m... GH issue: https://github.com/golang/go/issues/20676 https://github.com/golang/go/issues/20676 The fix itself: https://go-review.googlesource.com/c/go/+/46033 https://go-review.googlesource.com/c/go/+/46033 Relevant part of the release notes: https://golang.org/doc/go1.10#runtime https://golang.org/doc/go1.10#runtime
- lima 9y agoThis is a very important fix for writing things like file servers (think smbd, sftp...), which need to use seteuid/setfsuid.
- stesch 9y agoIn case you are wondering: "generics" is mentioned 5 times (now 6) in the comments right now.
- zbentley 9y agoThat was the first thing you searched for too? I just come here to eat popcorn and learn about type theory.
- piinbinary 9y agoI have been using the 1.10 release candidate for a while, and I have been really appreciating the build caching. It makes running tests after a small change as much as 10x faster for me (especially on projects that import huge libraries, like the AWS library).
- simonbyrne 9y agoCan someone tell me what is going on here: the release notes [https://golang.org/doc/go1.10#language https://golang.org/doc/go1.10#language] state that > A corner case involving shifts by untyped constants has been clarified, and as a result the compilers have been updated to allow the index expression `x[1.0 << s]` where s is an untyped constant; the go/types package already did. But the docs [https://golang.org/ref/spec#Operators https://golang.org/ref/spec#Operators] state that > `var u = 1.0<<s // illegal: 1.0 has type float64, cannot shift`
- cshenton 9y agoIt's probably to do with the fact that one is a "number". If I'm correct, that means in `x[1.0 << s]`. 1.0 is a "number", therefore the shift is valid, but in `var u = 1.0 << s`, it's a float64, and therefore the shift is invalid. see also: https://blog.golang.org/constants https://blog.golang.org/constants
- simonbyrne 9y agoAh, thanks.
- tapirl 9y ago@cshenton 's answer is not perfect. The "var u = 1.0<<s" in go spec is illegal is because s is a variable, so 1.0 will be deduced as a flaot64. However, in "x[1.0 << s]", s is a constant, so 1.0 will be deduced as int.
- Jahak 9y agoi love golang