this post was submitted on 06 Aug 2026
86 points (97.8% liked)
Programming
28009 readers
409 users here now
Welcome to the main community in programming.dev! Feel free to post anything relating to programming here!
Cross posting is strongly encouraged in the instance. If you feel your post or another person's post makes sense in another community cross post into it.
Hope you enjoy the instance!
Rules
Rules
- Follow the programming.dev instance rules
- Keep content related to programming in some way
- If you're posting long videos try to add in some form of tldr for those who don't want to watch videos
Wormhole
Follow the wormhole through a path of communities !webdev@programming.dev
founded 3 years ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
It's been a while since I used it in earnest, so my memory is hazy enough that I can't be specific. One of the largest pieces of work I've done in C++ was not writing C++, but working out how to ask bazel to build a single shared library that imports other bazel libraries. I've never used such a confusing and frustrating package manager. It was frequently unclear how to do things, despite the project having quite a lot of documentation.
When I read it supports multiple languages, I had two thoughts:
Thank you. I didn't expect that because I assume that packages are basically the same everywhere you go (at least in my experience). And managing them is basically solving dependency trees, then downloading files and putting them in the right place for the import system to find them.
But my experience with programming languages is limited. I haven't found a language that doesn't work this way.
I got the same feeling that it shouldn't be rocket science. Then again, I'm most experienced with C#, which is just a very clean and professional ecosystem, and I often experience that other languages can feel rough around the edges in comparison. E.g. in npm JS, different package managers create entirely different folder structures, even though the build system is 100% the same!
So maybe a package manager for C# would be straightforward, while npm JS would require a bunch of research about what happens behind the scenes.
And if other languages are similar to npm JS, it's easy to imagine that your want to keep languages separated for cleanliness - but then you kinda just get a bunch of one-language-package managers in a trenchcoat, so why even bother. OR you have the same code handling it all, becoming a bit of a mess.
Worth noting is that C# generally uses compiled libraries, not quite binaries but CIL rather than source code, so that's what you get when adding references and NuGet packages. And at the same time, compiled C# files include a lot of metadata about the code, like class structure and method signatures, so one .DLL is all you need to use a library.
NPM is a more complex situation. To say there is one build system is already misleading, since there isn't a build system built into JS - packages can be source distribution, or they can use a variety of tools, minifiers, packages for web or for Node, and occasionally include native libraries/binaries or otherwise compile native code from other sources.
I think generally new languages have their own package managers primarily because older languages weren't planned for convenient dependency management, so solutions for that are stapled on top of their stuff, aren't compatible with existing libraries, often have some annoyances, and there are often multiple alternatives that were independently developed. On the other hand, new languages can just plan things out from the start, tweaking the language to work well for libraries, and establishing a single tool to avoid fragmentation.