[untrimmed]

As someone who has spent days wrestling with Python dependency hell just to get a model running, a simple cargo run feels like a dream. But I'm wondering, what was the most painful part of NOT having a framework? I'm betting my coffee money it was debugging the backpropagation logic.

[ricardobeat]

Have you tried uv [1]? It has removed 90% of the pain of running python projects for me.

[1] https://github.com/astral-sh/uv

[mtlmtlmtlmtl]

I'm sure it's true and all. But I've been hearing the same claim about all those tools uv is intended to replace, for years now. And every time I try to run any of those, as someone who's not really a python coder, but can shit out scripts in it if needed and sometimes tries to run python software from github, it's been a complete clusterfuck.

So I guess what I'm wondering is, are you a python guy, or are you more like me? because for basically any of these tools, python people tell me "tool X solved all my problems" and people from my own cohort tell me "it doesn't really solve anything, it's still a mess".

If you are one of us, then I'm really listening.

[DiabloD3]

uv is great, but I think the real fix is just abandoning Python.

The culture that language maintains is rather hostile to maintainable development, easier to just switch to Rust and just write better code by default.

[TheAceOfHearts]

Switching to uv made my python experience drastically better.

If something doesn't work or I'm still encountering any kind of error with uv, LLMs have gotten good enough that I can just copy / paste the error and I'm very likely to zero-in on a working solution after a few iterations.

Sometimes it's a bit confusing figuring out how to run open source AI-related python projects, but the combination of uv and iterating on any errors with an LLM has so far been able to resolve all the issues I've experienced.

[shepardrtc]

uv has been amazing for me. It just works, and it works fast.

[farhanhubble]

I have heard of similar experiences on HN a few times. Haven't seen any such conflicts on real projects in the last five years or so, since I started using Poetry and then UV. I deal with data science code and the people writing it have a tendency to create dependency spaghetti, for example including the Scikit package in a mainly Pytorch code, just because they need a tried-and-tested accuracy() function.

I do remember banging my head against failed dependency resolution in my Early days of Python, circa 2014, with Pip and Conda, etc.

The dependency issues I have faced were mostly due to data science folks pinning exact package versions for the sake of replicability in requirements.txt for example

[farhanhubble]

My biggest gripes with Python are:

- exports being broken if code is executed from a different directory

- packaging being more complicated than it should be

and I don't even have too much experience in the area of packaging, besides occasionally publishing to a private repo.

[codetiger]

I guess, resource utilization like GPU, etc

[Galanwe]

> spent days wrestling with Python dependency hell

I mean I would understand that comment in 2010, but in 2025 it's grossly ridiculous.

[virtualritz]

So in 2025, in Python, if I depend on two packages. A and B, and they both depend on different, API-incompatible or behavior-incompatible (or both) versions of C, that won't be an issue?

That's not my experience and e.g. uv hasn't helped me with that. I believe this is an issue with Python itself?

If parent was saying something "grossly ridiculous" I must be doing something wrong too. And I'm happy to hear what as that would lower the pain of using Python.

I.e. this was assumably true three years ago:

https://stackoverflow.com/questions/70828570/what-if-two-pyt...

[adastra22]

Yeah, because of a tool written in Rust, copying the Rust way of doing things for Python developers.

[zoobab]

"a simple cargo run feels like a dream"

A cargo build that warms up your CPU during winter while recompiling the whole internet is better?

[surajrmal]

It has 3 direct dependencies and not too many more transitively. You're certainly not recompiling the internet. If you're going to run a local llm I doubt you're building on a toaster so build speed won't be a big ordeal either.

[tracker1]

I recently upped to a 9950X with a gen5 nvme.. TBH, even installing a few programs from cargo (which does compiles) is pretty quick now. Even coming from a 5950X with a gen4 drive.

[taminka]

lowkey ppl who praise cargo seem to have no idea of the tradeoffs involved in dependency management

the difficulty of including a dependency should be proportional to the risk you're taking on, meaning it shouldn't be as difficult as it in, say, C where every other library is continually reinventing the same 5 utilities, but also not as easy as it is with npm or cargo, because you get insane dependency clutter, and all the related issues like security, build times, etc

how good a build system isn't equivalent of how easy it is include a dependency, while modern languages should have a consistent build system, but having a centralised package repository that anyone freely pull to/from, and having those dependencies freely take on any number of other dependencies is a bad way to handle dependencies

[dev_l1x_be]

> lowkey ppl who praise cargo seem to have no idea

Way to go on insulting people on HN. Cargo is literally the reason why people coming to Rust from languages like C++ where the lack of standardized tooling is giant glaring bomb crater that poses burden on people every single time they need to do some basic things (like for example version upgrades).

Example:

https://github.com/facebook/folly/blob/main/build.sh

[quantumspandex]

Security is another problem, and should be tackled systematically. Artificially making dependency inclusion hard is not it and is detrimental to the more casual use cases.

[hobofan]

> but having a centralised package repository that anyone freely pull to/from, and having those dependencies freely take on any number of other dependencies is a bad way to handle dependencies

So put a slim layer of enforcement to enact those policies on top? Who's stopping you from doing that?

[MangoToupe]

> the difficulty of including a dependency should be proportional to the risk you're taking on

Why? Dependency hell is an unsolvable problem. Might as well make it easier to evaluate the tradeoff between dependencies and productivity. You can always arbitrarily ban dependencies.

[itsibitzi]

What tool or ecosystem does this well, in your opinion?

[IshKebab]

This is the weirdest excuse for Python's terrible tooling that I've ever heard.

"It's deliberately shit so that people won't use it unless they really have to."

[jokethrowaway]

Is your argument that python's package management & ecosystem is bad by design - to increase security?

In my experience it's just bugs and poor decision making on the maintainers (eg. pytorch dropping support for intel mac, leftpad in node) or on the language and package manager developers side (py2->3, commonjs, esm, go not having a package manager, etc).

Cargo has less friction than pypi and npm. npm has less friction than pypi.

And yet, you just need to compromise one lone, unpaid maintainer to wreck the security of the ecosystem.