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

181–190 of 301 posts

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

#181

Post by Sohcahtoa82 »

klodolph wrote: post #41
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 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 my experience, this is because a lot of Python programmers are trying to write Java code in Python, carrying Java's awful and unreadable paradigms into a language that has no reason for them.

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

#182

Post by systemvoltage »

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…

> Dependency conflicts are common.

Is it really?

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

#183

Post by PeterisP »

gkop wrote: post #157
sliken wrote: post #147

Earlier quoted context omitted.

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?

If you disagree with the One Format, you can configure your IDE to show (or transform) the code in a different style while you're working with it, and have the One Format be the format for storage of the source.

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

#184

Post by bloblaw »

BipolarCapybara wrote: post #58
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 do you feel is a good alternative to Go?

Depends on your requirements. If you want statically compiled (AOT compiled), then I think Nim, Zig, or even Rust are good alternatives.

If you like the high-performance backend, then Java, Kotlin, Scala, or C# are great choices.

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

#185

Post by Sohcahtoa82 »

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

Whenever someone complains about Python's indentation-as-syntax, my mind translates it as "this programmer writes terribly formatted code". If your code is properly formatted, then indentation will never be a problem.

Copy/pasting large blocks, yeah, you can mess it up. But any editor worth using will let you select several lines of text and hit Tab or Shift-Tab to add/remove an indentation level, so fixing it only takes a couple seconds.

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

#186

Post by metaltyphoon »

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…

I have a feel that most people that use Go haven’t had a chance to write code for the Government where its audited.

Pulling third party packages would be instantly flagged and be put under high scrutiny.

Meanwhile with C# and .NET’s ungodly framework size you can just cruise along because it’s made by the creators of the language.

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

#187

Post by jvolkman »

0x008 wrote: post #176
jvolkman wrote: post #130

Earlier quoted context omitted.

What are you looking for in a monorepo solution?

probably managing requirements.txt of sub-projects and virtual environment management?

This is possible with existing general monorepo tools. We use Bazel for Python and other languages. With Python, we have a single requirements.txt at the root of the monorepo, but each target (a Python package, a module, an app, or some combination thereof) depends only on the packages it needs and the transitive packages of its dependencies.

Then if you need to do something like build a distributable archive for your app (say, to deploy it to lambda), you can use Bazel's dependency graph to get only the packages that the app transitively depends on.

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

#188

Post by pdimitar »

abyesilyurt wrote: post #154
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.

Just curious, which languages have better type systems?

Rust, Haskell, OCaml, and many others.

Golang's typing system is fairly half-done.

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

#189

Post by Spivak »

throwaway894345 wrote: post #173
spapas82 wrote: post #168

Earlier quoted context omitted.

Nowadays black is a defacto standard in python formatting.

Black is awesome for the Python ecosystem, but it's still painfully slow for large files compared to gofmt.

How large is large because I don’t think I’ve ever even noticed black’s delay on 10k files.

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

#190

Post by KronisLV »

uhtred wrote: post #161
KronisLV wrote: post #141

Earlier quoted context omitted.

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

I had no idea exiftool was writen in Perl!

Here's a few other tools that are written in Perl, sorted by GitHub popularity: https://github.com/EvanLi/Github-Ranking/blob/master/Top100/...

Actually, that repo has lists like this for most languages: https://github.com/EvanLi/Github-Ranking

Post reply on HN