1. It's faster in terms of real performance - given its proximity to C, optimization at the compiler level for multiple platforms, that its highly concurrent and run compiled (usually), this is no shocker.
2. It's faster than transitioning from a dynamic scripting language than it would be to transition to, say, C or C++ or Java, etc.
Not that it's syntactically similar (obviously), but that language, testing and deployment design won't present any egregious bottlenecks and that there's so much built into the core library that complements an http-based service such as this.
In other words, the prospect of going from Python (or Rails or PHP or whatever) to "faster language X" has historically imposed an inherent cost in terms of development that I think a language like Go mitigates to some degree by design.
I think you are talking about 'go run', which one might easily mistake for an interpreter because of the speed of the compiler, but it's actually compiling your code and running it. Were you talking about something else?
Edit: I swear there was an interpreter demo'd, but I may well have been thinking of something like agora, which interprets Go-like code within Go.
OTOH goroutines are green threads multiplexed onto kernel threads (aka N:M thread model).
Even so, a production-ready transition in a few weeks time doesn't leave a ton of time for benchmarking and testing, but as someone who operates on a fly-by-the-seat ethos more often than I should I'm in no position to be tossing stones around.
See this shitty thing I wrote to bridge the gap: https://github.com/mattrobenolt/go-celery :)
Keep in mind that Highscalability bases it's articles on other 3rd party research. They don't talk to the people they are writing about, even when those people (like me) offer to help them get their facts right.
In all likelihood it's just completely wrong.
Nonetheless, my statement otherwise still stands.
But overall, specifically our realtime service is a hybrid of CPU intensive tasks + lots of network IO. gevent was handling the network io without an issue, but at higher contention, the CPU was choking everything. Switching over to Go removed that contention for us, which was the primary issue that we were seeing.
The port to GO will do it (I think), because it have built-in facilities to do concurrent programing across all the library..
When Go has available a significant fraction (subjectively) of the "batteries included" that Python has, then I'll start investing time in Go. Is it there yet (subjectively)?
It's also pretty cool that Go has a full crypto library in written in Go.
I was seriously looking at Go for a desktop app using the promising new go-qml, but there seems to be no elegant way to use Qt's system tray feature with go-qml. I'd say Go still has a way to go before it's got as many possibilities as Python for desktop GUI development.
But for command line utilities and network apps, I'll definitely reach for Go over Python now (although I'm increasingly playing around with Rust and hoping I can eventually just use Rust for just about everything).
Edit: Removed imaplib since Go has no equivalent in its stdlib.
The Go standard library is pretty amazing as far as standard libraries go (I'd say it's more useful than python's, and definitely contains less cruft). Community provided libraries are expanding rapidly, but there is a strong focus on web services all around.
As for home, I'm playing around with imap and some related things at the moment, and pointers to 3rd party libs might be fun for me to try. We'll see.
This part is telling to me. It means their codebase isn't so complex, and optimizing their application for their hardware would take as much time (or less) than adding hardware. For people with large, complex codebases, scaling horizontally increases capacity much faster.
For the record Python uses a generational garbage collector.
yields its own benefits as well.
I'm curious to hear what sort of CPU intensive tasks Disqus does.
It seems that this is what the found team was most comfortable with, so it makes sense that they proceeded to solve problems using tools they already knew well. At some point, they exhausted how far they could take their existing tools and started investing into new tools.
In short, since they were not really pushing volume with Python, just feeding data to Varnish, throughput wasn't such a big deal.
Again, this is my subjective opinion, and this is why we chose to use Go for our new stuff instead of something different.