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

101–110 of 269 posts

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

#101

Post by pdimitar »

korijn wrote: post #80
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…

Is it a mess? Yes. But, is the problem to be solved perhaps much simpler "in other languages"? Do you interface with C++ libraries, system-managed dependencies, and perhaps your GPU in these other languages? Or are all your dependencies purely coded in these other languages, making everything simpler? Of course the answer to these questions could be anything but to me it feels like attacks on Python's package managem…

Or the "complainers" work with Rust and Elixir and giggle at Python's last-century dependency-management woes, while they run a command or two and can upgrade and/or pin their dependencies and put that in version control and have builds identical [to those on their dev machines] in their CI/CD environment.

¯\_(ツ)_/¯

Your comment hints that you are feeling personally attacked when Python is criticized. Friendly unsolicited advice: don't do that, it's not healthy for you.

Python is a relic. Its popularity and integration with super-strong C/C++ libraries has been carrying it for at least the last 5 years, if not 10. There's no mystery: it's a network effect. Quality is irrelevant when something is popular.

And yes I used Python. Hated it every time. I guess I have to thank Python for learning bash scripting well. I still ended up wasting less time.

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

#102

Post by pdimitar »

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…

> and even modern languages like rust (stuff is always broken, or I have some incompatible version, even when it builds it doesn't work)

Been working on and off with Rust for the last 3 years, never happened to me once -- with the exception of the Tokio async runtime that has breaking changes between versions. Everything else always worked on the first try (checked with tests, too).

Comparing Python with C++ doesn't make do argument any favours, and neither does stretching a single Rust accident to mean the ecosystem is bad.

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

#103

Post by [deleted] »

fnord123 wrote: post #31
jossclimb wrote: post #12

Earlier quoted context omitted.

Yep, I have no idea how they do not even understand the basics of python dependency management. pip freeze > requirements.txt will do it all for you. No wonder they found rust to hard.

`pip freeze > requirements.txt` will generate a lock file. You want a requirements listing as well as a lock file (like rust, poetry, golang, npm, ruby).

[deleted]

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

#104

Post by tempest_ »

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…

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 parts of the ecosystem is a lot) as well as different python versions (if you are supporting any kind of legacy software). This is also assuming other people working on the same project have the same python yadda yadda the list goes on, its not great.

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

#105

Post by shrimpx »

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…

> Pretty sure you can use == in requirements.txt

You can, but one of those packages that you depend on will have a loose version spec for one of its dependencies, making your `pip install -r requirements.txt` non-deterministic.

Poetry and Pipenv solve this, though, by pinning all dependencies in a lock file.

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

#106

Post by ledauphin »

obviouslynotme wrote: post #78
37ef_ced3 wrote: post #52

Earlier quoted context omitted.

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…

Go has always been a Java, C#, Python, and Ruby killer. It has not and never will be a C or C++ killer. C is the language of libraries and embedded, neither of which Go is good for. C++ is the language of large systems that need extreme control over resource allocation. Go is not good for this either.

I agree with you that Go does not replace C or C++, but I strongly disagree that Go is an obvious replacement for most uses of Python, C#, Java or Ruby, all of which are, frankly, _much_ higher level languages than Go.

Go gets used for two main reasons that I've been able to observe:

1) a desire for a very specific type of concurrency 2) a desire for a fast compiled language with a minimalistic feature set that scales well to large teams.

Switching to Go from one of those languages is very much giving up a kitchen sink for a purpose-built tool. It may be the right decision under lots of different circumstances, but it doesn't directly compete with any of the languages you've mentioned because of how minimalistic it tries to be.

Overall, in fact, I think Go does something far more interesting: it's legitimately an attempt to carve out a whole separate niche for software development. Whether it's ultimately been successful there is for a different comment thread, though. :)

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

#108

Post by shrimpx »

jossclimb wrote: post #12
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…

Yep, I have no idea how they do not even understand the basics of python dependency management. pip freeze > requirements.txt will do it all for you. No wonder they found rust to hard.

Your dismissal of the author is unwarranted.

You can do you want you suggest, but it's an operational pain in the ass. You need to maintain two files, the actual requirements.txt and the `pip freeze` one that locks the environment. And you better never `pip install` anything by hand or you'll capture random packages in your frozen file, or else always take care to create your frozen file in a fresh virtualenv. And if you don't want to install your dev packages into the production environment, then you need to maintain two requirements.txt and two of those frozen files.

The author mentions Poetry which does solve these issues with a nice interface.

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

#109

Post by ActorNightly »

shrimpx wrote: post #105
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…

> Pretty sure you can use == in requirements.txt You can, but one of those packages that you depend on will have a loose version spec for one of its dependencies, making your `pip install -r requirements.txt` non-deterministic. Poetry and Pipenv solve this, though, by pinning all dependencies in a lock file.

Pip freeze will grab all of the versions that are installed.
Post reply on HN