Comment by taminka

Comment by taminka 18 hours ago

22 replies

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

  • taminka 16 hours 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?

    • Sl1mb0 16 hours ago

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

      That's just like, your opinion, man.

      • lutusp 14 hours ago

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

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

      • taminka 16 hours ago

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

    • CodeMage 14 hours ago

      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.

    • adwn 16 hours 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 16 hours 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...

quantumspandex 18 hours 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.

hobofan 15 hours 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?

itsibitzi 18 hours ago

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

  • taminka 16 hours 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 15 hours ago

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

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

IshKebab 17 hours 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 16 hours 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 :)

[removed] 18 hours ago
[deleted]
MangoToupe 14 hours 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.

jokethrowaway 18 hours 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 16 hours 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