Experience report on a large Python-to-Go translation
1–10 of 99 posts
Re: Experience report on a large Python-to-Go translation
#2Interesting. I'd have expected more than a 50% code expansion going to Go, maybe even 3x or 5x.
Similarly, he's using 40x speedup as a rule of thumb. I usually think of Python as 20x slower than C.
Personally I'd be loathe to convert a working Python system to Go, but it sounds like he had good reasons. I do wonder a bit whether divide-and-conquer or a C extension might not have worked instead.
Re: Experience report on a large Python-to-Go translation
#3[edit: fixed links]
This was discussed recently on the go-nuts mailing list: https://groups.google.com/d/msg/golang-nuts/u-L7PRa2Z-w/kfUS...
There was also discussion around an earlier post he made about the work: https://groups.google.com/d/msg/golang-nuts/WstriKt2jTA/lsZy...
Re: Experience report on a large Python-to-Go translation
#4I'd like to compliment the author on the quality of this post. It's very well written, data/example driven, fair, and educational.
Overall, a joy to read. Thank you!
Re: Experience report on a large Python-to-Go translation
#5Go is probably more verbose because it’s missing List comprehensions, for example.
It needs map, filter, reduce to reduce line count. Swift, while probably not as performant as Go, makes writing in a more Pythonic style.
[1,2,3,4,5,6,7,8,9].filter {$0 % 2 == 0}.map {$0 * 2}.reduce(0, +)
["550", "a", "6", "b", "42", "99", "100"].compactMap{Int($0)}.filter {$0 Re: Experience report on a large Python-to-Go translation
#6Go is probably more verbose because it’s missing List comprehensions, for example. It needs map, filter, reduce to reduce line count. Swift, while probably not as performant as Go, makes writing in a more Pythonic style. [1,2,3,4,5,6,7,8,9].filter {$0 % 2 == 0}.map {$0 * 2}.reduce(0, +) ["550", "a", "6", "b", "42", "99", "100"].compactMap{Int($0)}.filter {$0 https://github.com/melling/SwiftCookBook/blob/master/functi…
Note that this is the case because Go lacks generics, so it's not a quick or easy fix
Re: Experience report on a large Python-to-Go translation
#7> The problem directed the choice of Go, not the other way around. I
seriously considered OCaml or a compiled Lisp as alternatives. I
concluded that in either case the semantic gap between Python and
the target language was so large that translation would be
impractical. Only Go offered me any practical hope.
I wish they expanded more on this point. Do they mean that rewriting in, say, Lisp would be longer because it wouldn't be a 'port' and more like writing a new program from scratch?
EDIT: Spoke too soon. Reading more carefully, I answered my own question.
> Python reposurgeon was 14 KLOC of dense code. At that scale, any prudent person in a situation like this will perform as linear and literal a translation as possible;
Re: Experience report on a large Python-to-Go translation
#8I'd like to compliment the author on the quality of this post. It's very well written, data/example driven, fair, and educational. Overall, a joy to read. Thank you!
Came here to say this. Engaging, thoughtful, truly well written... This excellent piece is a real contribution to the body of knowledge of language design, and I'm grateful I got to read it.
Re: Experience report on a large Python-to-Go translation
#9[deleted]
Re: Experience report on a large Python-to-Go translation
#10I do not get why people do these total rewrites, especially for working Python systems. Why throw out the baby with the bathwater ? Python is fundamentally a composing toolkit. Rewrite the slow bits in C++/Rust/Go and wrap it. That's how all major Python components like Numpy, Scipy, Tensorflow, PyTorch etc. does it. And that's a major reason why Python dominates today.
Align with the core strengths of Python's philosophy and its toolset and get the benefit. Why fight it ?