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.
Why We Switched from Python to Go (2021)
251–260 of 301 posts
Re: Why We Switched from Python to Go (2021)
#252Earlier 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?
Re: Why We Switched from Python to Go (2021)
#253Earlier 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…
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"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…
Re: Why We Switched from Python to Go (2021)
#255As 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)
#256Earlier 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
Re: Why We Switched from Python to Go (2021)
#257Earlier 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.
Re: Why We Switched from Python to Go (2021)
#258Earlier 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.
Re: Why We Switched from Python to Go (2021)
#259Earlier 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…
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 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.