Background
«guarantees … is installed» merely means it depends on a set of packages which actually provide Go dev. env.
As you can see,
this package depends on three other packages—golang-1.8-doc,
golang-1.8-go, golang-1.8-src—so when you install golang-1.8,
those three will be installed as well.
The problem you're experiencing is, I must admit, indeed confusing
but can be easily explained.
If you'll look at the list of packages installed by golang-1.8-go, you'll see that the go tool is installed as /usr/lib/go-1.8/bin/go,
and the directory /usr/lib/go-1.8/bin is not listed in the
default PATH environment variable (set by /etc/profile).
The reason it's done this way is twofold:
There can be several groups of golang-X.Y* packages in the same
Debian suite at the same time; say, Stretch has 1.7 and 1.8.
It's crucial to understand that they are co-installable,
which may be useful to test how a project which was tested
against X.Y will work with X.Y+N.
Debian provides a special "the most generic" Go package
which depends on a specific golang-X.Y package which was deemed
to be "the standard" for the parcicular Debian release.
In Stretch, it's golang-go,
and as you can see, it has "1.7" in its version and depends on
golang-1.7-go.
This package makes sure the executable binaries
provided by a specific default golang-X.Y-go package are available
in "the standard place" — under /usr/bin
(see for yourself).
What to do about it?
Several possiblilties:
Merely call /usr/lib/go-1.8/bin/go by its full pathname.
The go tool "knows" where its GOROOT is so it will find its
packages specific to its version just fine.
Prepend that directory to your path variable;
say put something like
export PATH="/usr/lib/go-1.8/bin:$PATH"
into your ~/.bashrc script
and the next call to go will find it in the new place.
Grab the source of the golang-go package, fix it so that it
makes golang-1.8-go the default package, build it and install.
(I'd not recommend to go this way just yet.)
Hope this helps.
Another stab at explaining
Stretch has two packs of three packages: golang-1.7-* and golang-1.8-*.
In each, pack, the golang-1.N-go package installs its go binary under /usr/lib/go-1.N/bin. Neither of them installs a symlink under /usr/bin.
The reason for this is to make these packs of packages co-installable,
so that you can compile your Go code with any of the installed versions.
Now there is another, independent, package, which does not encode Go release version in its name.
It's named golang-go, and it depends only on golang-1.7-go
where 1.7 is the default version of Go runtime for Stretch.
In another release, golang-go will depend on another golang-X.Y-go
package.
It is this package, which provides /usr/bin/go pointing at
/usr/lib/go-1.7/bin/go.
So if (and only if) you have golang-go installed, will you have
the go binary available under /usr/bin, and that will be of Go
1.7 in Stretch.
And no, it's not possible to somehow force golang-go to point at
go from the installed golang-1.8-go package, and neither is there
a way to select a preferred Go version via the "dpkg alternatives"
mechanism.
My take on "the why" of this approach is to have a well-known version
of go in any given Debian release. This is supposedly needed for
building Debian packages of software written in Go.
Otherwise, it would be required for package building machinery to invent
some trickery for finding the default version of Go;
as of now, their source packages may
just depend on golang-go and call it a day.
