Live data from Hacker News

Why We Switched from Python to Go (2021)

softwareengineeringdaily.com

251–260 of 301 posts

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

#251

Earlier quoted context omitted.

To me the biggest advantage Python has is the debugging capabilities. Especially combined with PyCharm, ad-hoc interpreter to check things while the execution is at a breakpoint – this is just like cheating. It is too good. I am not an expert software developer and haven't developed anything that needs to be fast, but for my needs, Python is really awesome. That said, I want to learn Go properly.

Go debugging is nearly the exact same experience as Python. GoLand (from JetBrains ... same folks that make Pycharm) or VSCode with delve debugger work flawlessly. I don't think there is any difference between Go and Python when it comes to debugging. Support for both is widespread and high-quality.

The post you replied to mentioned an interpreter. Does Go provide an interactive REPL?

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

#252

Earlier quoted context omitted.

Go debugging is nearly the exact same experience as Python. GoLand (from JetBrains ... same folks that make Pycharm) or VSCode with delve debugger work flawlessly. I don't think there is any difference between Go and Python when it comes to debugging. Support for both is widespread and high-quality.

The post you replied to mentioned an interpreter. Does Go provide an interactive REPL?

Not natively, but there is a community developed one called gore: https://github.com/x-motemen/gore

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

#253

Earlier quoted context omitted.

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.

I worked at one of those places and helped rewrite components into Go ;) Sure, there were performance benefits but in my experience there was never a real business problem that Go solved that Python couldn’t. All the people freaking out about performance didn’t realize that even in the Python days, half of our datacenters pretty much sat idle or severely underutilized. Computing is dirt cheap as long as you’re not re…

So did I :) One of those places replaced an interpreted language used for a process intensive core function with Go and saw a massive performance increase...resulting in clear cost savings.

But Go isn't a silver bullet. It's another tool in the toolbox and sometimes it makes sense to reach for Python, or Kotlin, or Swift, etc. But choosing Python when you should've chosen Rust / Go / D is a tough design decision to quickly come back from.

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

#254
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…

The last time I was on a team using Go, we ended up ditching it for these reasons. We realized it took about as much specialization and wheel reinventing as Rust, which offered way better developer ergonomics in ways that mattered to us and wouldn’t panic over things that weren’t easy to predict or caught by the compiler. There were still tons of trade offs, but it worked well for us. Go is cool but I still can’t see…

Doesn't Rust also have competing nonstandard ways to handle errors? Right now I think they recommend 3rd party libraries for it (anyhow, one other I don't remember), and those library recommendations have changed over time

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

#255
post #228

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.

They didn't say they wanted to learn new things, they wanted to learn a new language. I can want to learn how to drive a race car in addition to my Toyota Corrola without wanting to lear how to operate a crane (though that would be pretty interesting honestly).

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

#256
post #254

Earlier quoted context omitted.

The last time I was on a team using Go, we ended up ditching it for these reasons. We realized it took about as much specialization and wheel reinventing as Rust, which offered way better developer ergonomics in ways that mattered to us and wouldn’t panic over things that weren’t easy to predict or caught by the compiler. There were still tons of trade offs, but it worked well for us. Go is cool but I still can’t see…

Doesn't Rust also have competing nonstandard ways to handle errors? Right now I think they recommend 3rd party libraries for it (anyhow, one other I don't remember), and those library recommendations have changed over time

I’ve been content with the error handling the language offers, but maybe there are scenarios where it isn’t sufficient that I haven’t encountered.

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

#257

Earlier quoted context omitted.

If I understand correctly, numpy at least originally was a wrapper around some Fortran libraries. So you could get the same functionality and performance in Fortran. Am I missing something? Is there some way in which numpy is superior to, say, Linpack (other than not having to use Fortran to call it)? Is there anything unique about Python that enables this approach? Couldn't Go, say, do the same thing? Or C++?

Python has a GC based around reference counting, which is vastly easier to integrate with native code than languages with heavier runtimes such as Go, Java, C#. C++ could give you equal or better performance, but it's not anywhere near as friendly to beginners as Python. Plus, the value of REPL-based programming for prototypes and experimentation is hard to overstate.

C++ has had repls forever (first the terrible hack of cint, now cling).

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

#258
post #10

Earlier quoted context omitted.

The author of the Software Engineering Daily post is credited as Thierry Schellenbach, CEO of Stream, so I'm guessing it's just a cross-post.

Sure, but why do a cross-post years later without saying the information might be dated? For example, you cannot now "Swap out True and False". That was changed in Python 3, and while many were still using Python 2 in 2019, it wasn't so true in 2021. I also wonder how numba does with the "simple_gauss(time)*popularity" expression.

I didn't cross post it. Think it's a content strategy for some of these sites.

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

#259

Earlier quoted context omitted.

> "I just wanted to learn a new language" and > finding a team Are connected. More people out there would be willing to work in Go than Python, even if more people know python. First, a large portion of python writers aren't backend devs, whereas pretty much all Go users are. Second, Python has a very bad rap as a backend language, and for pretty good reason. Third, if someone doesn't know Go, then can still get up t…

> if someone doesn't know Go, then can still get up to speed and use the language extremely proficiently within a few months Which combined with a new code base is very stressful. but this avoids the main point, which is > Python has a very bad rap as a backend language, its not a front end language really(discounting the transpiled JS web stuff). I know people dont like it, and that's fair enough, but its as good as…

> Its perfectly possible to write low latency high scaling code in python, just as it is in go and rust.

Depends on what you mean. A tiny and simple HTTP handler brought up on lambda, sure, Python will be as good as anything else. Anything larger than that, and no, it isn't. Python just doesn't have the semantics to do what Go and Rust can at scale. I run a service that uses 4 threads in Python and it's horribly slow and unreliable. I worked on a service in Go that used hundreds of concurrent go routines and it was reliable as hell.

> Despite what people say, code is just a logic brush, how you hold it, and how toy paint with it determines how pretty the picture is.

That's a great analogy when you consider painters use different paint brushes for different parts of the job.

> Yes there are inherent defects that each language has, but once again part of being proficient is know how not to blow your feet off. If Goethe can make wonderful prose in german, you too can make good scalable backend code in python.

Sometimes yes. But accomplishing the same in Go is so much easier I don't know why you'd bother.

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

#260
> Python allows you to get pretty creative with the code you’re writing. For instance, you can:

    Use MetaClasses to self-register classes upon code initialization
    Swap out True and False
    Add functions to the list of built-in functions
    Overload operators via magic methods
    Use functions as properties via the @property decorator
These features are fun to play around with but, as most programmers will agree, they often make the code harder to understand when reading someone else’s work.

---

Who actually does any of that, particularly at the office?

No one has the time for shenanigans.

Post reply on HN