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

241–250 of 301 posts

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

#241

Post by prepend »

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.

It’s not much of an issue as long as you document your third party packages and versions.

It’s all going through an SA&A process that will check your c# framework as well as your random package downloaded from the interweb.

(based on the decent amount of audited government work done using tons of third party libraries. Just try doing anything in data science without third party packages)

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

#242

Post by brobinson »

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?

It's easier to list which ones don't at this point. The Go team ignored the last 50 years of improvements in type systems.

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

#243

Post by bornfreddy »

snapetom wrote: post #210
mb7733 wrote: post #169

Earlier quoted context omitted.

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

I'll bite. So null is just a special value one can assign to a pointer, marking it not used. In Go this is nil. Void means "absence of type" and is related to pointers only marginally - void* is a pointer to something we don't know a type of. In Go, I guess a pointer to interface{} would be the same? (Not quite, but close)

As for wild and dangling pointers (I would argue the are the same - pointers that show somewhere they shouldn't), fair point. Of course one would expect this from a language so many decades younger.

But none of these are pointer "types" (far and near arguably are - iirc they determine the size of a pointer - but these four are not). I hope the question on the interviews are posed differently, I for one wouldn't know what you mean.

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

#244

Post by gkop »

prepend wrote: post #240
gkop wrote: post #145

Earlier quoted context omitted.

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

In candor I dabbled in Go in 2016 and found the community leaders arrogant and rude. I hope the community has evolved since then to expect more from leaders, but would need to see evidence of this before touching Go voluntarily again.

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

#245

Post by xigoi »

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…

Nim has all these properties. (I'm not sure about threading because I don't use it much.)

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

#246

Post by 0x008 »

jvolkman wrote: post #197
0x008 wrote: post #192

Earlier quoted context omitted.

What about the opposite case? I have several python packages with one requirements.txt each. But for development I want to have a single “root” virtual env?

In that case it seems like you could just have one all_requirements.txt that includes the individual files like: -r package_a/requirements.txt -r package_b/requirements.txt etc.

yes I get it. Good point.

Is bazel also a good choice for managing the virtual environments of my developers? Do you have any examples?

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

#247

Post by sk1pper »

bloblaw wrote: post #184
BipolarCapybara wrote: post #58

Earlier quoted context omitted.

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.

Do you mean for production? Zig isn't production-ready. Nim is extremely niche. I'm kind of puzzled why I see these thrown around so much on HN. Sure, they're fine for a side-project, but they're pretty out there for anything mission critical.

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

#248

Post by erik_seaberg »

> Developer Productivity & Not Getting Too Creative

These stories seem to have an undercurrent of mistrusting the judgment of your expensive and carefully chosen staff. It’s not doing anyone any favors to force an expert to laboriously write out the same junk a novice would have.

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

#249

Post by Gordonjcp »

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…

> People would do well to skip Python and go right to another solution.

Okay, so what solution? What do you recommend? I'm guessing if you're qualified to make statements like your first paragraph, you can bring your wealth of skill and experience to the table and show us what we should be using.

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

#250

Post by slaymaker1907 »

I get frustrated with this nonsense that writing tons of boilerplate is somehow beneficial. As someone who actually reads a lot of code, no it isn't. I want to see the core logic, not an essay on how to iterate through an array. You can cut the bullshit code without resorting to cryptic Perl-like code.

Adding in more bullshit just gives me more code I have to read that I may not actually be interested in while also spreading out the code of interest.

In the horrific example code posted, all that should be there is the URL, that it is a GET, and parsing of JSON (maybe into struct). Or in other words, "fetch(url).then(resp => resp.json())" with some validation code elsewhere, though in this case it's just one field so validation of the whole response is probably unnecessary.

Post reply on HN