I've been enjoying using Go as a C replacement when I need more performance than Python, but don't actually need to use C. It's been fine for that purpose. I would note that they do keep changing the syntax on a fairly regular basis, the libraries are still young, and I do find the language oddly unexpressive in places compared to even C++ with boost. (E.g., no ternary operator, no list comprehensions, using the same word for all loop variants, and so on.) That said, if you're using it as a C replacement, rather than a Python replacement, I think those are fine trade-offs.
"Google has people who administer apps and services, and they need to, say, write tools that say scrape a few thousand machines statuses and aggregate the data," he says. "Previously, these operations people would write these in Python, but they're finding that Go is much faster in terms of performance and time to actually write the code."
Clever marketing or could Google's problems actually be handled better by Go than Python, in time to code?
I think this may be specific to Google's situation--at least for now. PyPI may not be as comprehensive as CPAN, but it's rare these days that I can't "pip install" my way into having half the solution done before I start writing code. The same simply isn't (yet) true for Go.
Google has many custom components, though. I personally don't write Go nearly as quickly as I write Python, but I have 4+ years of writing Python in everything from tiny scripts up to large applications, both for the desktop and for the web. I have maybe twenty to forty hours of experience writing Go code, absolute tops. It's not a fair comparison. If we assume that the Googlers who are claiming to be more productive in Go than Python have a couple orders of magnitude on me, and that they don't need many prefabricated libraries, and I find the claim plausible.
I don't believe it'd currently be true in the general case, though.
In addition to your custom components point, I wonder if licensing restrictions come into play at all. I am not familiar with Google's policy on use of external code based on license of said code. If there is, hypothetically, a policy to use code for internal projects of only certain licenses, then pypi (generally) may be slightly less useful to them.
If they were re-implementing a significant amount of code then go may indeed be more productive.
They do have a policy regarding external code. It's called "third-party". Google has one big shared code-repo. Generally, the only requirement is to plop the code into the directory called "third-party" and make sure its license is clearly visible. If it's good code, yet "external", Googler's won't have a problem finding a way to use it in there projects.
Have you looked into other Python performance solutions like Cython which lets you add type declarations to Python code, and compile it into a C/C++ module?
In my tests, it produces speedups on numerics that put it within spitting distance of hand-tuned C.
Oh, no question. That's part of why Mercurial is so close to Git in terms of speed, despite Git being hyper-optimized C and Mercurial being Python. But so far, this has always come up when I'm doing one-off, or nearly one-off, stuff. Getting CPython extensions whipped up is more effort, and less fun, than writing the solution in Go.
Faster than Python, better memory use for many types of programs. Compared to Java, less memory use and (I assume) much less start-up time, since no VM is needed. Also, since you can use goroutines, it would seem like you'd be able to do concurrent requests without having to have a special async API like Java/Python have. Go seems like it'll be a pretty great fit for App Engine.
goroutines run in a single OS thread. Same reason for blocking threading on Java. Said this restriction maybe lifted in the future but I wouldn't hold my breath on that.
EDIT: Clarification, on goroutines run in a single OS thread on AppEngine.
Goroutines still provide concurrency with a single thread. It's not that useful for CPU-bound stuff, but I'd imagine it should allow multiple concurrent GAE API calls (as they are just IO, and certainly async under the hood), or you could do CPU-bound stuff while waiting for IO.
From a google developer, responding to complaints about the new per-instance pricing: "If you are using Java, we just launched the ability to make your instances multi-threaded allowing you to use fewer instances to handle the same
traffic"
https://groups.google.com/group/google-appengine/browse_thre...
I'd be surprised if they didn't do the same with Go, by the time it reaches production status.
I'd be interested in a link to that benchmark if you have it.
I assumed that you're talking about http://ziutek.github.com/web_bench/, but that makes no mention of PyPy (other than a HN comment that PyPy takes 2x the memory) and Go comes out on top in that benchmark.
Either way, when saying Go is faster, I wasn't talking specifically about it's http library or io system (I assume both are similar in speed to Pythons). I more meant that if you're going to be writing custom CPU-intensive code to run on App Engine, assuming the same algorithm, Go should be faster. It has better constant factors, and it gives you better control over allocation.
I don't know PyPy well enough to say in what situations it outperforms Go (especially considering that I don't know what kind of VM warm-up you can expect on App Engine), but since GAE doesn't run PyPy, it's not relevant to the discussion of Python v Go on App Engine.
My general feeling is that Go is kind of like a lighter Java. Go is compiled, but also optimized for fast compile times, and it should be faster than python. However, from wikipedia: "Of features found in C++ or Java, Go does not include type inheritance, generic programming, assertions, method overloading, or pointer arithmetic."
Ken Thompson is a co-creator, and the language came from Google. I think Google is just showing that they stand behind their language, and it does seem to hit a sweet spot for a lot of web apps. Although, I don't know too many web apps that need better performance than python.
If your server in Go is 10x faster than your Python server, which is not necessarily unreasonable, that's 10x less hardware expense you have, if your website is actually "doing something". That can add up.
> However, from wikipedia: "Of features found in C++ or Java, Go does not include type inheritance, generic programming, assertions, method overloading, or pointer arithmetic."
For many people (including me) the lack of all this "features" is a feature in itself. I certainly have not missed any of them.
You don't miss generics? In my limited time working with Go, the lack of generics felt like a glaring hole in the language. That said, maybe that feeling goes away as you spend more time with Go, and perhaps learn to program it more idiomatically.
Go has generics, but only for the built-in chan, map, and slice types (and the associated operators). Since the majority of uses of generics (at least in my code) are from containers, this results in me not really feeling the lack too much. Interfaces and reflection cover most of the rest, though not ideally. After using Go for a while, I'm not yet sure if the lack of user-defined generics are a bug or a feature. It limits your expressive power a bit, yes, but it also makes the world so much simpler.
Between interfaces and the builtin generic types, I have never missed generics (specially since append() was added to the language), and that seems to be the experience of most people that have used Go for a while.
Still it probably would be nice to have them some day, but it is worth doing right and not worth sacrificing the current simplicity and elegance of the language.
For me it's only preference at the moment. My Go code isn't that performance critical that I couldn't implement it with Python. But having not to put up with the whitespace/indentation hell of python is a great relief.
