It's interesting that Python has a C library for this, which indicates that someone thought Python couldn't cut it for this task. Yet the PyPy guy (in the comments) claims that with a bit of tweaking they got the pure python JSON encoder working faster than the C library (plus python/c interface overhead I assume) and that the same could probably be done for decoding too.
Python's USP seems to be the ability to drop down to C or C++, PyPy's is that it's fast enough to keep everything in high-level Python (at a cost in memory) and Go's is that it's low-level enough that you can do the C level optimisation in Go (though as yet they haven't for this particular case).
I think the time for the traditional Python approach has passed as newer technology allows you to be fast enough for many tasks without leaving the language and even Go is aimed at a fairly low level. PyPy is cool but is somewhat chained to assumptions in Python (though this lets them build on that wide legacy). So it makes me wonder what the new Python/Ruby/Perl is going to be? Possibly something written with PyPy's toolchain to get a JIT? Do they have a here's what we can do if we get to rewrite the rules to suit our tools language in the PyPy family? What are the other contenders? All the ones that spring to mind are rewrites of existing languages.
Something like Julia, Rust or Clay that are high level languages but with little more than Python-like simplicity that generate LLVM code seem powerful. This general model is the closest to a viable C-replacement I have seen yet.
In addition, personally, I'd much rather invest my time learning above the flexibile and fully open LLVM technologies than above Google's proprietary little-better-than-Java constrained language.
For current practical purposes though, Python/C combo is more than sufficient for many needs.
Does Python let you optimize easily? Not in my experience, unless you define "easily," as pushing the critical path into C libraries. (Not an unreasonable approach, just not one I'd call "easy," and then you're not using Python anymore.)
Go does give you the tools you need to profile, understand, and then fix performance issues without switching languages.
Profiling in Python isn't hard either. But yeah, you really can't gain the performance of statically typed language in pure python (well, maybe with pypy). However, pushing the critical path into C library doesn't have to be as horrible as it sounds (for python developer at least). Cython[1] project can be very helpful. You just annotate critical variables/functions with types and compile the now cython code into C. This C code will be pure C as you wrote it in your typed parts, and bunch of ugly (but commented) calling of Python libraries in pure python parts. Then you just throw it at gcc and you are done. The best thing is that you can mix the typed/untyped code and pass variables around as it was pure python. Example from docs: http://docs.cython.org/src/userguide/tutorial.html#primes
Comments
The usual benchmark complaints: You're not really comparing language performance, because the Python version is using an optimized C library.
But isn't that the deeper point?
Program in something that lets you optimize easily (or use optimized libraries easily). That's a significant, real-world performance advantage.
While it is a virtual certainty that Go will get a fast JSON library, Python's broad, mature library support is very helpful.
It's interesting that Python has a C library for this, which indicates that someone thought Python couldn't cut it for this task. Yet the PyPy guy (in the comments) claims that with a bit of tweaking they got the pure python JSON encoder working faster than the C library (plus python/c interface overhead I assume) and that the same could probably be done for decoding too.
Python's USP seems to be the ability to drop down to C or C++, PyPy's is that it's fast enough to keep everything in high-level Python (at a cost in memory) and Go's is that it's low-level enough that you can do the C level optimisation in Go (though as yet they haven't for this particular case).
I think the time for the traditional Python approach has passed as newer technology allows you to be fast enough for many tasks without leaving the language and even Go is aimed at a fairly low level. PyPy is cool but is somewhat chained to assumptions in Python (though this lets them build on that wide legacy). So it makes me wonder what the new Python/Ruby/Perl is going to be? Possibly something written with PyPy's toolchain to get a JIT? Do they have a here's what we can do if we get to rewrite the rules to suit our tools language in the PyPy family? What are the other contenders? All the ones that spring to mind are rewrites of existing languages.
Something like Julia, Rust or Clay that are high level languages but with little more than Python-like simplicity that generate LLVM code seem powerful. This general model is the closest to a viable C-replacement I have seen yet.
In addition, personally, I'd much rather invest my time learning above the flexibile and fully open LLVM technologies than above Google's proprietary little-better-than-Java constrained language.
For current practical purposes though, Python/C combo is more than sufficient for many needs.
Does Python let you optimize easily? Not in my experience, unless you define "easily," as pushing the critical path into C libraries. (Not an unreasonable approach, just not one I'd call "easy," and then you're not using Python anymore.)
Go does give you the tools you need to profile, understand, and then fix performance issues without switching languages.
More detail: http://blog.golang.org/2011/06/profiling-go-programs.html
Profiling in Python isn't hard either. But yeah, you really can't gain the performance of statically typed language in pure python (well, maybe with pypy). However, pushing the critical path into C library doesn't have to be as horrible as it sounds (for python developer at least). Cython[1] project can be very helpful. You just annotate critical variables/functions with types and compile the now cython code into C. This C code will be pure C as you wrote it in your typed parts, and bunch of ugly (but commented) calling of Python libraries in pure python parts. Then you just throw it at gcc and you are done. The best thing is that you can mix the typed/untyped code and pass variables around as it was pure python. Example from docs: http://docs.cython.org/src/userguide/tutorial.html#primes
1. http://cython.org/