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

211–220 of 301 posts

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

#211

Post by joebob42 »

uhtred wrote: post #86
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.

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. I swear in 20 years everything important will still be written in C, PHP, Perl, C#, Java, Python (how could I forget JavaScript).

I think it should have died when it came out. Javas way older but I'd rather use that.

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

#212

Post by d0mine »

claytonjy wrote: post #73
caymanjim wrote: post #55

Earlier quoted context omitted.

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…

Of things you mention I feel the testing part the most. I started python recently enough that I've only ever used pytest, but something about it just feels too...magical? I'm holding out hope for a new test framework that I'd feel more at home with, but I'm not aware of any such projects; do they exist?

If "too magical" is the only complaint that is mentioned, then pytest is not too bad :)

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

#213

Post by d0mine »

claytonjy wrote: post #27
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.

I don't know who coined it but I love the term "second-best language for everything" when describing python. The ecosystem is so broad you can almost always find tools to do whatever you need, and it lets folks jump between domains simply by knowing the language.

What is the better alternative for being glue/executable pseudo-code?

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

#214

Post by christophilus »

metaltyphoon wrote: post #186
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.

I've worked extensively in C# (for the first 15 years of my career, it was my primary language), and built a handful of projects in Go. They're mostly comparable in terms of dependencies. The average C# project I was on-- in the last few years I worked in it-- had roughly the same number of Nuget dependencies as the Go projects I've seen.

Both languages are great in this regard-- you can do a whole lot without 3rd parties.

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

#215

Post by tbarbugli »

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…

co-founder and CTO of Stream here. I did not write the article but I was very involved with the decision process.

Your assumption is wrong, we did not pick a different language just for fun or because we wanted to learn something new :)

Python was just not the language we needed for our APIs, we tried hard to make it work but eventually we looked at alternatives that would allow us to keep things simple and performant. End result was better latencies, a much simpler architecture (less async/MQ work) and processes that would eat a fraction of RAM and CPU compared to Python.

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

#216

Post by d0mine »

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 opposite is more plausible: it is rare when your performance issues are distributed evenly through the code.

The very words such as bottleneck/hotspot indicate that it is common to get the most benefit by optimizing small parts of the code.

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

#217

Post by philwelch »

Sohcahtoa82 wrote: post #185
RcouF1uZ4gsC wrote: post #77

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

> 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

...or has equivalent functionality that doesn't require the mouse ;)

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

#218

Post by sliken »

dgb23 wrote: post #207
sliken wrote: post #156

Earlier quoted context omitted.

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…

As a programmer I agree, but as management that's a hard thing to tell. If you were the boss would you allow Lisp? Scheme? Erlang? It sounded like a pretty important piece of code, even if small. The complaints about being forced to do C++ and how painful that process was shows that it's at least non-trivial.

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

#219

Post by gosukiwi »

usrn wrote: post #139
erokar wrote: 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. 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.

Forcing people to behave is the opposite of Python's approach, afterall, [we are all consenting adults here](https://mail.python.org/pipermail/tutor/2003-October/025932....)

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

#220

Post by gosukiwi »

ptx wrote: post #122
claytonjy wrote: post #73

Earlier quoted context omitted.

Of things you mention I feel the testing part the most. I started python recently enough that I've only ever used pytest, but something about it just feels too...magical? I'm holding out hope for a new test framework that I'd feel more at home with, but I'm not aware of any such projects; do they exist?

You could give the built-in unittest module [1] a try. It's less magical (although also less flexible) and many of its old limitations that people used to cite as advantages of pytest (e.g. built-in test discovery) have since been fixed. [1] https://docs.python.org/3/library/unittest.html

I'm relatively new to Python, coming from Ruby and JS, and the built-in unittest module is just fine. I haven't had any issues with it, besides the documentation for setting it up following the conventions is really hard to find. But once it works, I like how simple it is. If you know OOP you'll feel right at home. You can simply create your own test case classes if you want to re-use stuff. No magical bloated configuration.
Post reply on HN