Hacker News Reader

Comment by kriro | Hacker News Reader

Go seems like a fun language that has been sitting on my "look into it list" for a while, can't belive it's already six years old.

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]

View on HN

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++.

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

> Go supports green threads (goroutines)

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.

> Go produces native code (no VM)

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 see. So goroutines are just green threads with a nicer name? Thanks for correcting me. EDIT: Editing my comment because I can't reply to your reply. Yeah, I used "just" with the intention of saying that goroutines are well within the category/definition of green threads.

> So goroutines are just green threads with a nicer name?

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.

I think in the TensorFlow case it is just a purely technical decision - I don't see how they could achieve what they aim for with that project in Go (or really, in anything but C/C++ at this point in time). Right tool for the job, etc.

+1 for right tool for the job. Also, I can imagine they have large amount code already there in C/C++ since this is the second deep learning system they designed.

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.

Go is a language designed by Google people, but it is very much not the standard Google language. Most things Google does aren't done in Go.

Having said that Rob Pike told me that Go is now one of Google's "official languages".

... which just means developers at Go now have permission to use it, along with Python, Java, and C++, to build things, right?

I believe so.

Pretty much.

what does "just" mean?

What are your company's official languages used for?

Not so much permission as support. Being an official language means that the core internal libraries have Go bindings.

It is a standard language at google. It gets used for things like the download service and other high throughput service which is it's sweet spot. The TensorFlow project in previous iterations predates Go's official stamp of aproval at Google I believe and stopping to rewrite is an unnecessary step. It's possible that now something like Go would be used instead.

[Former Googler around when Go got it's start]

Reply on news.ycombinator.com