undefined | Better HN

0 pointsFridgeSeal1y ago0 comments

But like…why?

Let’s say we make a “thing” which contains packages for all participating languages.

98% of the time, aren’t users just going to go “filter down to my language” and just continue what they’re doing, except with a somewhat worse overall experience, depending on whatever the “lowest common denominator” API + semantics we use for this shared package management solution.

Multi-language build systems already exist, which happily serve the needs to those projects which find themselves needing cross-language (+distributed) builds. Could there be some easier versions of these? Sure, but I don’t feel like “throw everyone in the same big box” is the solution here.

0 comments

bluGill1y ago

> I don’t feel like “throw everyone in the same big box” is the solution

It has to be - while nobody needs more than a subset of that big box, the intersection of what everyone needs turns out to be throw everyone in the same big box. If you have anything less than that one big box you end up many standards and then everyone chooses which standard and in turn something important you need choose the other standard and you can't use it (ie the situation we are in now)

Of course making that "one standard to rule them all" easy enough to use is a hard problem. It may be itself impossible and thus everyone drops back to the current mess.

FridgeSealOP1y ago

I don’t entirely buy the argument, but I am intrigued.

> the intersection of what everyone needs turns out to be throw everyone in the same big box

I don’t follow: what’s the intersection of JS/Python/Go/Rust package management? What are they all needing that isn’t “download and store packages”? It can’t be OS level configuration, because that’s going to vary by OS and language.

j / k navigate · click thread line to collapse