Live data from Hacker News

Why We Switched from Python to Go (2021)

softwareengineeringdaily.com

131–140 of 301 posts

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

#131

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…

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?)?

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

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

Management forbade the use of Go? But they allow both Python and C++? So their rationale for forbidding Go is... what?

Is this just cluelessness and management by familiarity with buzzwords?

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

#134

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…

You down with RDD?

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

#135
post #124

Earlier quoted context omitted.

It's dated Wednesday, March 3 2021. Is there another date I missed?

https://news.ycombinator.com/item?id=31517109

I apparently didn't get far enough in the comments. Thanks for pointing that out. I didn't make the original comment you replied to, I had just noticed and was confused by 2021 not being 4 years ago.

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

#136

> Disadvantage 2 – Error Handling I'm by no means a Go expert, but it felt like Go forced consistent error handling. > Another issue is that it’s easy to forget to handle an error by accident Does anyone have specific examples of error scenarios that skip through the cracks? > While this approach works, it’s easy to lose scope of what went wrong to ensure you can provide a meaningful error to your users. The errors p…

Error variable shadowing is a big one that occurs in go codebases. Along with the re-use of for loop variables, it is the most common Go footgun.

The go language guys could fix both of these easily - force the caller to check error or explicitly drop it (_) optionally if non-null. That would almost completely eliminate the problem.

I really like Go - I can pick up pretty much any Go code, from any open source project or any fellow engineer and read it with ease. No context, secret macros, implicits, etc. The code basically is what it appears to be. This is an enormous benefit in most contexts.

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

#137
post #110
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…

How fast is it compared to rust ? Do you know. I ask because I've started a side project in rust because all of its guarantees were appealing to me (I don't want to spend too much time on bugs, and my code uses some threads). I also need maximum performances. So I've chosen it. But now I have my compilation times that reach 45 seconds, so I'm slowly wondering if the go balance (towards fast compilation) would not be…

There are a bunch of different metrics for performance that it is a little hard to compare.

Rust will have faster CPU and memory performance. It has no GC (well, other than RC). If you are IO bound, there won't be much of an appreciable difference, assuming you are using Rust's async/await for stuff. If you are using threads directly, then it will be a lot easier to make goroutines faster for IO stuff.

The long compile time of rust has a lot to do with it's LLVM backend, which is ultimately generating pretty fast code. You don't get that with go (well, unless gollvm lands). Go traded execution speed for compile speed by doing their own compiler/optimizer. Generally speaking, that doesn't really matter (hence the reason python is popular).

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

#138
post #131

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…

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?)?

I don't think there is a status quo. There is choice between autopep8, yapf (which itself supports 4 different styles), black, and maybe some more I'm missing. With languages that have a built in formatter this isn't an issue.

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

#139
post #60

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…

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.

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

#140
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.

For a lot of people like me, Go was something of a better scripting language. It wasn't as hard to grok as C or Rust, it wasn't as slow as Ruby, Python or PHP. most of all, it it was designed to make use of multiple cores. Surprisingly, having testing and formatting built into the tooling is also a huge win after spending years debating and changing choices in scripting land. Go is the new PHP/Node.js and Rust is the…

Agreed 100%. I've used a bunch of languages over the years: C, C++, C#, VB, Perl, Java/Groovy/Kotlin, Javascript, Lua, Ruby, PHP, Python and Go. All fairly mainstream and I'm not going to start railing on the ones I don't like. . . so let's just say Python was the first language that I loved and Go is my current favorite.

For me, readability, simplicity and having compile time checks are wonderful. Go feels like a better Python. I still enjoy using Python but "runtime is funtime" even with type hinting and linting and everything else.

I am also a sucker for good tooling and a pleasant dev experience. Go has fantastic tooling. That being said, it has its warts and weak points. If I need to write something quick and dirty, I prefer Python. If I need to parse JSON and I don't have an easy way to generate client code, I prefer Python.

There are some quirky bits in Go I don't particularly like e.g. the reversal of parameter type and name in function signatures. . . that just confuses me because I typically am using 2-4 different languages in any given week and Go is the weirdo in this regard. :)

I would be thrilled to see Rust become the dominant systems programming language some day. I'm planning to learn it as soon as it looks like the right choice for me - for most of my work, Python + Go + bash (I love and hate bash) are more than sufficient.

Post reply on HN