
Go 1.8 Release Candidate 1 is released - pythonist
https://groups.google.com/forum/#!topic/golang-nuts/tr2ZKSQ42zE
======
nishs
> 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. [0]

Finally. This is going to make it easier for newcomers to the Go ecosystem,
since commands such as "go get" will now work out of the box.

[0]
[https://beta.golang.org/doc/go1.8#gopath](https://beta.golang.org/doc/go1.8#gopath)

~~~
echelon
Why does Go require a special path for projects to be on? Python doesn't. Rust
doesn't. This just seems annoying for no particular reason.

~~~
schmichael
Python has a list of locations to look for projects (modules) in (sys.path)
and by default includes the working directory as the first item in that list.

Go has a list of locations to look for projects (packages) in ($GOPATH) and by
default does _not_ include the working directory. Unlike Python's sys.path,
$GOPATH normally only contains a single value.

Python's behavior is similar to $PATH on Windows while Go's behavior is
similar to $PATH on Unix.

There are pros and cons to each default value but either language can be
overridden to have the other's behavior if you desire.

I personally quite like having a single unified $GOPATH for all of my source.

~~~
Manishearth
> There are pros and cons to each default value but either language can be
> overridden to have the other's behavior if you desire.

How? With Python I can release a package with code like `import foo from .` in
it. This will not work in Go, a GOPATH package must import things from
subdirectories via GOPATH. At least, this was the case the last time I
checked.

~~~
thegeekpirate
Vendoring

[https://docs.google.com/document/d/1Bz5-UB7g2uPBdOx-
rw5t9MxJ...](https://docs.google.com/document/d/1Bz5-UB7g2uPBdOx-
rw5t9MxJwkfpx90cqG9AFL0JAYo/edit)

[https://blog.gopheracademy.com/advent-2015/vendor-
folder/](https://blog.gopheracademy.com/advent-2015/vendor-folder/)

~~~
shadowmint
Vendoring only works inside a GOPATH; if you're outside the GOPATH, the
vendor/ folder is ignored.

[https://github.com/golang/go/issues/14566](https://github.com/golang/go/issues/14566)

    
    
        There are many problems with running outside GOPATH. Among others, there's no
        caching of built object files, so everything is much slower than it should be
        (go build, go test, and so on). Vendoring is pretty low on the list of problems.
    
        It may be that GOPATH should be reconsidered but if so it should be done as a
        whole change, not just one piece at a time, like @bradfitz said above. 
    
        The solution for now is to use GOPATH.
    
        >  rsc closed this on 6 Dec 2016
    

Once the new dependency tool is done, it seems like GOPATH will be
increasingly irrelevant with vendored dependencies and proper tooling.

(You may also be interested in this extended and active discussion on getting
rid of GOPATH;
[https://github.com/golang/go/issues/17271](https://github.com/golang/go/issues/17271))

~~~
thegeekpirate
You're absolutely correct—I just tested it, and I'll be damned. That's what I
get for never playing around with it, and had (wrongly) assumed that this
would have been one of the most basic features of vendoring.

I appreciate the correction!

------
travisby
What a blockbuster release (candidate). Congrats golang team!

I can't wait to start adding in the mutex contention to our tests, remove our
custom graceful http shutdown library, compile 15% faster, start using context
within our queries, write custom comparators [I needed this just last week! We
had a type that already implemented the sort interface, but I needed to sort
it by a different key in this one-off] for sorting, and have a much better
time debugging JSON unmarshalling.

And those were just the big pieces I noticed that will be an immediate
improvement!

~~~
reikonomusha
Finally, in 2017, we can write custom comparators.

~~~
steeve
A nice comment which adds nothing.

On a side note, you always could.

~~~
junke
> On a side note, you always could.

Yes, with brand new sorter types for each different comparison. Knowing that
Go had first-class functions from the beginning, it is actually quite
surprising that a higher-order sort function didn't already exist.

------
sentiental
One thing that might snag web applications built with Go 1.8 is the change to
the html/template library. If you ever need to include script templates in
your HTML for usage by a Javascript template framework (in my case it was
EJS), then you will need to be aware that html entities will be escaped in a
way they were not in 1.7

Given the following literal:

<script type="text/javascript"> <div><%= something %></div> </script>

Go 1.8 will escape the EJS delimiter, breaking the template. I.e.:

<script type="text/javascript"> <div>&lt;%= something %></div> </script>

I selected EJS specifically because I wanted a templating library that didn't
conflict with html/template's handlebars syntax. If you're in the same boat
you'll want to find a template engine with non-html entity delimiters.

~~~
grey-area
Just had a look at your issue:

[https://github.com/golang/go/issues/18569](https://github.com/golang/go/issues/18569)

I think your comment above isn't quite right. The problem you're seeing is
that previously this was escaped as js (incorrect), and now it is escaped as
text (correct). If you set your type as above to "text/javascript", it works
in go 1.8:

<script type="text/javascript"> <div><%= something %></div> </script>

on 1.8 outputs:

<script type="text/javascript"> <div><%= something %></div> </script>

the one that fails is if you set the type to text/template or similar, which
makes sense I guess as it is not js but might be annoying if your library uses
<> as delimiters. Should work with text/template though if you mark those
snippets as template.HTML type before including in an html/template.

~~~
sentiental
Thanks for looking! Yeah, I managed to typo the HN example - yes, my existing
templates contain type="text/template", and I think that's how I filed the
bug. It's possible for me to inject those templates with a variable instead of
including them directly in the template, although that's a bit more invasive
of a change than what I was doing before.

------
FiloSottile
You can easily install the RC as its own binary with the new awesome version
tool:

    
    
        $ go get golang.org/x/build/version/go1.8rc1
        $ go1.8rc1 download
        $ go1.8rc1 version
        go version go1.8rc1 darwin/amd64
        $ go1.8rc1 build ...

------
sjezewski
There was talk of the go team deciding on a vendoring paradigm. I don't see
any mention in the release notes. Anyone have ideas/updates on how much closer
we're getting to an official vendoring decision?

~~~
stablemap
There is a committee working on it. Here's a detailed update from last month:

[https://blog.gopheracademy.com/advent-2016/saga-go-
dependenc...](https://blog.gopheracademy.com/advent-2016/saga-go-dependency-
management/)

------
maddyboo
It would be neat if there was a Go Playground running the latest beta/RC
version of Go. (Or is there?)

I wanted to quickly test out the new struct type conversion behavior and
obviously my code[1] doesn't compile on the normal playground.

Perhaps interesting to note, the `beta.golang.org`[2] homepage specifically
adds an inline `display:none` style to the div containing the mini Go
Playground which is normally on the `golang.org`[3] homepage - removing that
style in the Chrome inspector, you can see the mini Playground, but it doesn't
work. Upon closer inspection, the code to init the playground is still there,
but the `playground.js` script isn't – the init code, however, checks for this
so it doesn't throw any errors.

I like the attention to detail, at least – you don't want the homepage for a
beta version to have the plaground running the current stable release version;
that would be pretty confusing. Still, I wonder why the HTML and JS
initialization code for the playground is still there? If they went through
the effort to add a `display:none` style to the HTML and a condition to check
if the Playground script is available, why not just remove it entirely?

Just my random thoughts - obviously not a big deal at all, I just found it
interesting!

[1]
[https://play.golang.org/p/_OSA3O2vTR](https://play.golang.org/p/_OSA3O2vTR)

[2] [https://beta.golang.org/](https://beta.golang.org/)

[3] [https://golang.org/](https://golang.org/)

~~~
f2f
> It would be neat if there was a Go Playground running the latest beta/RC
> version of Go. (Or is there?)

umm, no, not automagically. the playground is restricted. it would require
some work to be put in to make it work with the latest release. that work
isn't available for free.

~~~
maddyboo
This is why I don't comment on HN.

Maybe I'm stupid and just always make stupid comments, but I think the
attitude you displayed with your "umm, no" is way too common around here. Is
it too hard for you to not be condescending when making a counter argument?

 _Edit: After re-reading both my comment and yours, I 'm not sure if you were
using the "umm, no" innocently in response to the `(Or is there?)` at the end
of my sentence, or if you were trying to say it in a condescending way. I'll
give you the benefit of the doubt and assume it was the former. I'm not trying
to be one of those SJW people who gets offended at any little thing._

Regarding the rest of your comment:

> the playground is restricted

What exactly do you mean by that?

> automagically

And that?

I'm referring to large RCs like this. I think a lot of people want to test out
new features/changes without pulling the latest version to their machine right
away.

That work is going to have to be done anyway before the final release, right?
And I can't really imagine it would be a lot of work, I would think _maybe_ a
few things would break, but otherwise it should work?

And if you think I mean to have the normal `play.golang.org` start using the
latest RC, that's not what I mean - I would imagine it would either be on a
separate subdomain, like `play.beta.golang.org`. Or, have a dropdown on the
main Playground, but that might be potentially confusing?

~~~
jerf
"What exactly do you mean by [the playground is restricted]?"

The Playground is a very special build of Go. I don't even think it's open
sourced, often because while you can't depend on security-by-obscurity you
still don't necessarily want to just hand people the source to attack on their
own. It's written to prevent people from abusing the playground, so for
instance, the os package can't read real files, the time package returns
constants for "time.Now()" rather than using the clock, and an arbitrary
number of other changes are made to prevent abuse. How many changes it is I
don't know exactly, but there's certainly a number of them. But, more
importantly, the QA work for such a thing is quite substantial. Many of the
changes would also preclude using the playground to investigate the new
features; for instance, you can't test HTTP2 support on there since you can't
open sockets or servers. Presumably updating it would require significant
effort, and at the very least, it can't be afforded to make that a blocker for
a release.

~~~
Manishearth
Interesting.

Rust has two playgrounds (official: [https://play.rust-
lang.org/](https://play.rust-lang.org/), unofficial:
[http://play.integer32.com/](http://play.integer32.com/)), and each is a
completely different bit of open-source software ([https://github.com/rust-
lang/rust-playpen](https://github.com/rust-lang/rust-playpen) ,
[https://github.com/integer32llc/rust-
playground](https://github.com/integer32llc/rust-playground))

They both use docker for isolation, with a bunch of things to make it work.
IIRC we haven't had any issues with this. Furthermore, the official playground
used to be a third completely different bit of software until it was rewritten
in Rust. It also used to use
[https://github.com/thestinger/playpen](https://github.com/thestinger/playpen).

I'm skeptical that the problem will take _that_ much effort since Rust has
solved it (to some degree) twice.

At the same time, it's likely that Go's playpen does a lot more mitigation,
e.g. the time.Now() probably futzes timing attacks. Though in that case they
would need to mess with mutexes or scheduling as well (since you can use
shared memory to build a timer), which complicates things.

(For timing attacks I still think the solution still lies in how you set up
the container, specifically isolating its memory accesses -- instead of
tweaking the compiler itself)

~~~
Merovius
> They both use docker for isolation

Docker isn't really meant as a security mechanism. Among other things, you
still expose the full kernel API as an attack surface. I can't imagine that
they _only_ use Docker, at the very least they'll probably have some dedicated
machines for the playgrounds. Even then, this is probably not a great idea.

The playground uses NaCl (and AFAIK that includes seccomp), restricting both
the instructions that you can use and the set of system calls that you can
make (basically just read/write on fds 0-3 and exit). It's what chromes
sandbox is based upon.

There are a couple of implications from this (most are described in the blog
post linked elsewhere), e.g. that time is faked and that playground-code runs
single-threaded. A great consequence, though, is that playground code is 100%
deterministic, meaning it can be cached (and it is cached pretty
aggressively), reducing the load for popular snippets.

~~~
Manishearth
Hm, seems like they both just use docker's sandboxing parameters
([https://github.com/rust-lang/rust-
playpen/blob/master/src/do...](https://github.com/rust-lang/rust-
playpen/blob/master/src/docker.rs#L20) ,
[https://github.com/integer32llc/rust-
playground/blob/master/...](https://github.com/integer32llc/rust-
playground/blob/master/ui/src/sandbox.rs#L211) ). The official one _used_ to
use libseccomp, but it doesn't anymore. They probably should use
[https://github.com/servo/gaol](https://github.com/servo/gaol) (should be
drop-in) or seccomp , I'll file issues.

IIRC they're on their own dedicated instances.

------
julio83

      Go 1.8 will be the last release to support Linux on ARMv5E and ARMv6 processors: Go 1.9 will likely require the ARMv6K (as found in the Raspberry Pi 1) or later. 
    

Does this mean that we will not be able to produce ARMv5 binaries or this is
only a prerequisite for the compiler?

~~~
rcarmo
Hmmm. If that's true, then I won't be able to build binaries for my old
Synology anymore.

~~~
bostand
More importantly, the cross platform router worm that was ddos-ing everyone a
few months back was written in go and will not be able to upgrade to 1.8 :)

~~~
julio83
And IoT companies will have to put trust in another language. We deployed
hundreds of ARM5 gateways accross Africa with a golang stack. This kind of
decision is not compliant with serious IoT HW providers. Software is easy to
upgrade, hardware not. Now we have to bet on another language... welcome rust?

~~~
zzzcpan
They already dropped support for older freebsd systems and at some point
discussed to drop freebsd as a first-class target. Already hard to judge the
risks for non amd64-linux systems.

~~~
bradfitz
The issue was about clarifying what "first-class" meant more than about
changing how we treat FreeBSD.

------
buckhx
What's a good version manager that allows me to jump versions without moving
my whole workspace over? Currently using gvm which installs and runs different
versions fine, but whenever you switch version you have to move your entire
workspace over or download all your packages again.

Any ideas?

~~~
JulianVModesto
gvm! [https://github.com/moovweb/gvm](https://github.com/moovweb/gvm)

~~~
buckhx
I'm using gvm now, but updating your workspace is very tedious. Here's the
related issue
[https://github.com/moovweb/gvm/issues/189](https://github.com/moovweb/gvm/issues/189),
also I'm not convinced gvm is maintained anymore.

------
XorNot
No mention if this is picking up the fix for the goroutine stack corruption
issue in the release notes.

~~~
alpb
You're right. I think it is included:
[https://github.com/golang/go/commit/b902a63ade47cf69218c9b38...](https://github.com/golang/go/commit/b902a63ade47cf69218c9b38c9a783fc8cfc3041)
(see the end of the commit message)

~~~
iand
That's what I call a comprehensive commit comment.

~~~
SwellJoe
For what appears to be a three line code change. Which also includes dozens of
lines of new comments explaining the bug and the temporary fix.

That's obviously a bug that really...umm...bugged somebody.

------
lsllc
The new plugin package is only supported on Linux? ... hopefully this is just
an rc1 limitation.

~~~
bradfitz
It was going to be Linux & Mac at least, but Mac support was removed at the
final hour due to bugs.

Go 1.8 will be Linux-only.

Go 1.9 should add Mac support back, and hopefully Windows if the right people
have time to work on it.

------
omginternets
>Note that many common MIPS-based routers lack an FPU and have firmware that
doesn't enable kernel FPU emulation; Go won't run on such machines.

I'm considering using Go for a small service that would live on my OpenWRT
router.

What does this mean for me?

~~~
codehusker
Nothing. OpenWRT enables Linux's FPU emulation.

Depending on your hardware, you may run into issues with the size of Go
binaries.

Off topic: If you use OpenWRT, check out the LEDE Project. It's a fork and
development appears more active, but no stable releases yet.

~~~
omginternets
Great, thanks! Also, could you enlighten me as to the meaning behind the FPU
acronym?

Edit: found it -- disregard my last. Floating Point Unit.

