
Go 1.10 Release Notes - 0xmohit
https://golang.org/doc/go1.10
======
ivan4th
One 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-m...](https://www.weave.works/blog/linux-namespaces-and-go-don-t-mix) 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
This is a very important fix for writing things like file servers (think smbd,
sftp...), which need to use seteuid/setfsuid.

------
old-gregg
Quickly 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
Do you executables run faster, or slower?

~~~
bradfitz
They should be faster:
[https://golang.org/doc/go1.10#performance](https://golang.org/doc/go1.10#performance)

------
danielvf
> "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!

~~~
sigjuice
IMHO, all programs ought to behave like this and be self-contained within a
directory.

~~~
pjmlp
Standard practice back in the MS-DOS days, what Microsoft now calls _xcopy_
deploy, because that is how we used to do it.

------
teacpde

      The 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
I 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?

~~~
rafi_kamal
Not a Go developer but bazel in Java does the same thing and it's really
helpful when writing test cases. Say I am editing two test methods within a
test suite of 30 test cases, it will run only those two tests. For the rest 28
it will show the cached output.

~~~
kasey_junk
But thats the thing, this is _not_ incremental compile/test. Its just checking
the binary output (at least as far as I can tell).

------
xiaq
One 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
I 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.

~~~
cube2222
Barely anybody uses them though.

~~~
cweagans
They 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.

------
ValentineC
Would 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)

~~~
felixfbecker
Also, 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
This 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)

------
piinbinary
I 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).

------
ordinaryradical
As 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.

~~~
gameswithgo
My 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.

~~~
peterevans
Go is like the Six Million Dollar Man language, compared to C. It's everything
C can do, but much better.

Both C and Go are very, very simple languages; there aren't many keywords, and
it's pretty easy to grok both at a functional level. It takes, of course, a
bit to reach the second-level understanding you need to make full use of
either language, but it's easy to hit the ground running in both.

We sometimes get stuck on one language being better than others because it has
X feature or Y concept, and I've seen some people essentially _root_ for one
language over another. But at the end of the day, languages are tools to get
your work done, and _on balance_ the work is going to be hard whichever route
you go. Use the one that suits the talents you have available and that broadly
complements the needs that you have.

~~~
zkomp
Everything C can do but better? Sure you are not confusing Go with Rust?

Go does have a GC, not manual memory management

Go can't interact performantly with other languages.

Go is like Java (not C). Its kind of nice but deliberatley sabotaged by (Big
Company).

~~~
peterevans
I'm pretty sure I'm not confusing it with Rust!

That said, I don't think there's anything more I can say which can add to the
conversation. I'm happy to allow what I have said to stand.

------
simonbyrne
Can 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
It'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
Ah, thanks.

~~~
tapirl
@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.

------
lima
> _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
Here'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
Threat model is building (but not executing) untrusted code.

------
Jahak
i love golang

------
alexandernst
Have they fixed already the GOPATH crap?

~~~
konart
>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
IMHO, fixing it would be being able to build go code on random directories
without env hackery.

~~~
gschier
I think this is on the roadmap but I'm not sure the priority. Check out this
proposal
[https://gist.github.com/sdboyer/def9b138af448f39300cb078b0e9...](https://gist.github.com/sdboyer/def9b138af448f39300cb078b0e94cc3)

EDIT: Found the proposal on the dep roadmap:
[https://github.com/golang/dep/wiki/Roadmap](https://github.com/golang/dep/wiki/Roadmap)

------
stesch
In case you are wondering: "generics" is mentioned 5 times (now 6) in the
comments right now.

~~~
zbentley
That was the first thing you searched for too?

I just come here to eat popcorn and learn about type theory.

------
0xmohit
Release notes: [https://golang.org/doc/go1.10](https://golang.org/doc/go1.10)

~~~
dang
We've changed to that URL from
[https://blog.golang.org/go1.10](https://blog.golang.org/go1.10).

~~~
lobster_johnson
Maybe merge with this:
[https://news.ycombinator.com/item?id=16395607](https://news.ycombinator.com/item?id=16395607)

~~~
dang
Thanks! Done.

------
nextstepguy
There are no significant changes to the language specification

This is my least favorite part of the release.

~~~
gameswithgo
It is already turing complete! :D

------
Rickasaurus
Does it have generics yet?

~~~
erik_seaberg
> There are no significant changes to the language specification.

I'll continue hoping goderive becomes a language that displaces go.

~~~
mirekrusin
Go++

