8 ms·

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

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.

taminka 1y ago
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
- itsibitzi 1y ago
  What tool or ecosystem does this well, in your opinion?
  - taminka 1y ago
    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 1y ago
      "a standardised build system (virtually every language nowadays?)" Python packages still manage poorly dependencies that are in another lang like C or C++.
      - taminka 1y ago
        that's two different languages, they don't have have a standardised build system across them
- quantumspandex 1y ago
  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.
- deleted 1y ago
  [deleted]
- jokethrowaway 1y ago
  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 1y ago
    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
- dev_l1x_be 1y ago
  > 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 https://github.com/facebook/folly/blob/main/build.sh
  - huflungdung 1y ago
    [dead]
  - taminka 1y ago
    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?
    - adwn 1y ago
      > 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 1y ago
        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...
    - Sl1mb0 1y ago
- IshKebab 1y ago
  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 1y ago
    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 :)
- hobofan 1y ago
  > 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 1y ago
  > 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.
codetiger 1y ago
I guess, resource utilization like GPU, etc
ricardobeat 1y ago
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 https://github.com/astral-sh/uv
- DiabloD3 1y ago
  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.
  - airza 1y ago
    There's not really another game in town if you want to do fast ML development :/
    - DiabloD3 1y ago
      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.
      - nkozyra 1y ago
        > 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.
Galanwe 1y ago
> spent days wrestling with Python dependency hell I mean I would understand that comment in 2010, but in 2025 it's grossly ridiculous.
- adastra22 1y ago
  Yeah, because of a tool written in Rust, copying the Rust way of doing things for Python developers.
  - Galanwe 1y ago
    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.
- virtualritz 1y ago
  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-python-packages-have-different-versions-of-package-dependencies https://stackoverflow.com/questions/70828570/what-if-two-pyt...
  - Galanwe 1y ago
    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.
zoobab 1y ago
"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 1y ago
  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 1y ago
  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.
farhanhubble 1y ago
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 1y ago
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.

taminka 1y ago

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

itsibitzi 1y ago
What tool or ecosystem does this well, in your opinion?
- taminka 1y ago
  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 1y ago
    "a standardised build system (virtually every language nowadays?)" Python packages still manage poorly dependencies that are in another lang like C or C++.
    - taminka 1y ago
      that's two different languages, they don't have have a standardised build system across them
quantumspandex 1y ago
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.
deleted 1y ago
[deleted]
jokethrowaway 1y ago
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 1y ago
  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
dev_l1x_be 1y ago
> 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 https://github.com/facebook/folly/blob/main/build.sh
- huflungdung 1y ago
  [dead]
- taminka 1y ago
  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?
  - adwn 1y ago
    > 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 1y ago
      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...
  - Sl1mb0 1y ago
IshKebab 1y ago
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 1y ago
  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 :)
hobofan 1y ago
> 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 1y ago
> 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.

codetiger 1y ago

I guess, resource utilization like GPU, etc

ricardobeat 1y ago

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 https://github.com/astral-sh/uv

DiabloD3 1y ago
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.
- airza 1y ago
  There's not really another game in town if you want to do fast ML development :/
  - DiabloD3 1y ago
    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.
    - nkozyra 1y ago
      > 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.

Galanwe 1y ago

> spent days wrestling with Python dependency hell I mean I would understand that comment in 2010, but in 2025 it's grossly ridiculous.

adastra22 1y ago
Yeah, because of a tool written in Rust, copying the Rust way of doing things for Python developers.
- Galanwe 1y ago
  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.
virtualritz 1y ago
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-python-packages-have-different-versions-of-package-dependencies https://stackoverflow.com/questions/70828570/what-if-two-pyt...
- Galanwe 1y ago
  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.

zoobab 1y ago

"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 1y ago
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 1y ago
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.

farhanhubble 1y ago

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 1y ago

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.