Go is not Erlang. Go supports green threads (goroutines) and offers CSP-like channels to communicate between threads. However, it does not have a distributed computing story yet (at least, not compared to Erlang, the usual Java frameworks, etc.).
For a library such as TensorFlow, Go is not really an option yet, for many difference reasons. E.g. the lack of parametric polymorphism makes it hard to parametrize code for single, double, or even half precision. Go does not support anything like expression templates, which exploit laziness to eliminate temporaries. Moreover, a lot of machine learning happens on GPUs nowadays. AFAIK, there are no CuDNN bindings for Go yet.
tl;dr: impedance mismatch
As far as I know, goroutines are NOT green threads (threads managed by run-time environment instead of OS). Go produces native code (no VM). And, the goroutines can be multiplexed (depending on implementation) to OS level threads.
Green threads can be managed by a runtime library or VM, so no VM doesn't mean no green threads.
> the goroutines can be multiplexed (depending on implementation) to OS level threads.
Being multiplexed onto OS level threads is normal for green threads. Goroutines are "hybrid" (M:N) rather than "user-level" (N:1) threads, but anything other than 1:1 native threading means that you need a runtime or VM managing it, and its a kind of green threads.
I don't know that I'd say "just": like Erlang processes, goroutines have some special features not shared by all other green threads, even with a similar M:N threading model. I'd say that Erlang processes and goroutines are each specific kinds of M:N green threads with unique features and distinct names. So, its useful to distinguish them within the broader category, they just shouldn't be distinguished from the category.
and if you watch Jeff Dean's video, he mentioned more front end in other languages, Go is the only example and as the interest from internal.
What are your company's official languages used for?
[Former Googler around when Go got it's start]
Since the TensorFlow video post is currently on the frontpage as well...as someone who uses neither C++ nor Go (I can write FizzBuzz level of code in both and read both well enough to get what's going on) I have to wonder how much internal buyin Go really has at Google if the core of such a project is implemented in C++. It's a project they see as valuable in the future and it would lend itself really well to Go as these calculations are done distributed and yet they picked C++.
[I'm not sure how much of the old framework they reused but if the will to Go was really strong I'm sure that wouldn't have been an issue]