← Back to context

Comment by kunley

3 months ago

I don't buy it.

A guy designing and then implementing a programming language has a much bigger chance to put a lot of rational thinking into the tooling like dependency manager, than a typical language consumer, who can and often is easily falling into the languages emo wars.

As the original article points out, not all languages come out of the box with a sane/rationally designed dependency manager. I can think of only a handful in that category. The vast majority of languages fall short and rely on secondary community projects to prop up the dependency management for the language: maven, gradle, npm, pip/pypi, now uv, etc.

Language designers in general terms will fall into the "more knowledgeable than the average developer"category , but let's not pretend they're anything but mere mortals like the rest of us.

NGL Ive somehow lost the thread and can't tell if we're talking about language integrated dependency managers in the abstract (in the OP), or specifically speaking about golang, odin or something else. I don't know what the emo wars are specifically in reference to but I think we jumped the shark here.

  • Put another way: what makes this time different? How does this designer's proclivity and push towards X learn from our collective past mistakes; what does it bring to the table?

    Yes dependency hell is "bad", but we have several language and package management systems today from ninja to uv that make various, obvious trade offs. Optimizing developer time, ergonomics, reproducible builds, configuration complexity are just some of the axes these pre-existing systems focus on.

    If you're extremely lucky you get to pick a system that aligns with your style of work and ideals for how software should be built. If you're not, and like the rest of us, you get stuck with everyone else's poor decisions and are forced to make do. All code is legacy code given the right time horizon, so think about software with all those manual dependencies included on disk and nowhere else. How do you safely apply those required security fixes, etc. Don't be user hostile, this will just lead to our past sins like the C of old.

    From a purist perspective, you can forgo all other software that you have not written in-house / or does not come with the standard library. This is the monk approach, but outside a few niche work environments that's untenable.

> than a typical language consumer, who can and often is easily falling into the languages emo wars.

How is ginger bill excluded from this group? No one is more invested in a language than its creator(s).

Sure, he might have given it a lot of thought, but he came up with some completely bonkers conclusions. If you don't want dependencies, DON'T IMPORT DEPENDENCIES. Don't make your dependencies extremely hard to add.

  • Yeah when speaking about emotions: the amount of emo reactions here, including shouting with all caps, lets me think we've fallen into the old story: the author kind-of praised Go, but it's unfashionable here; the contrary, the fad here is to hate Go, so the author needed to get his hate. As simple as that. The rest is just trying to hide the hate under seemingly rational arguments.

    Yawn.. saw it before...next, please

    • Yeah, god forbid you use bolding to emphasize your phrase on this site. It's considered emotinal response, but yours is purely logical?

      I'm glad you saw through me like a Superman through a lead book. Which is to say, not at all. I wasn't even thinking of Go. Where did this come from? I never mentioned Go. I don't use it or know how it does its packaging.

      Are you projecting your feelings onto me as a sort of substitute for the HN gestalt? The discussion was about package managers being evil.

      Now please return to the topic at hand.

      Let's say you have NPM package manager. What prevents you a rational individual from saying:

            {
               "depedencies": {}
            }

      1 reply →

  • I have? Pray tell.