What are you afraid of? Go is compiled. You have the compiler. You have the libraries. You have your code. You have perpetual licenses to run these things, and even to fork them.
Construct yourself a solid build chain, the kind that works even when you unplug it from the network. Bundle it inside a virtual machine, and it'll probably still be runnable in two decades.
The dependencies that you need to avoid are runtime dependencies, the kind that can disappear overnight. Does my deployment depend on Rubygems or NPM being up? Did I accidentally build in a hard requirement for Google App Engine? Did I use a licensed piece of software whose license could be withdrawn overnight? Is there only one person who can even read my fancy-pants source code, and might that person suddenly decide to become a guru and retire to a distant mountaintop with no cellular access?
But there's no sense in fretting about what might happen on a five-to-ten-year timeframe. Face it: In ten years, the code you write today will look old. Using Java won't save you. The fact that Android is based on Java doesn't mean that ten-year-old Java apps support Android in any meaningful sense. Ten-year-old Objective C code is stale: It doesn't support iOS, it doesn't use new features of Mac OS. How do you even know which Python will be most popular in production in five years, Python 2 or Python 3?
Your code will evolve over the next N years, and if Go spontaneously implodes -- a very unlikely event at this point -- you'll do what the Docker folks are going to do: Keep using it for months or years while you port it to whatever comes next.
You may notice that I carefully elided C to Objective C when selecting examples of things that change. :)
I'm also not sure this is a counterexample. It's just the opposite perspective. From the perspective of a parent, a three-year-old becomes a thirteen-year-old with terrifying speed. A cell biologist would note that both kids are built from the same parts, many of which are also shared with killer whales and the front lawn.
My examples are all easy to flip in this way. The most remarkable feature of iOS is that it is directly descended from the twenty-five-year-old Next system, to the point that it carries all those cute little "ns"es around.
Change is constant, but provided one escapes the traps of lock-in (oops, Adobe Flash, dang!) and resists the whims of fashion, the change can happen slowly and piecemeal. If a new Golang library is important enough, it can always be ported to C later for the benefit of one's great-grandchildren.
The dependencies that you need to avoid are runtime dependencies, the kind that can disappear overnight. Does my deployment depend on Rubygems or NPM being up? Did I accidentally build in a hard requirement for Google App Engine? Did I use a licensed piece of software whose license could be withdrawn overnight? Is there only one person who can even read my fancy-pants source code, and might that person suddenly decide to become a guru and retire to a distant mountaintop with no cellular access?
But there's no sense in fretting about what might happen on a five-to-ten-year timeframe. Face it: In ten years, the code you write today will look old. Using Java won't save you. The fact that Android is based on Java doesn't mean that ten-year-old Java apps support Android in any meaningful sense. Ten-year-old Objective C code is stale: It doesn't support iOS, it doesn't use new features of Mac OS. How do you even know which Python will be most popular in production in five years, Python 2 or Python 3?
Your code will evolve over the next N years, and if Go spontaneously implodes -- a very unlikely event at this point -- you'll do what the Docker folks are going to do: Keep using it for months or years while you port it to whatever comes next.