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

141–150 of 301 posts

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

#141

Post by KronisLV »

uhtred wrote: post #106
KronisLV wrote: post #101

Earlier quoted context omitted.

> Go should have died?! didn't Go come out like yesterday? This is why I am hesitant to invest time in new hot thing languages. Actually it came out about 10 years ago, in one way or another: https://go.dev/doc/devel/release So it largely depends on what timescales you're comfortable with - some people switch stacks or learn new tech every 3-5 years, for others this cycle is slower or faster, also depending on the st…

> On an unrelated note, it would be pretty cool to have extremely slowly moving and stable languages, projects and tooling out there. To see maybe 3 or 4 releases in my entire lifetime and to have the next generation take over the burden. Then again, seeing how COBOL and FORTRAN are now, perhaps that sense of grandeur isn't worth the effort and old projects should just die. Isn't that Perl?

Kind of, though the whole Raku thing made everything a tad wonky.

Some of the nicer Perl software that I use currently is BackupPPC, which has been pretty solid despite the slightly subpar UI: https://github.com/backuppc/backuppc

And another interesting piece that I can think of was RemoteBox, which was pretty niche but still worked nicely: https://remotebox.knobgoblin.org.uk/?page=about

From the more popular packages, one should also mention exiftool, which was written in Perl: https://github.com/exiftool/exiftool

Probably also a lot of other pieces of software, though it doesn't seem like there's much of a large/active community around Perl, for example, have a look at: https://github.com/trending/perl?since=monthly and then compare it to something like: https://github.com/trending/go?since=monthly

In regards to other contenders, I think FreePascal/Lazarus should also be mentioned, since they're pretty stable, capable and perhaps some of the better ways to write desktop software!

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

#142

Post by hnov »

josephcsible wrote: post #119
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.

Indeed. My overall complaint about Go is that despite being a very new programming language, it hasn't incorporated a lot of lessons learned long ago (e.g., the billion dollar mistake). One of my favorite articles about Go is http://cowlark.com/2009-11-15-go/

As a PL Golang is very unremarkable and it does have a lot of special casing and a general lack of "orthogonality," in fact it reminds me of PHP in some ways.

However, that's completely missing the point: Golang brought CSP into the mainstream when most were still using CPS to scale beyond OS threads. The kind of people who rewrite services to get performance improvements and then write blog posts about it aren't gonna learn your complicated language (just like they're not gonna spend their time messing with gevent and profiling to scale their python): they're makers not PL researchers. Google rightly noticed that there's a huge gap between existing mainstream offerings on the ease of use-performance spectrum and filled it with a DSL for programming network services. It doesn't need to be fancy, it needs to allow someone with CS201 knowledge to set-up the codebase so that people with CS101 knowledge can write sequential code that talks to the network without callbacks, yield/async/await or any of that incidental cruft.

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

#143

Post by digisign »

RcouF1uZ4gsC wrote: post #77
klodolph wrote: post #41

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. The other issue with Python is that it uses indentation for scoping. Combine that with the fact that it is super easy to mess up indentation when you are moving code around via copy/paste and it is super easy to change the meaning (ie accidentally move a statement out of an if block)…

Indentation has never been a problem with any of the code bases I've ever used. Ok, maybe there was that one script with tabs in it from ~2003?

Not using a programming editor? I select the text and hit Tab or Shift+Tab, not exactly rocket surgery. The lack of redundant noise characters pays off every single day, where as odd indentation problems are a once-a-decade issue.

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

#144

Post by vips7L »

8organicbits wrote: post #24
yedpodtrzitko wrote: post #5

So they switched to Go from Python, because of following advantages: #1 Performance #2 Performance (to make the list longer I guess?) #5 Fast compile time... which is an advantage over Python how exactly? #7 Strong ecosystem... which brings us to disadvantage #1 - lack of frameworks (?)

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

Javac is extremely fast. It doesn’t have to do any optimizations.

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

#145

Post by gkop »

snorfalorpagus wrote: post #138
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?)?

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 Python to Go…

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

#146

Post by igouy »

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…

How fast to do what?

fwiw https://benchmarksgame-team.pages.debian.net/benchmarksgame/...

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

#147

Post by sliken »

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

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 formatted with gofmt is considered wrong/broken.

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

#148

Post by Gwypaas »

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…

Consider turning your crate into a workspace instead. That usually helps to keep the compile times manageable.

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

#149

Post by potta_coffee »

snapetom wrote: post #121
yedpodtrzitko wrote: post #5

So they switched to Go from Python, because of following advantages: #1 Performance #2 Performance (to make the list longer I guess?) #5 Fast compile time... which is an advantage over Python how exactly? #7 Strong ecosystem... which brings us to disadvantage #1 - lack of frameworks (?)

I'm surprised they didn't mention #1 implies a cost benefit, or maybe they don't use it at scale in certain areas that it matters. I worked with one company that switched from Python to Go. They went from twenty-one instances of their load-balanced API servers to seven, saving a few thousand dollars every month.

This is my favorite advantage of Go. It does the work faster with fewer resources. I know there are a lot of aesthetic complaints about the language but I don't care.

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

#150

Post by digisign »

caymanjim wrote: post #55
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 a pretty terrible language to work with. Tooling sucks. Dependency conflicts are common. There's no test framework/runner worth a damn. Web frameworks are inferior to those in most other languages. If you're doing data science things, it's hard to beat pandas/numpy. I get that those are popular in that community because the barrier to entry with Python is low. People who are just looking for a tool to solve…

Sounds like inexperience or confusion, to be honest. None of those are problems particular to Python. Meanwhile you did not mention any of Python's significant issues, such as performance or deploying end-user apps. But it is best-in-class for what it was originally designed for.
Post reply on HN