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

151–160 of 301 posts

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

#151

Post by kjksf »

foobiekr wrote: post #136
alephnan wrote: post #125

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

There are lints for that, if that's really a big issue for you.

I don't want that because I don't want to litter my code with `_ = fmt.Printf()`

`Printf()` is a very common function. It returns an error. I don't care about an error from `Printf` and I don't want to make my code more ugly to avoid bugs I'm not writing in the first place.

I've been writing Go code since before v1. I really can't recall a case where I wrote a bug because I forgot to handle an error.

I get how you can forget something you do once a month.

I don't get how you can forget to handle an error in Go when that's something you do every couple of lines of code written.

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

#152

Post by BobbyJo »

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…

> "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 to speed and use the language extremely proficiently within a few months, unlike any of the other languages you listed.

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

#153

Post by BobbyJo »

gkop wrote: post #145
snorfalorpagus wrote: post #138

Earlier quoted context omitted.

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.

What’s the material consequence of this lack of uniformity? When a new Python developer joins a team, is it painful or costly to accommodate their stylistic preferences? I see a single standard as a nice to have, but as long as the language has adequate tooling with reasonable defaults and quality linting, this just doesn’t seem like a big deal. Curious to learn first hand experience of those that switched from Pytho…

The biggest issue I've felt with Python formatting is you run into build/versioning issues that basically never happen with gofmt. Also, some tools don't do everything you need, and you need multiple, like having to combine isort and black.

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

#154

Post by abyesilyurt »

mixedCase wrote: post #32
8organicbits wrote: post #24

Earlier quoted context omitted.

> #5 Fast compile time... which is an advantage over Python how exactly? Compiled code can have fewer runtime errors, that's a big win. I read this as golang is better than python because it's compiled and golang is better than Java and C++ because the compiler is fast.

The advantage then is "the type system", not "fast compile time". And as far as type systems go, Go is one of the worst in mainstream usage.

Just curious, which languages have better type systems?

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

#155

Post by Sohcahtoa82 »

tech_tuna wrote: post #140
Xeoncross wrote: post #70

Earlier quoted context omitted.

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 be…

> I still enjoy using Python but "runtime is funtime" even with type hinting and linting and everything else.

I'd love to see a s̶t̶r̶o̶n̶g̶ statically-typed Python that could throw type errors at compile time. I've only taken advantage of the duck typing once, and the way I did it was a massive code smell and I ended up refactoring it out anyways.

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

#156

Post by sliken »

AnimalMuppet wrote: post #133
kabdib wrote: post #48

Earlier quoted context omitted.

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?

Heh, imagine you have 8 C++ programmers, then one rewrites some critical piece in Go ... and then leaves. Now you have to find a go programmer (from a much smaller pool). How do you find a good one? It's not going to be easy without some good Go developers on the interview panel. Say you hire one, he goes on vacation for 2 weeks, something important breaks and you need a 2nd go programmer, etc.

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

#157

Post by gkop »

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…

Thanks! More curiosity:

How do humans that disagree with the One Format deal with it? Do they self-select away from Go?

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

How does the format evolve over time as the community discovers improvements (if it does), and what are the implications for code on github?

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

#158

Post by sliken »

stayfrosty420 wrote: post #28
papito wrote: 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…

Very surprised this is getting downvoted, I think in two years from now everyone will be singing this exact song when the next flavour of the month arrives.

Heh, flavor of the month ... for a 12 year old language.

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

#159

Post by digisign »

IshKebab wrote: post #91
ranjanprj wrote: post #18

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.

There's an element of truth to that in some cases, but it's mostly just something Python fans say to excuse the fact that Python is so slow. It's not true for two reasons: 1. In practice writing a prototype in one language, then completely scrapping it and rewriting it in another language almost never happens for fairly obvious reasons. 2. The "slow bits" of a Python program are rarely neatly concentrated in a few pa…

The point is you're very productive up front, and have a number of choices with the rest of your time. Few rewrite from the ground up because they don't need to.

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

#160

Post by radicalbyte »

ranjanprj wrote: post #18

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 the Visual Basic of 2022. Easy to understand, easy to learn and very forgiving. Much nicer than the main alternative (Javascript).

Unskilled developers can be very productive very quickly. Skilled developers can write some really beautiful code with it.

Has issues with the ecosystem - it's a headache with M1 and far too many Python projects are just broken. The latter is because it's used by scientists / students so is more a function of the community than the language.

I use it as a scripting language, which it excels in as long as you don't have many dependencies.

Go: fast and cgo is really powerful. The language itself is a little verbose for my tastes though - it makes the simple verbose. The package management story is weird (import the source code from github). Better than having the dependency hell of npm or Python though.

Post reply on HN