Live data from Hacker News

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

new.pythonforengineers.com

161–170 of 269 posts

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

#161

Earlier quoted context omitted.

When I was a Python dev, I never saw that happen in ten years or so of work. Pip freeze and virtualenv just worked for me. I will say, though, that this only accounts for times where you’re not upgrading dependencies. Where I’ve always run into issues in Python was when I decided to upgrade a dependency and eventually trigger some impossible mess.

Upgrading dependencies is fraught in all languages.

Haven't had any issues in Go so far.

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

#162

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…

I've rebuilt multiple projects written in python/php/perl originally in go instead and it's just great how much more performant these comparatively are... Just way lower resource usage and the programs work faster now. It's worth it to consider the switch. One of the things that go is really good for is the amount you can get done without having to deviate that far from the standard library. A lot of churn in updatin…

i agree, performance and stdlib are very nice benefits.

i enjoy refactoring with type safety and using gopls and ide completion instead of external docs. i used to constantly read boto3 docs in a browser, now i use gopls in my ide.

frontend dev can be sane[1] too! my default setup is a go lambda with an spa frontend inlined into an html file.

the lambda zip contains two files:

- ./main

- ./index.html.gz

1. https://github.com/nathants/aws-gocljs

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

#163
post #5

I hated the "damnable use requirement" (the error you get on unused imports) for years, but I've been keeping a count of how many bugs they've caught (I was surprised the first time this happened) and I'm up to 3-4 now. What people who code in Go seriously do is just hook `goimports` up to their editor, and then never think about this again.

Every time someone mentions this fact I think about Zig having recently added this "feature" and my blood boils.

Unused imports or variables being errors is the most idiotic and overrated paper cut ever implemented in compilers. In no universe it is a good idea.

I posit there are actually no or very few bugs it catches, and in exchange it ruins people's iterative development, flow and hyperfocus states when experimenting, because poor compiler can't deal with an unused import, fix it now or else. Now we need an IDE setup to deal with this? And why the hell isn't this a feature that can be turned off?

If only I could throw the person that invented this crap into the flaming sun.

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

#164
post #118

Earlier quoted context omitted.

- Poetry is a 3rd party package manager, I'm sure it's great but it's not widely used (yet) - Pip freeze just pins all dependencies at once to requirements.txt - I don't know what "vendoring in dependency code" means - I've never used pipreqs in my life (and 80% of my work has been in Python) - Virtualenvs are just a convenient way to keep project runtimes separated And for 90% of Python projects in existence the fol…

"Vendoring" means including the library in your package. So instead of listing it in requirements.txt, you copy the code of the library.

You can get that by bundling up your venv. When you install a package is a venv it installs it into that venv rather than the system. As far as the venv is concerned it is the system Python. Unfortunately passing around a venv can be problematic, say between Mac and Linux or between different architectures when binaries are involved.

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

#165

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…

The real issue is that you can't have multiple versions installed at the same time. if you could import numpy==3.2 it'd solve many problems.

Granted, I'm more of a hobbiest than a dev, but I think this is part of the problem that virtualenvs are supposed to help solve. One project (virtualenv) can have numpy==3.2, and another can have numpy==3.1. Maybe I'm naive, but it seems like having a one project with multiple versions of numpy being imported/called at various times would be asking for trouble.

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

#166
post #158
post #154

Earlier quoted context omitted.

> > - pip freeze > all this does it just lists currently installed packages in a form that can be automatically read by pip Are you referring to version specifiers[1] being optional or is there something more to versions that I don't understand? PEP 440 is a wall of text, maybe I should get around to reading it sometime. [1] https://packaging.python.org/en/latest/glossary/#term-Versio...

I mean pip freeze outputs packages and their versions in machine readable form that can be read and installed by pip install -r requirements.txt

This whole chain started with someone pointing out the author doesn't seem to realize you can pin versions[1]. I'm just confused how people seemed to end up questioning what pip freeze does.

[1] https://news.ycombinator.com/item?id=32141573#32142190

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

#167
post #96

Earlier quoted context omitted.

Sometimes I feel people are using Python very differently than me. I just use pip freeze and virtualenv (these are Python basics, not some exotic tools) and I feel it works great. Granted, you don't get a nice executable, but it's still miles ahead of C++ (people literally put their code into header files so you don't have to link to a library), and even modern languages like rust (stuff is always broken, or I have s…

Comparing anything to C++ is a very low bar. I have rarely encountered issues in rust. Most rust crates stick to semver so you know when there will be a breaking change. My rust experience with Cargo can only be described as problem free(though I only develop for x86 linux). As for pip freeze and virtualenv things start to fall apart especially quickly when you require various C/C++ dependencies (which in various par…

> pip freeze and virtualenv things start to fall apart especially quickly when you require various C/C++ dependencies

Yes 100 times. That can be incredibly frustrating. During the last year I've used a large (and rapidly evolving) C++ project (with many foss C/C++ dependencies) with Python bindings. We've collectively wasted sooo many hours on dependency issues in the team.

Long compilation times contribute considerably to slow down the feedback loop when debugging the issues.

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

#168
post #118

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…

- Poetry is a 3rd party package manager, I'm sure it's great but it's not widely used (yet) - Pip freeze just pins all dependencies at once to requirements.txt - I don't know what "vendoring in dependency code" means - I've never used pipreqs in my life (and 80% of my work has been in Python) - Virtualenvs are just a convenient way to keep project runtimes separated And for 90% of Python projects in existence the fol…

Sounds like someone has never been asked to clone and run software targeting Python 3.x when their system-installed Python is 3.y and the two are incompatible.

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

#169

Earlier quoted context omitted.

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.

Are you using conda-forge? Solving from over 6TBs of packages can take quite a while. Conda-forge builds everything . This isn't a criticism, but because of that the number of packages is massive.

"You can't use the big channel with all the packages because it has all the packages" isn't an exoneration, it's an indictment.

To answer your question: yes, we were using conda-forge, and then when it stopped building we moved to a mix of conda and a critical subchannel, and then a major GIS library broke on conda and stayed that way for months so we threw in the towel and just used pip + a few touch-up scripts. Now that everyone else has followed suit, pip is the place where things "just work" so now we just use pip, no touchups required.

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

#170
Having done both Python and Go for quite some time now, yes, Python modules are a mess, but it wasn’t so long ago that the same could be said for Go (glide-> dep -> go mod anyone else?) Go mod is finally maturing, but there are still some painful edges as well.
Post reply on HN