Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why We Switched from Python to Go (2021)

softwareengineeringdaily.com

Post reply on HN
Print view View original

221–230 of 301 posts

Re: Why We Switched from Python to Go (2021)

#221

Post by kortex »

idazuwaika wrote: post #37

I'm considering moving away from Python as well, to compiled language also. Performance and single executable are my primary motivation. I'm tired of venv, PYTHONPATH and OS package dependency issues. I'm however very much reliant on Pandas and Pyarrow for custom ETL works. Does anyone have suggestion what language and ecosystem I can switch to? Preferably something simple that does not require cluster or JVM to avoi…

> I'm tired of venv, PYTHONPATH and OS package dependency issues.

To both you and the peanut gallery. You should basically* never be using PYTHONPATH or OS packages. And there are several solutions to improve ergonomics of virtualenvs out there.

* I've never had a legitimate use case to use OS packages and only one to use PYTHONPATH, which is tot temporarily set it during tests in a repo with multiple independent sub-packages, coverage reports get a bit squirrelly.

Re: Why We Switched from Python to Go (2021)

#222

Post by AnimalMuppet »

sliken wrote: post #218
dgb23 wrote: post #207

Earlier quoted context omitted.

I have a bit of a different take on this. They mentioned it was a rewrite that happened in a couple of days in a shop that uses C++ and Python (at least). We can assume it was a small to medium utility program. Someone who can write C++ and Python professionally will get up to speed with Go in a few days. This shouldn't be a hiring issue. The cost of rewriting it again in C++ can easily be higher and apparently was a…

As a programmer I agree, but as management that's a hard thing to tell. If you were the boss would you allow Lisp? Scheme? Erlang? It sounded like a pretty important piece of code, even if small. The complaints about being forced to do C++ and how painful that process was shows that it's at least non-trivial.

I disagree. If you're managing programmers, you might be expected to have a bit of a clue about programming languages. If you can't tell how easy it would be for your people to pick up Go versus how easy it would be to pick up Lisp, you have no business managing programmers.

Re: Why We Switched from Python to Go (2021)

#223

Post by klodolph »

erokar wrote: post #60
klodolph wrote: post #41

Earlier quoted context omitted.

Python has problems scaling to medium-size code bases because programs above a certain size tend to become difficult to reason about. This is not a performance issue, and it’s the #1 issue that I choose to rewrite Python programs in other languages. Python type annotations help. IMO modern languages like Go and Java are pretty easy to get into and you can use them for a first implementation without really sacrificing…

> Python has problems scaling to medium-size code bases because programs above a certain size tend to become difficult to reason about. In mye experience Python programs are not more difficult to reason about than equivalent Java programs. To the contrary an over-reliance on certain design patterns and ubiquitous, inescapable OOP complicates Java code bases, while the static typing is so weak it affords little safety…

There's a speculation in the first citation:

> Python is not maintanable above 50k to 100k lines of code and because of that people consider this code bases very large

Note that this is a speculation, not a conclusion, the article is not very thorough, and LOC is mostly used because it is convenient to measure, not because it is what we are trying to measure. I'd personally consider 50k a "medium" code base, and 10k is "small".

> Worth keeping in mind a that a Python program will be about half the LOC of a Java program doing the same thing.

LOC is a confounding variable.

> Bugs are also proportional to lines of code...

Not supported by the citation. The citation measures bugs per line of code, and finds that for 500 kloc of code, the average number of bugs will be somewhere between zero and 25,000. That's a very wide range.

To be clear, I'm not really trying to fight against Python or for Java here. I'm just giving my reasoning for why I might personally choose one or the other. I think that the idea that you would switch languages because Python is slow is actually far more situational. You might have ten reasons to choose Python or Java, runtime performance may only be one of those factors, it may not be heavily weighted, and in some cases, Python runtime performance can be extremely fast (I do a lot of NumPy stuff... it's great).

The relationship between programming language and code quality is, at best, a difficult relationship to study. It's hard to make any kind of direct statement like "using language X results in more bugs than using language Y" and back it up by evidence, even though we believe it to be true. Individual statistics which relate some variable to LOC is not useful in isolation.

See: https://arxiv.org/abs/1901.10220 (a reproduction of an earlier result, that invalidates many of the conclusions)

Re: Why We Switched from Python to Go (2021)

#224

Post by Spivak »

gosukiwi wrote: post #219
usrn wrote: post #139

Earlier quoted context omitted.

This probably really depends on who you're working with. I think Go is a lot better at forcing people to behave than Python is.

Forcing people to behave is the opposite of Python's approach, afterall, [we are all consenting adults here]( https://mail.python.org/pipermail/tutor/2003-October/025932.... )

While this is something I very much appreciate about Python I think it's also true that structure needs to increase with the size of your codebase and the size of your team to avoid being driven mad. Python takes the "just apply discipline" approach which can absolutely work for lots of code but falls apart a bit with large heterogeneous teams.

Re: Why We Switched from Python to Go (2021)

#225

Post by feffe »

bloblaw wrote: post #102
uhtred wrote: post #86

Earlier quoted context omitted.

Go should have died?! didn't Go come out like yesterday? This is why I am hesitant to invest time in new hot thing languages. I swear in 20 years everything important will still be written in C, PHP, Perl, C#, Java, Python (how could I forget JavaScript).

Go was released in 2009, which is 13 years ago. Many companies have built significant portions of their stacks on top of Go....Twitch, Google, Uber, Lyft, Amazon, etc. It's widely used in industry and isn't going anywhere.

Go 1.0 was released in 2012, it spent 3 years in alpha/beta phase.

https://go.dev/blog/go1

Re: Why We Switched from Python to Go (2021)

#226

Post by throwaway894345 »

Spivak wrote: post #189
throwaway894345 wrote: post #173

Earlier quoted context omitted.

Black is awesome for the Python ecosystem, but it's still painfully slow for large files compared to gofmt.

How large is large because I don’t think I’ve ever even noticed black’s delay on 10k files.

It would pause for a few seconds on 1-3kloc files on a fully loaded 2019 macbook pro.

Re: Why We Switched from Python to Go (2021)

#227

Post by [deleted] »

didibus wrote: post #200
bloblaw wrote: post #97

Earlier quoted context omitted.

Go is successful because it has many appealing features: 1. trivial cross-compilation 2. native multi-threading (eg no GIL or multi-process hacks) that is easy to take advantage of 3. fast. An order of magnitude faster than Python in many cases. 4. easy to deploy. Most often just a single binary I like Go because once I compile it, I can ship that binary anywhere and it will run. I like Python for a great number of t…

Ya, and if you look at the language space, there's nothing else that offers #1. That set of features isn't related to the language itself (though the language was designed to allow those features). This is where Go is appealing, it's not the language itself, it's the properties it brings with it. Cross-compilation, multi-spec, reasonable performance and low memory footprint. Single binaries. And I'd add fast compilat…

[deleted]

Re: Why We Switched from Python to Go (2021)

#228

Post by tasuki »

KaiserPro wrote: post #129

As with all of these posts, the big reason is never really written: "I just wanted to learn a new language" Now, the points they've made are valid, Go concurrency beats the pants off python, and with gofmt, there is less of a debate about style. Te bit about finding a team is pure horse cock. As they point out there are a bunch of C++/C programmers about. There are even more python programmers too. Go is a tiny pond…

> As with all of these posts, the big reason is never really written:

> "I just wanted to learn a new language"

Strong disagree. If the actual purpose was learning new things, they'd have chosen a language which does things a little differently than all of the mainstream. At least Haskell or some Lisp...

The fact they chose Go shows they care primarily about the practical side.

Re: Why We Switched from Python to Go (2021)

#229

Post by mountainriver »

sliken wrote: post #147
gkop wrote: post #131

Earlier quoted context omitted.

For those of us not deeply familiar with Python vs Go, can you share a bit about why gofmt is so much better than the Python status quo (IE what’s wrong with autopep8 mentioned in article?)?

Go has one, the same one used by the compiler, so there's no arguments, no multiple standards, etc. Python has a few options, and when a new language feature comes out the time to implementation may vary. Think of it this way, if you could all the python code on github and ran it though autopep8, what fraction of the files would be changed? Generally in the go community, contributions, patches, code, etc that's not f…

It’s also an example of how Go thinks about all problems. Do things one way that is well made and roughly satisfies most use cases

Re: Why We Switched from Python to Go (2021)

#230

Post by dralley »

Xeoncross wrote: post #38
jerf wrote: post #23

Earlier quoted context omitted.

It's been a while since I wanted something in Go that wasn't available, other than the obvious big-ticket items like NumPy which are ecosystems unto themselves. (Or, to put it another way, yeah, Go doesn't have NumPy, but neither does anybody else other than Python at this point.) YMMV, of course, but it's certainly not a routine occurrence.

The other packages I've missed are all Rust or C packages that manage to create absurdly compact or performant versions of low level structures and blocks like tries, probabilistic filters, encryption primitives, or custom binary storage solutions. All things that Java, Go, C# and others just can't be the best at because of the overhead or GC.

There are definitely data structures that are a massive pain in the ass (if not impossible) without a GC of some kind.
Post reply on HN