Kinda makes sense. They are moving to more and more Go.

While Go is quickly eating into my use cases for Python in my own work, I'm not really sure that there's a connection here. Guido's employment at Google was a little more than simply, "Python's a cool language, so let's hire the main Python developer so we can use Python at Google."

Furthermore, Google's vision for Go isn't as a replacement for what Python does - the fact that Go can satisfy many of Python's use cases is by coincidence more than by design.

I personally see Go as more of a Java replacement than anything.

Go will replace Java when it will offer generics, same GC execution speed and the amount of libraries Java currently enjoys.

Channels and Goroutines are easily available in java.util.concurrent.

If you really want compilation to pure native code, there native code compilers for Java as well.

> Channels and Goroutines are easily available in java.util.concurrent.

HAHAHAHAHAHAHAHAHAHA. No.

With your childish comment you just showed how much you know about programming, zero!

Yeah, right. Just take a closer look what goroutines really are (hint: not threads), and how Java threads differ from them.

You show your ignorance again. Do you think that go does not use operatingsystem threads in the background? Do you think the same abstraction could and has not been built for java? How do you think does the Erlang impmentation on Java work? How do you think that scala can start so many actors? How do you think the forkjoin framework works?

Funny how we talk about Go and Java and you suddenly come up with Scala and Erlang.