Why does every package+module system become a Rube Goldberg machine?

Question

A programming language has a "core language" plus a package/module system. In each successful language, the core language is neat-and-tidy, but the package/module system is a Rube Goldberg machine. See JavaScript/TypeScript, Python, or C/C++.Lots of brain cycles are spent on "programming language theory". We've roughly figured out the primitives required to express real-world computation.In contrast, we apparently have no "package management theory". We have not figured out the primitives required to express dependencies. As a result, we keep building new variants and features, until we end up with , require(), import, npm, yarn, pnpm, (py)?(v|virtual|pip)?env, (ana)?conda, easy_install, eggs and wheels ...Is it just a "law of software" that this must happen to any successful language? Or are there examples of where this it has not happened, and what can we learn from them? Is there a "theory of package management", or a "lambda calculus of package management" out there?

tazjin · Accepted Answer

> In contrast, we apparently have no "package management theory". We have not figured out the primitives required to express dependenciesWe have a good hunch. The basic theory behind Nix definitely goes in the right direction, and if we look away from all the surface-level nonsense going on in Nix, it's conceptually capable (e.g. [0]) of being a first-class language dependency manager.For this to work at scale we'd need to overcome a couple of large problems though (in ascending order of complexity):1. A better technical implementation of the model (working on it [1]).2. A mindset shift to make people understand that "binary distribution" is not a goal, but a side-effect of a reasonable software addressing and caching model. Without this conceptual connection, everything is 10x harder (which is why e.g. Debian packaging is completely incomprehensible - their fundamental model is wrong).3. A mindset shift to make people understand that their pet programming language is not actually a special snowflake. No matter what the size of your compilation units is, whether you call modules "modules", "classes" or "gorboodles", whether you allow odd features like mutually-recursive dependencies and build-time arbitrary code execution etc.: Your language fits into the same model as every other language. You don't have to NIH a package manager.This last one is basically impossible at the current stage. Maybe somewhere down the line, if we manage to establish such a model successfully in a handful of languages and people see for themselves, but for now we have to just hold out.[0]: https://code.tvl.fyi/about/nix/buildGo[1]: https://cs.tvl.fyi/depot/-/tree/tvix/

jakewins · Answer

Have you used Go or Rust package ecosystems?My experience is that the older gen languages you mention had to invent package management, made lots of understandable mistakes and now are in a backwards compat hellscape.Rust and Go built their packaging story with the benefit of lessons learned from those other systems, and in my experience the difference is night and day.

ChrisRackauckas · Answer

Julia and Rust seem to have package systems that are fine and manageable. I think these are really just major problems in Javascript, Python, and C/C++ (exactly the languages you mention) because the kind of widespread OSS code sharing just didn't exist to the extent it does today back when those languages were designed. People shared code through email, but didn't expect one button to pull in 200 Github repositories, and thus weren't built with the expectations required to make that be stable.Back when those languages were designed, you'd manually download the few modules you need, if you downloaded any packages at all. In C you'd normally build your own world, since it came before the www times, and C++ kind of inherited that. But languages which came out later decided that we now live in a world where most of the code that is executed is packages, most likely packages which live on Github. So Julia and Rust build this into the language. Julia in particular with the Project.toml and Manifest.jl for fully reproducing environments, its package manager simply uses git and lets you grab the full repository with `]dev packagename`, its package registry system lets you extend with private package worlds.I think the issue is that dependencies are central, so you can never remove old package systems because if that's where the old (and rarely updated) dependencies live, then you need to keep it around. But for dependencies to work well, you need all dependencies to be resolved using the same package system. So package systems don't tend to move very fast in any language, whatever you had early has too much momentum.

derefr · Answer

What I really want to know, is why package development is such a Rube Goldberg machine. Not for programming-language packages, per se, but rather for OS packages of simple programming-language packages.Have you tried to package a random Python/Ruby/etc. CLI program, for Debian? Or how about for Homebrew? Each one involves a cacophony of PL scripts calling shell-scripts calling PL scripts, and internal/undocumented packager subcommands calling other internal/undocumented packager subcommands. It takes ~forever to do a checked build of a package in these systems, and 99% of it is just because of how spread out the implementation of such checks is over 100 different components implemented at different times by different people. It could all be vastly simplified by reimplementing all the checks and transforms in a single pass that gradually builds up an in-memory state, making assertions about it and transforming it as it goes, and then emitting it if everything works out. You know &mdash; like a compiler.

denton-scratch · Answer

It annoys me that every gee-whizz new language needs to have it's own package-management system.There's no reason why a package-management system needs to be language-specific; dependencies are often cross-language. Hell, even some blocks of code contain more than one language.The package-management system is responsible for deploying packages. The way a package is deployed should depend on the operating environment, not on the language. These language-specific packaging arrangements typically deploy into some private part of the file-system, organized in its own idiosyncratic way.Using git as a repository is just nuts. Git is privately-owned, and stuffed with all kinds of unaudited junk. You can't audit everything you install by hand; so these systems force you to install unaudited code, or simply not install.I've been using Debian derivatives for years. I appreciate having an audited repository, and an installation system that deploys code to more-or-less predictable filesystem locations.

perrygeo · Answer

I'd say we have a fairly good existing theory that explains modern package management: Conway's Law.We self-organize into communities of practice and select the package management strategy that works best. Reaching across communities to develop a grand centralized strategy that fits everyone's needs would be __possible__, but involves significant communication and coordination overhead. So instead we fracture, and the tooling ecosystem reflects ad-hoc organizational units within the community.Ecosystems like Rust cargo that have batteries included from the start have an advantage, virtually all Rust developers have a single obvious path to package management because of this emergent social organization.Ecosystems like Python's seem like the wild west, there is deep fracturing (particularly between data science and software engineering) and no consensus on the requirements or even the problems. So Python fractures further, ironically in a search for something that can eventually unify the community. And python users feel the strain of this additional overhead every day, needing to side with a team just to get work done.I'd argue both of these cases are driven by consequences easily predictable from Conway's Law.

neilv · Answer

The Racket module system, designed by Matthew Flatt, is great.But to fully appreciate it, it helps to understand syntax transformation in Racket. Once the rigorous phase system forces non-kludgy static rules about when things are evaluated, your syntax transformers and the code on which they depend could cause a mess of shuffling code among multiple files to solve dependency problems... until you use submodules with the small set of visibility rules, and then suddenly your whole tricky package once again fits in a single file cleanly.I leveraged this for some of my embedded doc and test experiments, without modifying the Racket core. (I really, really like single-source-file modules that embed doc, test, and package metadata all in the same file, in logical places.)

jrockway · Answer

You mention Python and Node, which are programming language that unusually require end users to have the text of your program and all its dependencies on their own machine, and the languages store some parts of your program in /usr/lib and other parts of your program in your source directory. (npm does a little better here and at least puts the dependencies in your project directory.) Those constraints make development and packaging hard no matter what.Python and Node both need a way to compile the code down to a single statically-linked binary like more modern languages (Go, Rust), solving the distribution problem once and for all.There are module systems that aren't insane, like Go's module system. It uses semantic versioning to mediate version conflicts. Programs can import multiple major versions of the same module. The module requirements files ensure that every checkout of the code gets the exact same bytes of the code's dependencies. The compiler is aware of modules and can fetch them, so on a fresh workstation, "go test ./..." or "go install ./cmd/cool-thing" in a module-aware project works without running any other command first. It is actually so pleasant to use that I always think twice "do I want to deal with modules" before using a language like Javascript or Python, and usually decide "no".npm and pip are the DARK AGES. That's why you're struggling. The community has been unable to fix these fundamental flaws for decades, despite trying in 100 incompatible ways. I personally have given up on the languages as a result. The standard library is never enough. You HAVE to solve the module problem on day 1.

rpigab · Answer

I think package management is something so important you either have to get it right on the first released version of the language, or never release an official one at all. So if you look at C, there was basically no internet or even HTTP, so if they wanted to fetch + store dependencies from centralized repositories, it would have been difficult and then need to change a lot over the years. Python is the worst to me, I love the language, but I hate the tooling, managing installations, packages, modules, etc.Sometimes languages are relased with just a spec and don't want to force any choice of tool or way of doing things on you, so you just manage that yourself or create third party tools, and that's where it gets wild in every direction, but it also creates room for new ideas, innovation, which later are used in "official" modern package managers built in the language tools.And yeah, nowadays I use Rust even for scripting stuff that would be easier to do in Python, just because I don't want to create a thousandth virtualenv, find a lib that does what I want but it's for Python

rklaehn · Answer

I find cargo (rust package manager) relatively pleasant to use. It's not perfect, but it also is not a constant source of confusion like sbt (scala package manger) was back when I did scala.In the long term, I think the whole notion of a "package" is obsolete. In unison https://www.unison-lang.org/ , code is just a content-addressed merkle tree. So dependencies are both more precise and more fine grained than packages.E.g. if there is a new version of a library, but the part of the library that you actually use is unchanged, unison will detect this and not trigger a full rebuild.The whole notion of a package becomes less important.

jcarrano · Answer

Because anyone can write a mediocre "gets the immediate problem solved" type of package manager, while designing and implementing a programming language that someone else would want to use requires way more knowledge and skill.Eventually the shortcomings of the package manager will become more evident, but at first it will seem to work and solve some pain points programmer have.Something similar goes for build systems.

namelosw · Answer

Modern languages like Rust and Elixir are fine.JavaScript, C/C++, Python are very old and the package systems were pretty much bolt-on. And of course a lot of historical factors were playing a bit role.In the old days, people usually start minimal. When they get burned they also find they were locked-in - thus the bolt-ons.> we apparently have no "package management theory"People are definitely standing on top of each others' shoulders. Node.js npm actually felt like Ruby package tools but also being first-party (they also cut some corners, and made some design choices - some worked well and some didn't).i.e. Hex for Elixir feels like nothing new, but avoided most common pitfalls others have experienced. I believe most language designers nowadays can do the same, given they want to play it safe and want nothing too novel.

choeger · Answer

We have such a theory, it's called "modules". But unfortunately, modules are even less popular than proper typesystems have been for decades.It's no coincidence that Rust (which has basically copied Haskell's type system to a large degree) and Julia (which is essentially a Lisp in disguise) have somewhat sound packaging systems. C/C++ does not even have a tidy core language, let alone proper modules (yes, yes, C++ modules might change that, but they are still a complex mix of templates and normal code).

gwd · Answer

You haven't explicitly enumerated the things about those packaging systems which seem "Rube Goldberg" to you; nor have you mentioned either Golang or Rust's package management. I'm pretty happy overall with Golang's package management, and from my little exposure to Rust's package manager, it seems fairly decent as well. Do either of them strike you as "Rube Goldberg"? What aspects, and why?

Akronymus · Answer

> Is it just a "law of software" that this must happen to any successful language? Or are there examples of where this it has not happened, and what can we learn from them?Dotnet has nuget and it is quite pleasant to use in my experience. I think the big deal is having some standardized way of managing them as a layer on top. In teh dotnet case, it is having the solution pull in the nuget packages, rather than individual files. Along with having a standardized way to index available packages from each source (In this case the nuget json)

thenerdhead · Answer

Have you read https://medium.com/@sdboyer/so-you-want-to-write-a-package-m... ?The author does a great job pointing out the problems, theory, and ecosystem change that makes it a Rube Goldberg machine.By definition, a package manager is always "incomplete" because it cannot catch all the security vulnerabilities, binary compatibility, or knowing the dependencies ahead of time nor their interactions together. Thus it can be unsuccessful at managing dependencies - its primary job.Source: Also work on a notable package manager.

michael1999 · Answer

Part of it is deliberately ignoring the lessons of the past because they seem like overkill. Python has the excuse that it is old enough to predate the lessons of Java and Maven. But the node and js worlds deliberately ignored things like namespaces and mandatory version specification because they were uncool. And then they had to introduce package-lock and typo-squatting defences because the complexity of the world isn't always negotiable.

pastage · Answer

Why do we need different systems for all languages, all Linux/Windows/Mac/Android distributions. Why are no one reusing what is already there. It might seem like an easy problem to fix. Rust, Java and Go certainly has their problems too, not quite sure why people feel they are good examples.I think the world is complicated and you will in the end need to support compilations/installations on AmigaOS 2.05 on m68k running in kubernetes native.

warrenm · Answer

It's far simpler than you thinkIt all boils down to NIHS - "not invented here syndrome"Between developers being suspicious of anyone else's work, and their innate love to build things they'll use (your wheel is cool, I guess...but MY wheel does THIS!) ...you get a gajillion libraries that overlaps 95% of the time (but never on the 5% you "care" about)Eons ago David Pogue wrote in his review of Word (98, I think) for the Mac, "MacWrite fit on one floppy disk and had 95% of all the features I've ever needed in a word processor. Word take a CD, and has 96% of all the features I've ever needed in a word processor."Why is Word so big? Is it because a 'word processor' needs to be that big?Why are there so many libraries with incredibly weird interdependencies (version 1.9.2a of this lib needs 2.1.x2 of that one, not 2.1.x3 or 2.1.g7; but if you have version 1.9.3 of this lib, you can use 2.1.x2 up through 2.1.x9 ot he other one)?Same thing - somebody somewhere sometime somewhy decided to use that library in their own stuff, and is now forever and always bound to it (...until they refactor or rewrite a perfectly good tool that was in Scala into Haskell)

tsukikage · Answer

They all followed the same process:Step 1: look at all the existing package+module systems, and realise they are all horrible Rube Goldberg machines, way too bloated for the simple thing you want to doStep 2: write your own package+module system! It's lean, mean and just does the simple obvious thing your simple one-man project needs.Step 3: your system hits the real world! Your system is used with projects that involve more than one person and grow organically, and that spread to more and more esoteric environments. The Rube Goldberg projects have Rube Goldberg aims and their target ecosystems have Rube Goldberg requirements while goalposts shift continuously with tight deadlines. You add features and toggles to your system to support these things.Step 4: congratulations! You are the proud inventor and owner of yet another Rube Goldberg machine. It is now time to move on to better things; the system, meanwhile, is handed over to some committee and will only grow in complexity from here.https://www.kiplingsociety.co.uk/poem/poems_palace.htm

tikkabhuna · Answer

> See JavaScript/TypeScript, Python, or C/C++.I feel like you've picked the 3 worst ecosystems as an example.Java has a wonderful ecosystem. You can use Maven/Gradle/Bazel as a dependency manager/build tool. All support the Maven repository format. Packages are published as jars and easily consumed. Of course you can still end up in dependency hell and you should take steps to mitigate those issues, but I'm quite happy with it.> As a result, we keep building new variants and features, until we end up with , require(), import, npm, yarn, pnpm, (py)?(v|virtual|pip)?env, (ana)?conda, easy_install, eggs and wheels ...IMO the problem here is that there isn't a monopoly and its easy to swap in a replacement. JavaScript/Python developers are happy (or willing) to try something new, so new alternatives are created. Convincing a Java developer to try a new build system is difficult, so changes are made to existing systems rather than creating new ones.Go and Rust are two other systems that work well and are (almost?) universally adopted. They come with the language and there is little reason to look around.

qbasic_forever · Answer

There is no real theory because it's a solved problem--packages and dependencies form a DAG or graph and it's just an ordering and traversal problem that's easily solved.The pain and fragmentation you're mentioning is that everyone has different opinions about how they want to configure/bundle/organize code and package metadata. That's really the only core difference between deb/rpm, npm/yarn, pip/poetry/conda/, handmade makefile/cmake/autotools/etc. People just had different ideas about how they wanted to do things at the periphery. At their core all of those tools are just simple DAG walkers.Basically, you're thinking it's a technical problem when in reality it's just a social issue. Some people prefer something one way, others prefer it the other way--there is no consensus (and likely never will be, people will always be building tools to do things their way).

emmelaich · Answer

> we apparently have no "package management theory"Honestly, I'd like to have a lowest common denominator of "just dump the contents of the tar/zip archive" here.Only check required would be to ensure you're not overwriting anything.Dependencies and PATH management etc could be done out-of-band. That way you would not have to re-download stuff at least.

jonfw · Answer

I am starting to see some consistency these days. I mostly work in Go, so I'm not intimately familiar with the state of the art in other languages, but it looks like most ecosystems have a tool that support this flow.A declarative (go.mod) file that always installs the same dependencies every build, a tool to update that lock file (go mod tidy), and an indication in the source that indicates how the dependency is being used (import).

lloydatkinson · Answer

Have you used nuget for .NET? I have to say I've never once run into any of the problems I encounter sometimes weekly with NPM for Node.

karel_3d · Answer

I like golang package management in practice - sure, you have the "v2" thing and "every package can bump any package if you're not careful", but it works in practice because people are careful, and the minimal version selection is always deterministic.The proxy thing and the drama with sr.ht is annoying, but maybe it was solved while I didn't look.

chubot · Answer

It's because the software ITSELF is structured poorly, not just the package managersBig pyramids of dependencies are inherently fragile (whether dynamically or statically typed)Dependency inversion can make it so that your dependency tree is exactly 1 deep, and it's dynamically wired together in main()But most people don't write code in that style. It takes extra effort

gwbas1c · Answer

In C#, I liked the pre-Nuget approach where you just made sure 3rd party dlls were in a location relative to source code control, (or in source code control if they were small.)Not really "package management," but it was straightforward and worked very well... (Until you had to juggle 32/64 bit native dlls.)

DemocracyFTW2 · Answer

If I wanted to point out what the greatest mistake in the conception of the NodeJS package manager&mdash;npm&mdash;is, its 'original sin', if you will, is the conceit that SemVer ('semantic versioning', a great idea in itself) is 100% reliable and that, therefore, it would be heretic or contradictory for a single module or sub-package in a project to ever want to `require()` two distinct versions of a module, say, xyz@1.0.1 and xyz@1.2.0. This is now fixed[1] but the developers stubbornly refused to see the occasional necessity of doing just this for many years.[1](https://medium.com/weekly-webtips/how-to-install-multiple-ve...)

Someone · Answer

If you let everyone and their dog create and maintain packages and package dependencies and leave it to them to declare forward/backward compatibility between versions of packages, and your package manager ends up being popular, I think it&rsquo;s unavoidable that you end up with a mess.Foo may not be updated for Bar 2.0, while the Baz you use states it needs it, Bar 3.0 may incorrectly declare to be a 100% stand-in for anything between Bar 1.5 and Bar 3.0, Baz and Qux may contain similar functions that would better be part of their shared dependency Quux, etc.Tooling can make navigating that mess more or less difficult, but the mess still is there.

Vosporos · Answer

You might want to check PackagingCon https://www.youtube.com/watch?v=bdX1XXpLFYY&list=PLl386dCR5Q...

maximumcomfy · Answer

A few reasons:1) Every developer no matter how new wants to contribute something. 2) There is no centralized authority in most languages/package system to stop them doing so 3) Imagine all the bad code you write in the first 2 years but now you can't delete it because 100 other developers rely on it and 100 other developers rely on themThe rube goldberg machine exists because of the matryoshka dolls that is the dependency tree. Sometimes rewriting things is actually easier than trying to untangle the wire of dependencies.

samsquire · Answer

I think the problem is the answer to this question:What is harder regarding computation - arranging for a computation or doing the computation?What I mean is that the computation of an addition or subtraction is easy but the arranging of instructions of code into an algorithm is hard. Everything has to be in the right place for the algorithm to work right.This is why packaging is so difficult. Each algorithm and code expects things to be in a certain place. ABIS and packaging for them is tedious.

PaulHoule · Answer

Pythoners have themselves to blame.The worst thing that happened to Python was that distributions like Red Hat not only shipped Python as an rpm but shipped system scripts in Python. This made it practically impossible to upgrade the system Python without breaking scripts and is fundamentally incompatible with how Python packaging works. (You are just one 'sudo pip install' from breaking your system)Like people who are impressed with ChatGPT (wow that answer seemed so confident even if it is wrong), Pythoners systematically mistake footguns for solutions. For instance, use 'pip install --user' and now the package you've included is visible when you type 'python', 'python3', use a venv, conda, whatever. I've had people tell me that having a 'python3' is the best idea anyone's had since Solomon proposed cutting a baby in half, but if you stop and think you realize that pretty soon you have 'python3', 'python3.5' (broken), 'python3.6' (maybe broken), 'python3.7', 'python3.8', 'python3.9', ...I would say venv's really solve the problem with the exception that you can currently trash all your venv's with 'pip install --user'.The trouble is that people who are bothered by this stop using Python, the people who are still using Python are people who have difficulty perceiving the nature of the problem never mind that there is a problem.The algorithm used by pip to resolve packages is not sound. It goes off trying to install things and can only find out late in the game that it installed a package which is not compatible with another package. This can be solidly blamed on the egg package format which can only determine the dependencies of a package when it tries to install it by running a setup.py. This is nice because it can adapt to the environment dynamically (say add a timezone db on windows) but it is not like Java's maven that knows it has a consistent solution before it downloads the JARs.I'm pretty sure you could make a Python package manager that works like Maven if it only installed wheels because you can read the directory of a wheel (a ZIP file) with one or two http range requests and then read the dependency data with another http range request. Poetry doesn't quite do this. Poetry does a lot better than pip does, but whatever it does takes a really, really, really, long time.Poetry might be the best thing going but it has the fundamental flaw of trying to be a 95% or 98% solution which, to the Pythoner, sounds like a good idea. The trouble is that writing programs that are 98% is to computer science what Bigfoot is to zoology or ESP is to psychology. The gap between that and 100% is not 2% but more like 200% because figuring out exactly what is wrong with the conceptual model and working around it in a hard case is at best like pushing a bubble under a rug. Imagine how much trouble you could get into with a 98% correct sort or binary search algorithm... It's a place where professional developers just don't want to go.Java has the advantage of extreme xenophobia and bad feelings all around that mean that: (1) people don't expect to link very much C code into Java, and (2) people don't feel entitled to use the Java bundled with their Linux system and have it really work. Because of (1), Java code tends to be self-sufficient and avoids a whole sector of 'dependency hell' involving .so and .dll files. Because of (2) people feel both responsible and empowered to install a JDK that works unlike the typical who Pythoner doesn't.Don't think that docker helps in any way, what I found what that Docker accelerates the ability of Pythoner to find pythons that are broken in odd ways, configured with strange default character sets and such.Javascript has the nice feature that file A can import from package version B and file C can import from package version D so that the 'diamond dependency' problems that are so terrible in Java (Like that bug in Guava post-13 that broke HDFS) and still problematic in Python rarely produce problems. (You only have problems if an object from A migrates to C and it gets used in incompatible way, contrast that to Java where probably the classloader blows up)I was wishing over the weekend that Python had something like that because once more I have been building and packaging machine learning models for inference in Python and it would be really sweet to pack up a model that uses scikit-learn or pytorch or whatever into a Python package and then load it into a web server or a batch job. It's totally practical to do that, using joblib to unpickle a few MB of code. Once you end up needing two different versions of pytorch though, you are really screwed.

drewcoo · Answer

Because of a surplus of worn out boots, candles, chickens, bowling balls (all bygone common, everyday, understandable items), and human invention (meaning "copying" badly, wheel reinvention - seldomly punctuated with novel synthesis).Or was that open source software? Or was that any private corporate software ecosystem? If I squint the problems all start to look the same. I must need glasses, considering my squint frequency.

ttyprintk · Answer

It sounds like you&rsquo;re familiar with the status quo, so let&rsquo;s look at this as a matter of requirements:- Cross-platform - Wraps another packaging format - Lowest disk space - Dependency version solving - An OS can run make changes to its own low-level state using its own tools - User can configure when and what are installedEven Nix, which has its own language and isolation model, can&rsquo;t meet all these.

conor_f · Answer

At least in Python's case, I think people are much too hard on the packaging system. I don't think anyone has significant issues with pip itself as opposed to the runtime it exists within.Following from this, I think that most back-end applications should try solve their messy runtime environment issues with some containerization. Java/C(++) however...

tstrimple · Answer

Almost any trivial application can be trivially implemented using these build systems. People encounter their own &ldquo;unique&rdquo; edge cases and build their own &ldquo;unique&rdquo; solutions to them. Over time, all these edge cases result in a proliferation of bubble gum, duct tape and baling wire that you&rsquo;ve described.

goodpoint · Answer

Because most developers don't learn from other projects and redo the same mistakes.It's a form of not-invented-here syndrome and you can see it in all the comments defending their favorite language..> we apparently have no "package management theory".Apparently. In reality there's been plenty of research - and for decades - that is not being used.

jerf · Answer

A solution can not be simpler than the problem.The problem is a classic "looks simple until you really examine it".

tbarone · Answer

I'll say that on the whole it seems to be getting better with time. Most people have already mentioned Rust / Go as examples of this.I do agree it is an issue. Doing away with node_modules completely on the last rails 7 app I worked on was the most cathartic experience of my life.

digitalpacman · Answer

Have you experienced nuget? Seems pretty solved and solid and unchanged since... forever now.

intrasight · Answer

I'd think that with all the CS PhDs, there'd be some academic work in this area. I haven't gone looking.My experience as a .Net developer has not been that it's a Rube Goldberg machine. I isolate all my projects and minimize 3rd party dependencies.

Falkon1313 · Answer

I don't see many complaints about Free Pascal/Delphi. You want a unit? Get it, add it, use it.No 3rd party Rube Goldberg contraption needed. No package managers or dependency resolvers, no special build tooling, no lock files. No constantly having to run updates and figure out what they broke by way of transitive dependencies. Just get what you need and use it.I haven't, however, developed enough professionally with it to know how that plays out long-term in practice. But I'd have to imagine it would compare favorably to just about everything else nowadays. The things I've been using for the last couple of decades are all pretty abysmal in comparison.I'd say they were a solution in search of a problem, but people have managed to create a problem to justify the solution, which really still isn't very good. At least, not nearly as good as the simple get, add, use pattern.

Dowwie · Answer

Your mistake is in the use of the word "every" when in fact you've only considered a few. Rust, for instance, uses cargo for packaging and it's probably the most intuitive part of Rust (/s).

al2o3cr · Answer

TBH I think you may just have a sampling problem - the JS and Python spaces have two of the messiest package-management ecosystems.

badpun · Answer

> neat-and-tidy (...) C++.This is a huge oxymoron. Additionally, C++ does not even have a package manager.

noloblo · Answer

What about haskell cabal and stack

icelancer · Answer

I just spent a few hours in npm/node/heroku hell, so... yeah. It's awful.

Quequau · Answer

Rube Goldberg was a prophet.

sinenomine · Answer

"The entropy-pool, a reservoir of dumped complexity"

onion2k · Answer

Scope creep.