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

191–200 of 301 posts

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

#191

Post by Sohcahtoa82 »

kortex wrote: post #165
Sohcahtoa82 wrote: post #155

Earlier quoted context omitted.

> I still enjoy using Python but "runtime is funtime" even with type hinting and linting and everything else. I'd love to see a s̶t̶r̶o̶n̶g̶ statically-typed Python that could throw type errors at compile time. I've only taken advantage of the duck typing once, and the way I did it was a massive code smell and I ended up refactoring it out anyways.

You mean statically typed? Python is already strongly typed. Try running it through mypy with all the strict options. If you can get it to 100% pass and don't try to "cheat" the system too much with dynamic casts, I think you will find runtime type errors to be very rare.

> You mean statically typed? Python is already strongly typed.

Err...yes. I forget that "strong" and "static" are not the same and that "strong" and "duck" are not mutually exclusive.

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

#192

Post by 0x008 »

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

Earlier quoted context omitted.

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

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?

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

#193

Post by bsdnoob »

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.

Go has a pretty decent standard library, you can go really far without adding a single third party library.

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

#194

Post by akira2501 »

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.

I have yet to find a language where cross compiling is as easy and simple as it is with Go. It's a first class feature of the language and for my use case, it makes it an obvious choice.

Programming is about managing tradeoffs to solve real problems, not building a perfect ideological environment to write code in.

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

#195

Post by returningfory2 »

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?

The point of view in Go is that the specific format is irrelevant. The design choices made by the format don't matter. What you think is "nice" code and what someone else thinks is "nice" code doesn't matter. The benefit of formatting has nothing to do with making the code conform to anyone's definition of "nice". It's just about having a format that's passable and that is then applied uniformly.

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

#196

Post by mixedCase »

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?

TypeScript, Kotlin, Scala, Haskell, Rust, Swift, modern Java, C#, F#, OCaml, Reason, Elm, PureScript,... it's a long list.

I'd also count Python with MyPy, but having a mostly untyped ecosystem means you can't take much advantage of it.

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

#197

Post by jvolkman »

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

Earlier quoted context omitted.

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

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.

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

#198

Post by metaltyphoon »

polskibus wrote: post #47

I'd love to read an objective comparison between Go and C#/NET6 wrt to building services.

Its hard to see because most post won’t try to use real world code.

An objective comparison would need:

* Authentication n Authorization

* Rate limiting

* Configuration loading

* OAuth integration

* Websockets

* Retry policies

* HTTPs (yes… all the way to uService)

* Testing

* Benchmarks

* Cloud tooling (integration)

* C interop

* Service Caching

* Middleware authoring

And many more…

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

#199

Post by kortex »

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…

> Python is a pretty terrible language to work with.

That's just like, your opinion, man.

> Tooling sucks.

Not in my experience. Lot of tools could be better, but I would not say there is a lack of un-sucky tooling at this point. Poetry and pytest in particular are largely excellent to work with.

> Dependency conflicts are common.

This has been a problem historically but it's leagues better today, especially with lockfiles.

> There's no test framework/runner worth a damn.

Um, what? Unittest (stdlib), Pytest, tox, nose, hypothesis, schemathesis, and a few other lesser known ones.

> Web frameworks are inferior to those in most other languages.

FastAPI is pretty amazing. Flask is well regarded as a good intro framework. Django I'm not a fan of personally, but many love it.

> If not for data science and academia keeping it alive, it'd be disappearing along with Perl.

And machine learning. And web dev. And sysadmin scripting.

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

#200

Post by didibus »

bloblaw wrote: post #97
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 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 compilation times.

Honestly it needs more competition that offers those same properties, because I'd love to have more choice of language (syntax + semantics), but get the same properties. But for now, you have to use Golang if you want something that gives you all those properties and that's just where Golang differentiates itself.

Post reply on HN