Live data from Hacker News

Why We Switched from Python to Go (2021)

softwareengineeringdaily.com

231–240 of 301 posts

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

#231
post #23

Earlier quoted context omitted.

It's been a while since I wanted something in Go that wasn't available, other than the obvious big-ticket items like NumPy which are ecosystems unto themselves. (Or, to put it another way, yeah, Go doesn't have NumPy, but neither does anybody else other than Python at this point.) YMMV, of course, but it's certainly not a routine occurrence.

If I understand correctly, numpy at least originally was a wrapper around some Fortran libraries. So you could get the same functionality and performance in Fortran. Am I missing something? Is there some way in which numpy is superior to, say, Linpack (other than not having to use Fortran to call it)? Is there anything unique about Python that enables this approach? Couldn't Go, say, do the same thing? Or C++?

Python has a GC based around reference counting, which is vastly easier to integrate with native code than languages with heavier runtimes such as Go, Java, C#.

C++ could give you equal or better performance, but it's not anywhere near as friendly to beginners as Python. Plus, the value of REPL-based programming for prototypes and experimentation is hard to overstate.

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

#232

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…

> extremely concise code (as long as you don't apply mainstream coding standards/style) I'm interested in this aspect! I discovered that I was able to write short scripts in PowerShell in a style I find readable, or I can add extra stuff (parameter annotations, mostly, IIRC) and it can stretch to look like the C# I see in Microsoft API documentation. I find that the idea just gets buried. So I need to revisit C#, to…

The language has evolved greatly in the last few years. With LINQ and generics it was already nice but add on all the recent syntax sugar and ideas stolen from F#.. and you can write very nice code.

Not all code will be though - we have a lot of Java-minded people in the community (who port Java libraries/frameworks) and they tend to be... ugly..

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

#233
post #86

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

Go was released in 2009, which is 13 years ago. Many companies have built significant portions of their stacks on top of Go....Twitch, Google, Uber, Lyft, Amazon, etc. It's widely used in industry and isn't going anywhere.

I worked at one of those places and helped rewrite components into Go ;) Sure, there were performance benefits but in my experience there was never a real business problem that Go solved that Python couldn’t.

All the people freaking out about performance didn’t realize that even in the Python days, half of our datacenters pretty much sat idle or severely underutilized. Computing is dirt cheap as long as you’re not renting a 15-year-old CPU from a Cloud Provider for 100x markup. The other thing is that engineers would frequently build things that were just wasteful or unnecessary, and sure, Go sped things up, but you could have changed the design instead of the language.

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

#234
post #110
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…

Why do you need maximum performance?

Logically, if you need maximum performance, you can't care about compile time.

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

#235
post #116

Earlier quoted context omitted.

As someone who has started side projects with very technical and opinionated friends, just stick with Rust. Make a decision, stick with it, ship it. If there's a real problem, change it after you have it up and running. There's no point in optimizing for millions of users if you have 0 users now.

yeah sure, I have zero user and well, it may be like that until my death :-) that project was an excuse for learning rust. But now I understant rust a bit more, well, I'm a bit scare to wait 45 sec on each build for a side project (ie a project I do on my very limited spare time) :-) but anyway, rust is really cool to work with (I have a python/C++/assembler/R background). The level of checking it does is really mind…

Try to debug where your compile times are going[1][2], but if you want a good rule of thumb: separate your crate into multiple if you can (that way incremental compilation will yield better results), switch to an alternative linker, like mold or lld, and use trait objects instead of generics (monomorphization can be expensive during compilation, while trait objects can be slower at runtime, but not enough to be worth it worrying about it).

[1]: https://fasterthanli.me/articles/why-is-my-rust-build-so-slo...

[2]: https://matklad.github.io/2021/09/04/fast-rust-builds.html

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

#236

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…

"Medium size codebase" means "bigger than a huge portion YouTube", which is in Python.

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

#237

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

> if someone doesn't know Go, then can still get up to speed and use the language extremely proficiently within a few months

Which combined with a new code base is very stressful. but this avoids the main point, which is

> Python has a very bad rap as a backend language,

its not a front end language really(discounting the transpiled JS web stuff). I know people dont like it, and that's fair enough, but its as good as virtually any other language for "backend stuff". Its perfectly possible to write low latency high scaling code in python, just as it is in go and rust.

Despite what people say, code is just a logic brush, how you hold it, and how toy paint with it determines how pretty the picture is.

Yes there are inherent defects that each language has, but once again part of being proficient is know how not to blow your feet off. If Goethe can make wonderful prose in german, you too can make good scalable backend code in python.

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

#238
post #218

Earlier quoted context omitted.

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.

I disagree. If you're managing programmers, you might be expected to have a bit of a clue about programming languages. If you can't tell how easy it would be for your people to pick up Go versus how easy it would be to pick up Lisp, you have no business managing programmers.

Well you can still manage programmers but you certainly shouldn't micromanage their technological choices then.

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

#240
post #145

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…

I’ve found it’s nice for detecting people who care about unimportant things.

I can’t imagine ever picking a language based on this feature and seems weird to even mention it.

This has never caused me a minute of headache and the only time I care is when conflicting styles are used in the same file.

I always thought it was kind of dumb of Go to care about this but don’t care enough to affect my language choice. I don’t use Go but am open if it’s a fit for a project.

I like that Python has that variability and let’s developer make decisions as they see fit.

I don’t want to talk to people about tabs and spaces unless we’re already friends and having a few beers.

Post reply on HN