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

151–160 of 269 posts

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

#151

Post by smeagull »

okasaki wrote: post #96
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…

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…

If I did that I'd have no harddrive space left due to how large python dependencies are.

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

#152

Post by smeagull »

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.

I'd be too fat from all that icecream.

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

#153

Post by sph »

takeda wrote: post #120
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…

Keep in mind that Python is 31 year old (it's even older than Java) it was created around the same time as world wide web. So it started when no one even knew they would need dependency management and evolved over time from people posting packages on their home pages, to a central website to what we now call PyPI. Similarly the tooling and way of packaging the code evolved. What you described are multiple tools that…

Being 31 years old doesn't preclude having a decent, official and reproducible way of installing packages in 2022. That's just a bad excuse to justify subpar package managers and terrible governance around this problem.

Package management is pretty much a solved problem, no matter how old is your language. It smells to an outsider like me like a lot of bike-shedding and not enough pragmatism is going on in Python land over this issue. Has a new BDFL stepped up after Guido left?

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

#154

Post by tmh88j »

takeda wrote: post #120
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…

Keep in mind that Python is 31 year old (it's even older than Java) it was created around the same time as world wide web. So it started when no one even knew they would need dependency management and evolved over time from people posting packages on their home pages, to a central website to what we now call PyPI. Similarly the tooling and way of packaging the code evolved. What you described are multiple tools that…

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

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

#155

Post by FridgeSeal »

sph wrote: post #153
takeda wrote: post #120

Earlier quoted context omitted.

Keep in mind that Python is 31 year old (it's even older than Java) it was created around the same time as world wide web. So it started when no one even knew they would need dependency management and evolved over time from people posting packages on their home pages, to a central website to what we now call PyPI. Similarly the tooling and way of packaging the code evolved. What you described are multiple tools that…

Being 31 years old doesn't preclude having a decent, official and reproducible way of installing packages in 2022. That's just a bad excuse to justify subpar package managers and terrible governance around this problem. Package management is pretty much a solved problem, no matter how old is your language. It smells to an outsider like me like a lot of bike-shedding and not enough pragmatism is going on in Python lan…

No but there’s a walrus operator!

Not sure anyone was asking for that, unlike a fix for packaging issues.

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

#156

Post by mountainriver »

Zopieux wrote: post #132
mountainriver wrote: post #124

> The libraries for Go aren't as good as for Python– certainly, the documentation is lacking Huh, Go has some of the best autodoc features of any language. Also the library assertion is insane to me. I switch back and forth from Go to Python all day and generally Go has more stable better maintained libs

Sadly I agree with the author on the general feel of Go libraries. I can feel the language design itself and non-written philosophical identity of Go strongly affects what APIs people write in it. Most often, they suck. They feel monolithic, unforgiving, and impossible to extend. I don't belive we can only blame the lack of generics for that, it runs deeper. On documentation, I've never seen a language community that…

The bare bones godoc is generally fine because the language is so easy. Python needs the examples because most of the libraries have no types so you would have no idea whats happening without examples

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

#157

Post by bsder »

jeremydw wrote: post #38
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…

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…

> This is simply a mess and it's handled much better in other languages.

I don't agree.

The problem is simply that Python encompasses a MUCH larger space with "package management" than most languages. It also has been around long enough to generate fairly deep dependency chains.

As a counterexample, try using rust-analyzer or rust-skia on a Beaglebone Black. Good luck. Whereas, my Python stuff runs flawlessly.

What many newer languages do is precompile the happy paths(x86, x86-64, and arm64) and then hang you out to dry if that's not what you are on.

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

#158

Post by takeda »

tmh88j wrote: post #154
takeda wrote: post #120

Earlier quoted context omitted.

Keep in mind that Python is 31 year old (it's even older than Java) it was created around the same time as world wide web. So it started when no one even knew they would need dependency management and evolved over time from people posting packages on their home pages, to a central website to what we now call PyPI. Similarly the tooling and way of packaging the code evolved. What you described are multiple tools that…

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

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

#159

Post by rtev »

Uptrenda wrote: post #95

I don't think Python packaging is as bad as people make out (if packages only stick to the basic features of Python!) A far bigger issue I see is despite Python supposedly being 'cross-platform': the language introduces so many small, backwards-compatibility breaking changes that you really need to use the most up to date interpreter you can. For instance: there is now a really cool operator that lets you do expressi…

While I do see the value in something like that, I can’t help but feel like that would just bake in more complexity. The python ecosystem is fragmented with micro fixes and half-solutions without anything truly addressing the major confusing aspects.

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

#160

Post by jamal-kumar »

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…

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 updating code can be alleviated if you try to select small, well-written, well-maintained libraries in ANY language but in go this just feels way easier, I find myself thinking how to solve it using stdlib instead of trying to find out what package would suit my needs and boom everything is there already don't need to mess around too hard looking on whose shoulders to stand on only to have them walk away and do something else with their time down the line. The worst ecosystem for that is easily nodejs, blows my mind what front-end dev often looks like these days... like it being normal for a project's node_modules to hit like 500mb is just incredible to me. I'm extremely allergic to that mentality. Someone hit me up like hey I have a linux problem when i run webpack it crashes my whole system... like yo how does some corky javascript thing to minify stuff cause semaphore exhaustion to a point where your entire system goes down when you run it on a sufficiently large project, that's just horrifyingly bad. Found out if he was to continue using that tool that he had to install some graceful filesystem package for it to work. I think I managed to convince him to switch to esbuild, written of course in go. [1]

[1] https://esbuild.github.io/

Post reply on HN