Hacker News new | ask | show | jobs
by mherrmann 3901 days ago
Anybody else find it difficult to believe that a 4k LOC Go project takes 26k LOC in Python?
2 comments

Typically rewrites like this focus on core functionality; I truly down the project is a 1:1 equivalent. There may be factorings, as well (functionality included as part of Go).
I rewrote a python webservice in go once and found go need A MORE boilerplate code because of json structures need to be strictly defined for better or worst.

In python, it is at lease 10x less code for json parsing. json.dumps(), json.loads() is basically what I needed. The exception handle fill in all the undefined easily.

Also, go used a lot more memory because the GC is not under my control. In python, I can tell the GC to collect and one can see the memory shrink immediately. In go, that was not the case for me. A program that build GB of search index database in go end up using 4x the amount of memory as compare to python. Golang at that time (2+ years ago) lack the gc debugging infrastructure for me to resolve the problem.

Yes. I really do feel like we are not being told the whole story here.
That said, I'm not really surprised about the performance details. My experience was that Go made it pretty easy to "light up all the cores" on a machine. I say this as a person who spent a lot of time releasing the GIL for multithreaded C++ code hiding behind python front ends.
It seems it's looking at everything outside the core libraries. Go has a built-in templating engine. That alone may explain the LoC difference.
It has to be something like that, because no two languages on this planet differ that much in code size without counting library stuff.
Sorry to be pedantic, but I'm sure a Brainfuck (or other similar languages) version would differ at least by that much
6:1 seems to be in the Java to Python range, specially if you do a lot of getters and setters.
That's a design choice, but even if you always use getters and setters in Java and never in Python, the program would have to consist exclusively of getters and setters to get you to 2:1 (or 3:1 if you count closing brace lines).

What makes Java code look bloated is a culture of overdesign, not so much the language itself.