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

201–210 of 301 posts

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

#201

Post by foobiekr »

kjksf wrote: post #151
foobiekr wrote: post #136

Earlier quoted context omitted.

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

I regularly see both of the problems I mentioned when reviewing imported dependencies. Yes, the linters can help for your own code base, but something that forces correctness into all code is a big advantage over something that your dependencies may or may not bother with.

Most people, I admit, do not review their dependencies, but that in and of itself is a problem.

Your fmt.Printf issue is trivially addressed by implementing PrintfOrDrop() which wraps that - and if this was the way Go behaved, you can be certain the standard library would add these variants for conciseness.

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

#202

Post by didibus »

wiz21c wrote: post #110
bloblaw wrote: 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…

Go is slower than Rust. Rust allows you to go as fast as the metal can get you if you want.

But Go is still reasonably performant and has a reasonably low memory footprint. We're talking C#/Java level performance with C level memory footprint.

Rust is the next level up in performance.

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

#203

Post by digisign »

corrral wrote: post #128
iainmerrick wrote: post #40

Earlier quoted context omitted.

Hmm, I feel like that’s been the case for more than a couple of years. Java has been fast for well over 10 years, I’d say. But I think Java also still has the problem that it tends to use a ton of memory (unless you use it the fintech way, manually wrangling your data in arrays rather than using lots of objects). My subjective impression is that garbage collected languages have gone through a bit of a rise and fall o…

> Hmm, I feel like that’s been the case for more than a couple of years. Java has been fast for well over 10 years, I’d say. It got the reputation in part because once upon a time Java programs were noticeably slow and heavy on resource use, no matter how many times Java fans posted micro-benchmarks of Java finding digits of Pi to "prove" Java was fast and we must all be imagining things. In actual fact, in the real…

Java was slow at startup, speeding up as it is run. Those two were both improved, with 1000x faster hardware being the final leg of the stool.

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

#204

Post by philwelch »

gkop wrote: post #131
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…

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

autopep8 isn't deterministic enough. If you were going to autoformat your Python you'd want to use Black, which has the same philosophy as gofmt.

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

#205

Post by hardware2win »

systemvoltage wrote: post #174
radicalbyte wrote: post #171

I have experience with both (and a lot of other languages) and honestly - I wouldn't move from Python to Go. I'd move from Python to the very latest version of C#. You get far better tooling, excellent performance, the ability to write extremely concise code (as long as you don't apply mainstream coding standards/style) and a better range of libraries for most situations than Go. More chance for re-use too (i.e. same…

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.

In c# you can edit code at fly when debugging, jumping between lines, evaluate expr and more like conditional breakpoints

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

#206

Post by bloblaw »

didibus wrote: post #200
bloblaw wrote: 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…

Ya, and if you look at the language space, there's nothing else that offers #1. That set of features isn't related to the language itself (though the language was designed to allow those features). This is where Go is appealing, it's not the language itself, it's the properties it brings with it. Cross-compilation, multi-spec, reasonable performance and low memory footprint. Single binaries. And I'd add fast compilat…

That's a great point, and one I hadn't considered. One language feature that Go brings is first-class multi-threading and communication amongst and with child threads.

The only languages I know that can compete with Go with similar properties are Nim, Zig, and Rust. I'd like to include Delphi / Free-Pascal, but cross-compilation can be a bit of headache at times.

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

#207

Post by dgb23 »

sliken wrote: post #156
AnimalMuppet wrote: post #133

Earlier quoted context omitted.

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.

I have a bit of a different take on this.

They mentioned it was a rewrite that happened in a couple of days in a shop that uses C++ and Python (at least). We can assume it was a small to medium utility program.

Someone who can write C++ and Python professionally will get up to speed with Go in a few days. This shouldn't be a hiring issue. The cost of rewriting it again in C++ can easily be higher and apparently was a huge PITA. Go is not some obscure language, it is literally designed to be accessible by anyone with basic programming experience.

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

#208

Post by gosukiwi »

KronisLV wrote: post #94
atx42 wrote: 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's wrong with Angular? It being largely "batteries included" seemed pretty nice and I really liked the fact that TypeScript was a first class citizen - React and Vue both feel like it's been kind of tacked on, especially when a lot of additional libraries out there don't really have proper bindings. That said, personally I also think that React kind of went downhill for a bit due to the hooks (after seeing a few…

No matter how hard I try, I just can't like React. I prefer Angular, Vue, even Ember. React feels like a downgrade to me.

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

#209

Post by kortex »

IshKebab wrote: post #104
mixedCase wrote: post #32

Earlier quoted context omitted.

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.

But still better than Python's.

Despite its warts, Python's type system is at least comparable to Go, and better in several areas. The type inference works really well much of the time without any assistance, you can use tools like pyre to generate types for untyped code, as well as tools for discerning types through running the application.

Heck, you can even use HKTs in Python if you are willing to install a plugin/library.

https://returns.readthedocs.io/en/latest/pages/hkt.html

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

#210

Post by snapetom »

mb7733 wrote: post #169
snapetom wrote: post #111

Earlier quoted context omitted.

The two things I always bring up in interviews on why I like Go: 1) Easy to use pointers. There's just pointers, not like C where you can have anywhere from 4 to 8 different types depending on your platform. And no, pass by reference vs. value are not the same as pointers. 2) Very simple to use concurrency.

> 1) Easy to use pointers. There's just pointers, not like C where you can have anywhere from 4 to 8 different types depending on your platform. And no, pass by reference vs. value are not the same as pointers. Do you mean C++? Or am I confused?

Null, void, wild, dangling in core C. DOS also had far, near. I believe one of the Windows Visual something platforms had extensions that added another three or four.
Post reply on HN