If you think that Python and Go are made for the same tasks then you're really confused.
I try to explain to them that obviously Python developers care about these things, and I show them some of the most common pitfalls. But this isn't the first, or even fifth, thing that you think about when you're coding in Python.
The key thing to remember with dynamic languages, and particularly interpreted dynamic languages, is that they're optimized for programmer speed, not execution speed. And that's fine nowadays, when programmers are expensive and computers are not.
So yeah, maybe Go will run your program 100 times faster. And there are cases when that's important. But in most cases, it's not, and the benefits that you'll get from having a happy, efficient developer will be more than worthwhile.
Having a decent type system and decent concurrency primitives are far more attractive.
But there's no doubt that concurrency is indeed one of Python's weak points, and Go's strong points.
A good type system quietly and with minimal programmer effort encodes and documents your code, helps you find mistakes faster, guides your re-factoring, and gets out of your way when you don't want to deal with it.
It's not Python that's slow, it's CPython. If you use PyPy you get a much faster implementation of Python, not too far from Go speed.
Yes, PyPy is probably faster than CPython. But what then? In most cases, CPython is THE PYTHON. PyPy is still in its early age and has a lot to demonstrate itself as a serious alternative to CPython.
On the other hand, programmer could get out-of-box performance boost from adapting Go without worrying the potential compatibility issues.
PyPy is a very interesting and promising project. I highly respect that. I just don't like the idea of merely using it to dodge the blame of performance slowness, when what people are really talking about is CPython.
Well, from TFA: "Again, they’re not many, but they are quite vocal (including whole startup dev teams blogging about switching their codebase), and enough to create a certain buzz (and to surprise Rob Pike, who initially expected people to come to Go from C/C++)".
Data are always hazy in our industry -- who knows what each company/developer uses? But we can gauge interest from the discussion around something. So:
1) Go had several known startups (and established companies) post that they migrated some of their services to it from Python.
2) We have Rob Pike, who wrote a couple of years go he was surprised seeing most in the Go community come from Python, whereas he expected them to come from C/C++.
Now, I don't know what you mean "If you think that Python and Go are made for the same tasks then you're really confused". What's confusing? Sure, Python has some unique niches (like scientific computing), but there's a lot of stuff people use Python that they could (and are) use Go for.
I'm sure you've heard of Twisted. Go solves a similar problem quite nicely. Also: RESTful services. But even more so, people also use Go for glue stuff, including for stuff previously relegated to a scripting language.
It's not that huge numbers are leaving Python for Go. Perhaps not even 1%. But it's a vocal 1%, and it might also be an influential 1%.
Heck, at some point Perl was king of the hill for scripting and web application development. But then 1% went to Python, and 1% went to Ruby. And then they continued going...
A big reason for this is that some prominent members of the Python community left for Go and that Go talks have started appearing at Python conferences.
We've spent the last few months writing some of our tools in Go. For our purposes, it is slightly slower to develop in, but we have much more faith in its correctness, and deploying the code is a dream. Also, it's much faster than what we've been useful.
We'll still be doing some Python development, but were it up to me I'd be using Go for everything I ever used Python for.