Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Learning Go as a Python Developer: The Good and the Bad

new.pythonforengineers.com

Post reply on HN
Print view View original

81–90 of 269 posts

Re: Learning Go as a Python Developer: The Good and the Bad

#81

Post by nathants »

jerf wrote: post #49
nathants wrote: post #33

i dragged my feet on go for a long time. i also thought that skipping go and moving to rust was the play. a few years later, i still write python often, but i don’t build systems with it. python i now use like bash, to glue things together and automate random things. it’s a fantastic language and i will never drop it. the verbosity of go is the biggest hurdle for a pythonista. the thought of giving up context manager…

Obviously the closest thing in the general sense to Python is Ruby. But I think a case can be made that in practice, the closest thing to Python on the static language side is Go. The list of superficial differences is a mile long, I don't deny, nor will I exhaust my audience's patience with actually writing them out. But the interface orientation of Go captures the essence of how you design in Python surprisingly we…

very true! to be a WriteCloser[1], you have to be able to Write[2] and to Close[3]. quacking confirmed.

1. https://pkg.go.dev/io#WriteCloser

2. https://pkg.go.dev/io#Writer

3. https://pkg.go.dev/io#Closer

Re: Learning Go as a Python Developer: The Good and the Bad

#82

Post by paulsef11 »

ActorNightly wrote: post #6

>sharing your code is even pain with colleagues even if they are using the same operating system, mainly because the Python requirement file doesn't pin dependencies, wat? Pretty sure you can use == in requirements.txt Also, its very possible, and quite easy to just include the code for the library in your package, which effectively "locks in" the version. We did this all the time when building AWS lambda deployments…

There's lots of cases where you wouldn't want to pin your requirements.txt, the main one being if you're authoring a package. You need to leave the versions unpinned, preferably just bound to a major version, allowing some variability for the users of your package in case there's a shared dependency. I have a feeling that's what the author is describing here, because Poetry solves this dilemma by introducing a poetry.lock file which pins the dev versions of all the dependencies, but publishes a package with unpinned deps.

Re: Learning Go as a Python Developer: The Good and the Bad

#83

Post by takeda »

aidenn0 wrote: post #65

I only use python casually, but it seems to me that python library authors are always refactoring and breaking interfaces. Recently, there was a bug in a second order dependency, and the version that fixed this bug was after a version that moved a function into a submodule. So I had to make a local patch to my dependency that changed all of the imports. Was the new interface more consistent? Yes, but could they have…

I think that depends on library. The ones I use seem to use appear to not do that. In fact I think I actually have seen that more in Go. What goes for Go though is that you won't compile your code until you fix it. In Python you could use mypy, but unfortunately is optional and will work only if you and library author uses annotations.

Re: Learning Go as a Python Developer: The Good and the Bad

#84

Post by atwood22 »

Areibman wrote: post #51

> I especially struggled with the DynamoDb library for Go; so much so I wrote a Python script to query Dynamodb, and called it from Go. This seems like a compelling enough reason to stick with Python

The official AWS SDK contains a perfectly good DynamoDB client, especially when combined with this utility library (also part of the AWS SDK): https://docs.aws.amazon.com/sdk-for-go/api/service/dynamodb/...

Re: Learning Go as a Python Developer: The Good and the Bad

#85

Post by raffraffraff »

throwawaymaths wrote: post #41
jeremydw wrote: post #38

Earlier quoted context omitted.

This comment section itself clearly shows how crazy dependency and environment management is in Python. In this thread alone, we've received instructions to... - poetry - "Just pin the dependencies and use Docker" - pip freeze - Vendoring in dependency code - pipreqs - virtualenv This is simply a mess and it's handled much better in other languages. I manage a small agency team and there are some weeks where I feel l…

Now try installing tensorflow. Treat yourself to ice cream if you get it to install without having to reinstall Linux and without borking the active project you're on.

And unless things have gotten a lot better in the 2 years since I last did `pip install numpy` on ARM, prepare for a very long wait because you'll be building it from source.

Re: Learning Go as a Python Developer: The Good and the Bad

#86

Post by giantrobot »

ActorNightly wrote: post #6

>sharing your code is even pain with colleagues even if they are using the same operating system, mainly because the Python requirement file doesn't pin dependencies, wat? Pretty sure you can use == in requirements.txt Also, its very possible, and quite easy to just include the code for the library in your package, which effectively "locks in" the version. We did this all the time when building AWS lambda deployments…

The issue is transitive dependencies. A dependency you pin isn't guaranteed to pin its own dependencies. A bug somewhere in a grandchild dependency can manifest for you even if you have a version pinned but the dependency did not.

It's not automatically a problem but it certainly can become one.

Re: Learning Go as a Python Developer: The Good and the Bad

#87

Post by atwood22 »

I don't understand how the author struggled to find a good DynamoDB library. The official AWS SDK has a very useable DynamoDB client and provides utility classes for marshaling and unmarshaling Go types: https://docs.aws.amazon.com/sdk-for-go/api/service/dynamodb/...

Re: Learning Go as a Python Developer: The Good and the Bad

#88

Post by MonkeyMalarky »

jjoonathan wrote: post #68
MonkeyMalarky wrote: post #59

Earlier quoted context omitted.

Don't forget Anaconda because you're on windows and have no idea how to compile random packages that are really C++ code with Python bindings!

Solving environment | Solving environment / Solving environment - Solving environment \ Solving environment | ... One day it takes 10 seconds, next month it takes 10 minutes, and the month after that it takes 30 minutes and then fails entirely.

That's half of why from 2017 to 2021 I had a yearly "uninstall Anaconda and start fresh" routine. The other half is because I'd eventually corrupt my environments and have no choice but to start over.

Re: Learning Go as a Python Developer: The Good and the Bad

#89

Post by bogeholm »

37ef_ced3 wrote: post #52
returningfory2 wrote: post #30

> I had heard of Go for many years, but never stuck with it; it gets constant negative press on Hacker News/Reddit I think on Hacker News it's really fashionable to criticize Go, and this has led to a culture where Go gets significantly more negativity than it deserves. As technologists, one of our most important jobs is to see through such fashions and judge languages/tools/technologies based on their actual merit.…

As an engineer who uses Go and appreciates it as a replacement for most purposes where you might use C or C++, the complaints just seem bizarre. You've got people who argue against explicit error checking and people who don't understand the important role of nil pointers and people who don't see the massive net win of garbage collection in concurrent programs, and so on. Endlessly. It feels like a waste of time defen…

> Natural Born Killers … Primus …

We should have a beer sometime!

Re: Learning Go as a Python Developer: The Good and the Bad

#90

Post by aidenn0 »

takeda wrote: post #83
aidenn0 wrote: post #65

I only use python casually, but it seems to me that python library authors are always refactoring and breaking interfaces. Recently, there was a bug in a second order dependency, and the version that fixed this bug was after a version that moved a function into a submodule. So I had to make a local patch to my dependency that changed all of the imports. Was the new interface more consistent? Yes, but could they have…

I think that depends on library. The ones I use seem to use appear to not do that. In fact I think I actually have seen that more in Go. What goes for Go though is that you won't compile your code until you fix it. In Python you could use mypy, but unfortunately is optional and will work only if you and library author uses annotations.

I don't use Go at all, but TFA was concerned with pinning dependencies, and stuff like this makes dependency pinning much more important
Post reply on HN