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

[hobofan]

I'm one of you.

I'm about the highest tier of package manager nerd you'll find out there, but despite all that, I've been struggling to create/run/manage venvs out there for ages. Always afraid of installing a pip package or some piece of python-based software (that might muck up Python versions).

I've been semi-friendly with Poetry already, but mostly because it was the best thing around at the time, and a step in the right direction.

uv has truely been a game changer. Try it out!

[tinco]

As a Ruby guy: uv makes Python feel like it finally passed the year 2010.

[llIIllIIllIIl]

Don’t forget to schedule your colonoscopy as a Ruby guy

[jhardy54]

I’m a “Python guy” in that I write Python professionally, but also am like you in that I’ve been extremely underwhelmed by Portry/Pipenv/etc.

Python dependencies are still janky, but uv is a significant improvement over existing tools in both performance and ergonomics.

[Yoric]

As a developer: it basically solved all of my problems that could be solved by a package manager.

As an occasional trainer of scientists: it didn't seem to help my students.

[buildbot]

It installs stuff super fast!

It sadly doesn’t solve stuff like transformer_engine being built with cxx11 ABI and pytorch isn’t by default, leading to missing symbols…

[OrderlyTiamat]

I'm (reluctantly) a python guy, and uv really is a much different experience for me than all the other tools. I've otherwise had much the same experience as you describe here. Maybe it's because `uv` is built in rust? ¯\_ (ツ)_/¯

But I'd also hesitate to say it "solves all my problems". There's plenty of python problems outside of the core focus of `uv`. For example, I think building a python package for distribution is still awkward and docs are not straightforward (for example, pointing to non-python files which I want to include was fairly annoying to figure out).

[OoooooooO]

As a mainly Python guy (Data Engineering so new project for every ETL pipeline = a lot of projects) uv solved every problem I had before with pip, conda, miniconda, pipx etc.

[beacon294]

It doesn't handle python version management, it only handles pip. It doesn't solve bundling Python.

[re]

It does handle python version management: https://docs.astral.sh/uv/concepts/python-versions/

[beacon294]

That's great news, I'll have to try to replace pyenv (again).

[J_Shelby_J]

Isn’t UV essentially cargo for python?

[adastra22]

Somewhat literally so. It is written in Rust and makes use of the cargo-util crate for some overlapping functionality.

[rossant]

I know, but uv truly is different.

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

[trklausss]

Every tool for the right job. If you are doing tons of scripting (for e.g. tests on platforms different than Rust), Python can be a solid valid alternative.

Also, tons of CAE platforms have Python bindings, so you are "forced" to work on Python. Sometimes the solution is not just "abandoning a language".

If it fits your purpose, knock yourself out, for others that may be reading: uv is great for Python dependency management on development, I still have to test it for deployment :)

[aeve890]

>Every tool for the right job. If you are doing tons of scripting (for e.g. tests on platforms different than Rust), Python can be a solid valid alternative.

I'd say Go is a better alternative if you want to replace python scripting. Less friction and much faster compilation times than Rust.

[DiabloD3]

I am not a huge fan of Go, but if all the world's "serious" Python became Go, the average code quality would skyrocket, so I think I can agree to this proposal.

[physicsguy]

Go performance is terrible for numeric stuff though, no SIMD support.

[9rx]

That's not really true, but we're talking about a Python replacement for scripting tasks, not core compute tasks, anyway. It is not like Python is the paragon of SIMD support. Any real Python workloads end up being written in C for good reason, using Python only as the glue. Go can also interface with C code, and despite all the flack it gets for its C call overhead it is still significantly faster at calling C code than Python is.

[DiabloD3]

(given the context of LLMs) Unless you're doing CPU-side inference for corner cases where GPU inference is worse, lack of SIMD isn't a huge issue.

There are libraries to write SIMD in Go now, but I think the better fix is being able to autovectorize during the LLVM IR optimization stage, so its available with multiple languages.

I think LLVM has it now, its just not super great yet.

[wild_egg]

Lots of packages out there using SIMD for lots of things.

You can always drop into straight assembly if you need to as well. Go's assembler DX is quite nice after you get used to it.

[pjmlp]

Go itself no, but luckily like in any compiler toolchain, there is an Assembler available.

[pclmulqdq]

There are Go SIMD libraries now, and there's also easy use of C libraries via Cgo.

[airza]

There's not really another game in town if you want to do fast ML development :/

[DiabloD3]

Dunno, almost all of the people I know anywhere in the ML space are on the C and Rust end of the spectrum.

Lack of types, lack of static analysis, lack of ... well, lack of everything Python doesn't provide and fights users on costs too much developer time. It is a net negative to continue pouring time and money into anything Python-based.

The sole exclusion I've seen to my social circle is those working at companies that don't directly do ML, but provide drivers/hardware/supporting software to ML people in academia, and have to try to fix their cursed shit for them.

Also, fwiw, there is no reason why Triton is Python. I dislike Triton for a lot of reasons, but its just a matmul kernel DSL, there is nothing inherent in it that has to be, or benefits from, being Python.... it takes DSL in, outputs shader text out, then has the vendor's API run it (ie, CUDA, ROCm, etc). It, too, would benefit from becoming Rust.

[mountainriver]

I love Rust and C, I write quite a bit of both. I am an ML engineer by trade.

To say most ML people are using Rust and C couldn’t be further from the truth

[Narishma]

They said most people they knew, not most people.

[wolvesechoes]

> It, too, would benefit from becoming Rust.

Yet it was created for Python. Someone took that effort and did it. No one took that effort in Rust. End of the story of crab's superiority.

Python community is constantly creating new, great, highly usable packages that become de facto industry standards, and maintain old ones for years, creating tutorials, trainings and docs. Commercial vendors ship Python APIs to their proprietary solutions. Whereas Rust community is going through forums and social media telling them that they should use Rust instead, or that they "cheated" because those libraries are really C/C++ libraries (and BTW those should be done in Rust as well, because safety).

[nkozyra]

> Dunno, almost all of the people I know anywhere in the ML space are on the C and Rust end of the spectrum.

I wish this were broadly true.

But there's too much legacy Python sunk cost for most people though. Just so much inertia behind Python for people to abandon it and try to rebuild an extensive history of ML tooling.

I think ML will fade away from Python eventually but right now it's still everywhere.

[DiabloD3]

A lot of what I see in ML is all focused around Triton, which is why I mentioned it.

If someone wrote a Triton impl that is all Rust instead, that would do a _lot_ of the heavy lifting on switching... most of their hard code is in Triton DSL, not in Python, the Python is all boring code that calls Triton funcs. That changes the argument on cost for a lot of people, but sadly not all.

[airza]

Okay. Humor me. I want to write a transformer-based classifier for a project. I am accustomed to the pytorch and tensorflow libraries. What is the equivalent using C?

[adastra22]

You do know that tensorflow was written in C++ and the Python API bolted on top?

[pjmlp]

PyTorch also supports C++ and Java, Tensorflow also does C++ and Java, Apple AI is exposing ML libraries via Swift, Microsoft is exposing their AI stuff via .NET and Java as well, then there is Julia and Mojo is coming along.

It is happening.

[famouswaffles]

TensorFlow is a C++ library with a python wrapping, yet nobody (obviously exaggeration) actually uses tensorflow (or torch) in C++ for ML R&D.

It's like people just don't get it. The ML ecosystem in python didn't just spring from the ether. People wanted to interface in python badly, that's why you have all these libraries with substantial code in another language yet development didn't just shift to that language.

If python was fast enough, most would be fine to ditch the C++ backends and have everything in python, but the reverse isn't true. The C++ interface exists, and no-one is using it.

[pjmlp]

The existing C++ API is done according to that "beautiful" Google guidelines, thus it could be much better.

However people are definitely using it, as Android doesn't do Python, neither does ChromeOS.

[pjmlp]

I know Python since version 1.6.

It is great for learning on how to program (BASIC replacement), OS scripting tasks as Perl replacement, and embedded scripting in GUI applications.

Additionally understand PYTHONPATH, and don't mess with anything else.

All the other stuff that is supposed to fix Python issues, I never bothered with them.

Thankfully, other languages are starting to also have bindings to the same C and C++ compute libraries.

[wavemode]

Rust is not a viable replacement for Python except in a few domains.

[WhereIsTheTruth]

abandoning Python for Rust in AI would cripple the field, not rescue it

the disease is the cargo cult addiction (which Rust is full of) to micro libraries, not the language that carries 90% of all peer reviewed papers, datasets, and models published in the last decade

every major breakthrough, from AlphaFold to Stable Diffusion, ships with a Python reference implementation because that is the language researchers can read, reproduce, and extend, remove Python and you erase the accumulated, executable knowledge of an entire discipline overnight, enforcing Rust would sabotage the field more than anything

on the topic of uv, it will do more harm than good by enabling and empowering cargo cults on a systemic level

the solution has always been education, teaching juniors to value simplicity, portability and maintainability

[stonemetal12]

Nah, it would be like going from chemistry to chemical engineering. Doing chemical reactions in the lab by hand is great for learning but you aren't going to run a fleet of cars on hand made gas. Getting ML out of the lab and into production needs that same mental conversion from CS to SE.

[Exuma]

i hate python, but the idea of replacing python with rust is absurd

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

[Galanwe]

Well, first, this a purposefully contrived example, that pretty much does not happen in real life scenarios. So you're pretty much acknowledging that there is no real problem by having to resort to such length.

Second, what exactly would you like to happen in that instance? You want to have, in a single project, the same library but at different and conflicting versions. The only way to solve that is to disambiguate, per call site, each use of said library. And guess what, that problem exist and was solved 30 years ago by simply providing different package names for different major version. You want to use both gtk 1 and gtk 2 ? Well you have the "gtk" and "gtk2" package, done, disambiguated. I don't think there is any package manager out there providing "gtk" and having version 1 and 2, it's just "gtk" and "gtk2".

Now we could design a solution around that I guess, nothing is impossible in this brave new world of programing, but that seems like a wasted effort for not-a-problem.

[virtualritz]

> Well, first, this a purposefully contrived example [...]

So you are saying that (a) I made this up and (b) intentionally so.

How so? I am always flabbergasted when people make such statements.

You know nothing of my use of Python. I work in a specific field (computer graphics) and within that an even more specific sub field, visual effects.

I have to use Python maybe every three months. And there is some dependency related pain every single time. Python's dependency management "is straight up terrible" (quoted from elsewhere in this thread), I concur.

And thusly, in my world, this example is not "contrived" and given the aforementioned circumstances -- that were unknown to you -- even less so "purposefully".

> Second, what exactly would you like to happen in that instance?

I would expect Python to namespace-wrap (on-the-fly) conflicting versions.

See Rust for some similar solution.

> [...] a wasted effort for not-a-problem.

If this was "not-a-problem" why would Rust/cargo go out of its way to solve it? And why would people regularly point out for this to be one of the reasons dependencies are indeed a "not-a-problem" in Rust and how great that is compared to whatever else they battled with before?

Indeed you and I do live in different worlds.

[Galanwe]

> I am always flabbergasted when people make such statement

Sit down, have a coffee, re-read your whole comments, create bullet points for your case, and try to have an *objective* look at your arguments.

- Your are frustrated with your use case, seemingly to the point where you don't care about reasonable arguments but just want to lash out at something.

- By your own description, you have a specific use case, in a specific field, in a narrower sub field.

- You are not primarily a Python developer, and use it every 3 months when you have to.

Your experience, in your field, on your project, does not make you a poster child of what everyday Python is like. Sorry for the news.

Now I get that frustration of "I just want things done and not care about that whole ecosystem", but the reality is, that's not a Python thing, it's a "that's not my preferred stack thing".

I have that same feeling whenever I need to get things done in a stack I don't know, and get stuck by something <insert preferred stack> does.

I used Rust the other day and ended up in a case where I needed to implement a trait I do not own. Well that ended up not being possible. That pissed me off for a time, that *really* made the most sense for my use case. Yet... I'm not going to complain that Rust is unusable because of "trait ownership hell" on the internet.

If we let the frustration aside for a minute:

Your use case, as a fact, is very contrived.

One does not stumble into projects that need to work with different, incompatible, similarly named, versions of a same library, every day.

As I mentioned, when that need arises, library maintainers usually just create a new package, with a different name.

That is what have been done for 99.99% of package managers ever in existence, be it system package managers, or language package managers.

And the reason for it is really just common sense:

- It does not happen very often

- Whenever that happens, the solution of providing a new package is the simplest and most well established

- The pattern works, and has been used since 30 years

- It is unambiguous

Note that Rust does _not_ magically solve that problem either, as there is no one size fits all solution to this problem. The best Rust can do, is:

- In the subset use case of this problem where said dependency is solely accessed from the inside of another dependency

- And said library symbols need not be externally accessible

- And said library data structures need not be shared

- Then Rust can build the outer most dependency against a specific version of said inner dependency.

[adastra22]

Maybe this doesn’t happen in Python, but I find that hard to believe. This is a common thing in Rust, where cargo does support compiling with multiple versions of the same crate. If I have dependency X that depends on version 1.x of crate Z, and dependency Y which depends on version 2.x, cargo will compile BOTH versions of crate Y, and handle the magic of linking dependencies X and Y to their own, different copies of this common dependency.

[steveklabnik]

Yes, Rust can do this. I know Ruby cannot, and I believe Python may not either, but I am less sure about it because I’m less good with Python’s semantics here, but I’d believe your parent.

[adastra22]

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

[Galanwe]

I am not even thinking of `uv`, but rather of pyproject.toml, and the various improvements as to how dependencies are declared and resolved. You don't get much simpler than a toml file listing your dependencies and constraints, along with a lock file.

Also let's keep middle school taunts at home.

[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

[taminka]

i'm saying that ease of dependency inclusion should not be a main criterion for evaluating how good a build system is, not that it isn't the main criterion for many people...

like the entire point of my comment is that people have misguided criteria for evaluating build systems, and your comment seems to just affirm this?

[Sl1mb0]

> dependency inclusion _should not_ be a main criterion for evaluating how good a build system is

That's just like, your opinion, man.

[lutusp]

> That's just like, your opinion, man.

I would love to know how many younger readers recognize this classic movie reference.

[taminka]

i mean, unless you have some absolute divine truths, that's kind of the best i have :shrug

[virtualritz]

There are no truths but your opinion in this case runs counter of what 35 years developing software have taught me.

Obviously, I may be an outlier. Some crank who's just smitten by the proposal of spending his time writing code instead of trying to get a dependency (and its sub-dependencies and their sub-dependencies) to build at all (e.g. C/C++) or to have the right version that works with ALL the code that depends on it (e.g. Python).

I.e. I use cargo foremost (by a large margin) for that reason.

[adwn]

> like the entire point of my comment is that people have misguided criteria for evaluating build systems, and your comment seems to just affirm this?

I think dev_l1x_be's comment is meant to imply that your believe about people having misguided criteria [for evaluation build systems] is itself misguided, and that your favored approach [that the difficulty of including a dependency should be proportional to the risk you're taking on] is also misguided.

[taminka]

my thesis is that negative externalities of build systems are important and i don't know how to convince of importance of externalities someone whose value system is built specifically on ignoring externalities and only factoring in immediate convenience...

[CodeMage]

Dependency management should most definitely be one of the main criteria for evaluating how good a build system is. What's misguided is intentionally opting for worse dependency management in an attempt to solve a people problem, i.e. being careless about adding dependencies to your project in circumstances when you should be careful.

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

[taminka]

any language that has a standardised build system (virtually every language nowadays?), but doesn't have a centralised package repository, such that including a dependency is seamless, but takes a bit of time and intent

i like how zig does this, and the creator of odin has a whole talk where he basically uses the same arguments as my original comment to reason why odin doesn't have a package manager

[zoobab]

"a standardised build system (virtually every language nowadays?)"

Python packages still manage poorly dependencies that are in another lang like C or C++.

[taminka]

that's two different languages, they don't have have a standardised build system across them

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

[taminka]

i just realised that my comment sounds like it's praising python's package management since it's often so inconvenient to use, i want to mention that that wasn't my intended point, python's package management contains the worst aspects from both words: being centralised AND horrible to use lol

my mistake :)

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

[taminka]

nah python's package management is just straight up terrible by every metric, i just used it as a tangent to talk about how imo ppl incorrectly evaluate build systems