Migrated WordGap from Python to Go 1
blog.zmxv.com
blog.zmxv.com
In fact, I started making a list of things Python devs need to know about when switching to Go. It's all a tradeoff, you lose some expressiveness for performance.
http://play.golang.org/p/XPgHkKCz_D
But you're absolutely right, you trade in some easy expressiveness and lack of boilerplate for better performance and easy concurrency.
But Go is much better about the boilerplate required than most other static/compiled languages, IMO.
Agree re: boilerplate. Much slimmer than Java or C++. And the build times, my God, the build times. It almost makes up for not having a true REPL.
A tuple is just a makeshift struct. Think about it this way: by replacing it with a real struct, you're documenting your code.
This is what it feels like going from a language with tuples, to one without :)
(I would also say "imagine further that you had to do the same whenever you returned multiple values"--but you don't have to imagine ;)
The only thing missing is giving a tuples a name. But if you do that, you should make a struct, or you will forget which field is which and have bugs.
Not only do you gain performance but I think you gain maintainability and clarity. I value that when you read Go the run-time complexity of operations is very clear. In many other languages you often find O(n) or worse operations that appear to many programs in such a way the uninformed assume they are O(1) operations. In Go that does not happen- almost always what you see is what you get. I will gladly write a few more lines of simple code to gain clarity.
This kind of difference is not uncommon when BOTH the before and after program optimally handle IO (network,file,db,etc), BUT the before program is from the interpreted performance tier (PHP,Perl,Ruby,Python) and the after program is from the compiler tier (C/C++,Java,C#,Go,Scala,Haskell).
These micro-benchmarks, while not proving anything, at least suggest that you could be wrong as well: http://benchmarksgame.alioth.debian.org/u64q/benchmark.php?t...
I have ported node.js applications to Go and seen similar substantial speedups. In my cases though I was running in a multi-threading enviroment. not GAE and the performance difference (improvement) was much greater under concurrent load versus single request latency. But that seems reasonable since node.js is closer to Go in performance than Python is.
I guess I just believe it because I have seen it. :)
The benchmarks game shows toy programs not synthetic benchmarks ;-)
Not only it's not impossible, but it's also quite common, even for programs having the same program-level algorithmic complexity.
Except if the programs are IO bound (which happens with most of them), you can see real differences between various languages. It doesn't even have to be compiled vs interpreted (well, if you exclude JITs). A V8 JS program can smoke a Python program (when the latter doesn't reach for some C builtin function).
People reach for C when they are desperate for performance, have the skills to do C, have the time to do C and are ok with loosing the cross-platform capabilities. Pure python code runs on mac/windows/unix (90% of the time). The moment you add a C module to the mix, you end up with the usual cross-platform mess (separate installers for each platform, complicated build processes etc.).
A cleverly written Python program can indeed beat a naively written V8/JS program.
But if they have the same program-level complexity and the Python program doesn't delegate to C libraries, V8 wins. That is: when using the same algorithms in both languages, V8 is faster.
We have h264 decoders using Javascript, and even ports of the QT widget stuck into pure JS (using emscripten). And they run in acceptable speed. Those would be hopeless in pure Python without adding new ad-hoc C extensions.
>And it is not realistic to compare Python to JS while excluding any commonly used optimization strategy for the former, whether that be C or PyPy or using different language constructs.
Well, it's fair, in the sense that mainstream JS is fast, whereas mainstream Python (CPython) is not. And you don't have to resort to stuff like Cython, SWIG and such with JS to get that performance.
Meanwhile, since Go has true arrays, and since you can probably just assume we're in English only and let byte[] substitute for real unicode, you can write very nearly what you'd write in C, albeit more safely, and not be creating string objects by the thousands, and it wouldn't be particularly unnatural Go code. A 12x differential is very plausible. I'd believe you could even go higher.
This is not to say that Go is awesome or that (C)Python is a bad language in general. I like (C)Python. But it does have some bad cases in it if you need lots of performance, fiddly little string algorithms and lots of numeric computation being two of the big ones. (By which I mean numeric computation in pure CPython, not with Numeric Python or PyPy.) In both cases the sheer rate of object creation and destruction work dwarfs the real work being done.
First of all, Go's strings are also immutable. To get around this, you can use the []byte type, as you said, but Go is built with the assumption that all text is UTF-8. Frankly, I find the suggestion that ASCII is good enough, even for Americans, absurd.
Second, Python's "list" type and Go's slice type (what you're calling a "true array") are almost the same under the hood. Both are variable length arrays. (I'm not sure why Python calls it a "list" since it's not a linked list.) The only major difference is that Python's lists are always filled with pointers to the underlying objects. In Go, you have the choice of whether you want to use pointers to the underlying objects or to put the objects into a contiguous block of memory.
Speaking more broadly, there's no reason you couldn't use a lot of different Go practices in Python and end up with much more efficient Python code: pre-allocating lists of the proper size, for example, or making sure to use mutable buffers instead of immutable str objects. However, Go makes it natural to be concerned with these efficiencies, and Python makes it natural to ignore them. Each language has its strengths.
g = bytearray('Do this')
g
>>> bytearray(b'Do this')
g[:2] = 'On'
g
>>> bytearray(b'On this')While in the enterprise everyone is happy using the available set of languages, on HN we continuously see posts about migrations from Ruby/Python to Go.
Note: Even with Go only given a single core a developer can still write a Go program so they are concurrent. That way when one goroutine blocks on IO, another can use the CPU to make progress; furthermore, when multi-threading is enabled the performance upgrade will be substantial and seamless.
If he rewrote Python in Ruby, the perf would have been more or less the same.
If he rewrote in C, he would get even better perf but at much bigger cost (in dev time).
The point of his article is that Go is almost as easy to write in as Python but gives you 10x perf and that's why Go is attractive. It has the right perf/coding effort ratio.