Live data from Hacker News

Why We Switched from Python to Go (2021)

softwareengineeringdaily.com

51–60 of 301 posts

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

#51
post #33

Earlier quoted context omitted.

I think the latter point about "less ceremony" is extremely debatable especially on a larger project.

How does Go have more ceremony than Rust without a borrow checker, lifetime annotations and all?

I think the point is not that Rust has less ceremony (it certainly has more), but that you want the “ceremony” for larger scale projects.

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

#52
I think Go and Angular should have died, and would already be footnotes in programming history if they had not been introduced by Google. Let's make procedural programming great again? I get it, you can compile it and it has concurrency, but there's better alternatives in my mind, unfortunately not as popular.

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

#53
post #29

Earlier quoted context omitted.

Python is an excellent choice for that. What I tend to do is build with Python and, if (and that's a big if) the thing needs to be orders of magnitude faster, then we profile the app to find the hot spots and optimize those, either in Python, with some better approach, or in another language still being called from Python. A rewrite of a whole service from scratch is relatively rare in my experience (unless the origi…

I take a similar approach. Python allows me to rapidly prototype and ... gets the job done — fast (in terms of developer productivity). Once performance becomes a main criteria, it's not so difficult to fork/exec some Go/Rust/C/C++ executable.

I'm thinking about using MPI for that - it should minimize the fork/exec time. Another approach is the extensive use of queues (which is a good thing anyway) and process the queue messages using a more optimized backend.

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

#54
post #33

Earlier quoted context omitted.

I think the latter point about "less ceremony" is extremely debatable especially on a larger project.

How does Go have more ceremony than Rust without a borrow checker, lifetime annotations and all?

related, how does having no unit tests have more ceremony than a full test suite?

(and yet it will do so, as you try to find other ways to make your code safe to release)

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

#55

I read somewhere on HackerNews that Python is kinda like a default language and rest such as Go, C, C++, Java are just for Optimization, once you figure out your solution.

Python is a pretty terrible language to work with. Tooling sucks. Dependency conflicts are common. There's no test framework/runner worth a damn. Web frameworks are inferior to those in most other languages.

If you're doing data science things, it's hard to beat pandas/numpy. I get that those are popular in that community because the barrier to entry with Python is low. People who are just looking for a tool to solve immediate problems would do well to reach for Python.

The problems start when you try to write more complex things. Then you run into the weaknesses in tooling, testing, and performance. People would do well to skip Python and go right to another solution.

I say this having spent half of the last decade working on Python projects. If not for data science and academia keeping it alive, it'd be disappearing along with Perl.

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

#56

So they switched to Go from Python, because of following advantages: #1 Performance #2 Performance (to make the list longer I guess?) #5 Fast compile time... which is an advantage over Python how exactly? #7 Strong ecosystem... which brings us to disadvantage #1 - lack of frameworks (?)

Hmm, why exclude #4: Concurrency and Channels? Concurrency in Python is a nightmare; in fact, doing anything more complex than embarassingly parallel computation in Python is a nightmare. Goroutines are excellent for lots of application logic, especially if your operations are being blocked (e.g. querying a database and waiting for the response). I'll admit the difference is less large if you are doing big data computation / ETL where tasks are long-lived and you can eat the overhead, but the post was specifically for an application's web server.

Also re #3 and #6 - I found learning Go to be relatively painless, coming from a Python background. It was helpful to have much more experienced teammates and to have some opinionated pre-existing infra (e.g. tests, lint, deploy, general app architecture). The lack of frameworks is good/bad -- more decisions to make (though the standard Go libraries seem to almost always be good enough) but if everyone is mostly using some combination of modular libraries, it means that problems are easier to debug and search for on StackOverflow, versus needing to add if the error is in Flask or Django or some other bespoke framework.

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

#57
post #52

I think Go and Angular should have died, and would already be footnotes in programming history if they had not been introduced by Google. Let's make procedural programming great again? I get it, you can compile it and it has concurrency, but there's better alternatives in my mind, unfortunately not as popular.

I can't think of anything off the top of my head that doesn't require a runtime, but does exclusively use green threads.

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

#58
post #52

I think Go and Angular should have died, and would already be footnotes in programming history if they had not been introduced by Google. Let's make procedural programming great again? I get it, you can compile it and it has concurrency, but there's better alternatives in my mind, unfortunately not as popular.

What do you feel is a good alternative to Go?

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

#59
post #48
post #6

"Developer productivity and not getting too creative" is NOT a point in favor of Go. Go does not have a lot of batteries included. Things like error handling, logging, test bootstrapping, etc, require consensus on the team and tight coordination. Every project is basically its own framework. Most teams are not that well-oiled. They are going to find this out the hard way. And fast? Please. If your database queries ar…

Recent-ish experience: - Wrote a distributed app in Python (it aggregated a few GB / day of info from several thousand servers). Performance was terrible, though I was doing all the right things (async I/O, etc.). - Rewrote it in Go. That worked really well, and took just a few days. But management freaked out, forbade Go in engineering, and so: - Spent several months rewriting the whole thing in C++. What a fucking…

Did you have prior Go experience to the rewrite? My experiences line up with this quite closely, similar tasks are much better suited to Go, concurrency management is night and day vs Python. But Go can seem scary to folks without previous experience and that turns lots of folks off - even though the language and syntax don't feel _that_ different and there is a similar batteries included approach, though Go's batteries are generally better.

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

#60

I read somewhere on HackerNews that Python is kinda like a default language and rest such as Go, C, C++, Java are just for Optimization, once you figure out your solution.

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 compared to e.g. Python.

Worth keeping in mind a that a Python program will be about half the LOC of a Java program doing the same thing. (See the reference section here [1].) In other words you can get further with Python before passing the complexity threshold.

Bugs are also proportional to lines of code [2], which is another element that favours Python over more verbose languages like Java.

1. https://svese.dev/comparing-java-and-python-is-java-10x-more...

2. https://amartester.blogspot.com/2007/04/bugs-per-lines-of-co...

Post reply on HN