* author cannot write portable C sockets code
* author cannot handle C/C++
* author believes his app would be too slow in Python, later abandons App, but retains his bias against Python
* Go has no parens for if/for
* Go has unicode support
* Go has closures "like salt shakers"
* Go is cohesively designed
* Go has nice libraries
Go may or may not be a good language, but this kind of argument is not going to win me over.
There is a very strong difference between "cannot write" and the need for something to be simple.
I can definitely handle C/C++, and I don't think writing something in a higher-level language changes that.
If something is doing processing with 4000 threads with around 10 years worth of by-the-minute data, it sure as hell will run too slow in Python.
And, the arguments stated after are not crucial to "making you switch to Go", which was not the point of the article anyway.
EDIT: Also, I did not abandon the app, and in fact open sourced the Bayesian filter stuff I wrote right here: https://github.com/Poincare/Bayesian.go
But your arguments for Go rang hollow. I'd urge you to go through the "pro-Go" arguments point by point and describe why, say, they apply to Go but not to Python 3.0. And I'm not a Python zealot by any means; I mention it as a comparison point mostly because it's very commonly used.
There are undoubtedly lots of great reasons to use Go, but your article did not enunciate them in a way that would win people over.
That's sort of a terrible example since python is ill-suited to many (might I dare say a clear majority of?) production environments. The field of general-purpose production languages is actually pretty narrow. I somewhat agree with your point that the reasons were on the superficial side. Nevertheless, people are dissatisfied with the C/C++/JAVA trio and efforts to replace them have so far failed to stick (D comes to mind).
It's not like we're setting an impossibly high bar here. Just put forward a reasonable argument for why Go is cool. "Closures like salt shakers" will not win anyone over.
A bold statement, considering the broad range of production environments that have come to the opposite conclusion.
Do you have anything in specific to back up this claim or is this just name-calling?
Knowing Haskell makes reading about Go a very underwhelming experience.
Compilation times are not bad enough to be a problem.
This is what e.g. Haskell does, and Go as well, I think.
This is what Erlang does by default, GHC >= 6.12 will do it when using `+RTS -N -RTS` and Go requires explicitly setting GOMAXPROCS, the runtime defaults to single-threaded (as far as I know, GOMAXPROCS still hasn't been retired) and there is no way to have it auto-detect the core count.
I think he'll still have to learn a fair few tricks to get around some features of Go. Things like type assertions, float32 vs float64, get ready for it lack of generics, and no distinction between stack and heap aren't common in other similar languages, and just getting to know the standard library is a huge part of being productive in a language. C could be seen as better in that respect; the core language is _very_ simple, which can't really be said for Go, though the advantages of Go probably out weigh the advantages of C for many people.
The author needs no age defense. He makes a ton of valid points for why you should try out Go.
Additionally, PyPy has many garbage collection algorithms, while Go has a stop-the-world mark-and-sweep collector.
Go is still really young, yet it's plenty fast. There's plenty of room for it to get much faster.
The problems with making Python fast mostly have to do with its complicated semantics, particularly around things like name lookup; the GIL doesn't have much to do with it.
Interestingly, I predict Go will have a much tougher time here, unless a form of goroutine is created that can't share any state at all. PyPy has been able to do a lot of garbage collection work precisely because it doesn't have to do concurrent GC. Unfortunately, Go crossed that bridge and can't really go back at this point.
I mean, if I want to write a cross platform websocket server signaling server for PeerConnection, what would you recommend that will let me write a statically typed server in 80 lines of code that's all standard libraries? (edit: Websockets was moved to a `go install`able package recently)