4 ms·

> No package manager Ginger Bill famously hates package managers, so if the lack of one is a deal breaker for someone they might as well look for a different l

> No package manager Ginger Bill famously hates package managers, so if the lack of one is a deal breaker for someone they might as well look for a different language.

Ygg2 1y ago
Not that it stopped people in the past from adding their own. See JS.
- scuff3d 1y ago
  Yeah. If it gets popular enough someone will build one, or get it working with an existing manager.
bxparks 1y ago
Do you happen to know why? A package manager system seems essential for sharing and reusing code with other people. For example, I don't particularly like Python as a language, but I will use it because it has 677,633 packages in PyPI.
- badsectoracula 1y ago
  > 677,633 packages in PyPI. Chances are 677,634 of those will be broken next week though :-P The problem with package managers is that they encourage piling on dependencies and creating deep (and thus fragile and often hard to reason about) dependency trees. I loathe having to install anything more complicated than simple scripts[0] based on Python because unless the developer constantly chases after all their dependencies to keep them in working order, i'll be the one who will have to do that when something inevitably breaks (assuming it wasn't already broken the time i decided to try it - which is sadly something i encountered more than a few times). And once the developer moves on, the bitrot spreads alarmingly fast. [0] and even that isn't reliable if the scripts rely on more than whatever comes preinstalled with Python
  - bxparks 1y ago
    I'm not going to write things like Django, flask, requests, urllib3, numpy, scipy, mathplotlib, dateutils, and psycopg2 on my own. That would take multiple lifetimes. Sure, you can choose to write everything yourself, but you are limiting the size, scope, and complexity of the problems that you can solve. We have to stand upon the shoulders of others to get stuff done.
    - nemomarx 1y ago
      I think the suggestion here is to take a copy of those that you know works with your software and package in that particular version? instead of the user having to resolve conflicts or manage the dependencies
      - dwattttt 1y ago
        Those are properties of Python's package management strategy and language design, they're not inherent to package management.
    - skydhash 1y ago
      Package managers and libraries are orthogonal. if the language and the libraries are stable, you hardly need a package manager. And without one, I’d say you see much better quality in the wild.
    - badsectoracula 1y ago
      Nobody said to not use libraries. Hell, even the Odin site's main page links to one.
    - scuff3d 1y ago
      Meanwhile Ryan Fleury is writing a cross platform debugger almost entirely from scratch in C.
- forrestthewoods 1y ago
  He's written about it repeatedly. https://www.gingerbill.org/article/2025/09/08/package-managers-are-evil/ https://www.gingerbill.org/article/2025/09/08/package-manage... The short version is: projects should vendor their deps and manually resolve package versions. I don't think he states his argument very clearly. But I do think he's basically correct. Vendor your damn deps!
  - MattPalmer1086 1y ago
    Umm... What does "vendor your deps" mean? I have no idea what using the noun vendor as a verb means. I'm guessing deps is dependencies.
    - pansa2 1y ago
      https://stackoverflow.com/questions/26217488/what-is-vendoring https://stackoverflow.com/questions/26217488/what-is-vendori...
    - jenadine 1y ago
      https://en.wiktionary.org/wiki/vendor https://en.wiktionary.org/wiki/vendor > To bundle third-party dependencies with the source code for one's own program.
      - MattPalmer1086 1y ago
        Thanks. It's not a particularly clear term. Bundle might have been better!
        forrestthewoods 1y ago
        Bundle is both a noun and a verb the same as vendor! So not any better imho. I hate to say this, but vendor is an extremely common term for this operation. Rust’s cargo has a “vendor” sub command built in. You’re far from alone in not being familiar with the term. Which is a great travesty because it really should be considered best practice and default behavior!
- pansa2 1y ago
  > I will use it because it has 677,633 packages in PyPI Quality over quantity, please
- dismalaf 1y ago
  > Do you happen to know why? Look at Rust and NPM... Insane amounts of dependencies for almost every library. C and C++ famously don't have package managers, well, at least not blessed ones (although you could argue Linux/Unix is a C package manager). The idea is to be more informed about the dependencies you're bringing in, to encourage libraries to be more standalone things, and just not to automate dependency hell. On the plus side, the Odin compiler makes it very, very easy to compile your program with dependencies. Hell, even in my Ruby journey I've realised that 99% of what's on Rubygems is absolute trash. I basically use Rails, Faraday, RubyLLM, and not much else.
  - 1718627440 1y ago
    > C and C++ famously don't have package managers > although you could argue Linux/Unix [package managers] [are] C package manager[s] Exactly. It's just that they don't have the bug, that they only work with programs written in a single language.
  - skinnymuch 1y ago
    > Hell, even in my Ruby journey I've realised that 99% of what's on Rubygems is absolute trash. I basically use Rails, Faraday, RubyLLM, and not much else. Is this really the case? I just came back to Ruby and Rails recently. Haven’t explored that much yet beyond established major gems
    - dismalaf 1y ago
      I mean, trash is subjective. Certainly a lot of abandoned gems. Case in point, for one project, I needed to pull some financial data. So used an unofficial gem for that provider. It was a mess of spaghetti and object patterns for what could have been simply a few helpers, also dependencies that clashed with another gem I was using so I simply replicated the functionality myself in like, 100 lines of code. Btw, still worth it because Ruby is an amazing language and Rails is great. Just can't blindly trust other people's code.
- 1718627440 1y ago
  Because pulling in, updating and verifying code is fundamentally a responsibility of the OS. Also language specific package managers are kind of stupid.
  - sph 1y ago
    I never thought about it, but yeah, the concept of “fetch a repository of packages, resolve dependencies, download a tarball and put it in a special place on disk” is such a common operation that it should have been solved once and reusable across languages or anything else that needs this process (editor plugin, font management, gamedev and audio assets, OS packages, app store, etc.) Yet any language has to reinvent the wheel and write yet another archive downloader.
    - 1718627440 1y ago
      > Yet any language has to reinvent the wheel and write yet another archive downloader. No, I don't think they need to do that. They want to do that instead of using the already existing OS packager, breaking and messing up things left and right. Take for example the ridiculous state in the python ecosystem. It would be entirely eliminated by using the existing tools of make altinstall, the system-package manager and properly using Site files. I don't know when altinstall was introduced, but in this issue from 2013 it is already mentioned: https://bugs.python.org/issue19553 https://bugs.python.org/issue19553 . The OS package managers already go out of their way (e.g. Debian) and renamed site-packages to dist-packages, so that OS installed and other vendored python packages don't conflict. The Python maintainers provide make altinstall and the python program provides site files. Linux distros have /usr/ vs. /usr/local to avoid programs conflicting with the OS versions. So many problems could never occur by people using their tools correctly instead of adding layers on top, which causes other breakage and is "fixed" by even more layers on top.
- scuff3d 1y ago
  According to him, some things shouldn't be automated, and dependency hell is one of them. With package managers developers completely lose track of what code they're depending on, the quality of the code, and vulnerabilities it might have, etc. In addition they are probably pulling a ton of code they don't care about to do one thing, which leads to a lot of bloat. I think he would say either copy the code you want into your own project, or clone down the repo and control the code yourself. He hae interviews on Primeagens channel and Developer Voices where he talks about it.
FullGarden_S 1y ago
and yet it never truly became an issue at all because there is an officially maintained, high quality package collection. https://pkg.odin-lang.org/ https://pkg.odin-lang.org/ GingerBill and the Odin community put tremendous effort into making sure that the Odin compiler ships with "batteries included". You get base, core and vendor library collection that cover almost everything a developer would need to the point that you can argue that you don't need a package manager for Odin.
- Ygg2 1y ago
  That's great. But I need an Aerospike/YAML/JPEGXL/Slint libraries first thing in the morning. Is it in vendor package yet? No? Then Odin vendor package will be a bottleneck for development.
  - skydhash 1y ago
    I see binding, so maybe interops with C is trivial. And just like that, you’ll have the thousand existing C libraries.
    - Ygg2 1y ago
      Binding is one thing, having idiomatic library is another.
  - FullGarden_S 1y ago
    All the things you demanded require a significant amount of financial support to both create and maintain, and that is where Odin falls short. If you really do need all those libraries first thing in the morning, then forget about the language; it's out of your hands. You will always be at the mercy of the industry, and you will be forced to pick and use whatever language the majority of the industry is using while the industry keeps tailoring the majorly adapted languages to do things the languages weren't designed for in the first place. Also, all the libraries you demanded have almost nothing to do with the language itself. Odin, as a solo project, lacks both the financial backing and the cult-like obsessive adoption within its community-both of which are essential for breaking into the industry and reaching the mainstream status. It's the industry's adaptability and the community's enthusiasm that determine how many new libraries will emerge for a programming language. Unlike modern languages like Rust and Zig, which have their respective foundation organizations that employ and pay several full-time developers, languages like Odin and C3 that stripped-down complexity and subjectively annoying features got no serious fancy features to market to the target consumers, making it hard for them to gain any exponential momentum. So, give the current state of things, we can certainly say that Odin will not provide any of those libraries any time soon. Besides, the Odin developers are perfectly fine using libraries written in other languages, whether Rust, C, or anything else. If a library in another language works and will get the job done, re-writing it in Odin is logically pointless for getting the job done. The only people who seem to have an issue with Odin's ecosystem are backend developers. Low-level systems programmers and graphics developers have their needs well met(there are no built-in green threads or fibers but there is support for SIMD and all major graphics API bindings). Networking requires stable, secure maintenance, so unless someone from the community steps up to create and maintain an HTTP/3 or QUIC implementation, there will never be native HTTP/3 support in Odin. The same applies to Aerospike, YAML, JPEG XL, Slint, and everything else. Gotta see how things will turn out.

> No package manager Ginger Bill famously hates package managers, so if the lack of one is a deal breaker for someone they might as well look for a different language.

Ygg2 1y ago

Not that it stopped people in the past from adding their own. See JS.

scuff3d 1y ago
Yeah. If it gets popular enough someone will build one, or get it working with an existing manager.

bxparks 1y ago

Do you happen to know why? A package manager system seems essential for sharing and reusing code with other people. For example, I don't particularly like Python as a language, but I will use it because it has 677,633 packages in PyPI.

badsectoracula 1y ago
> 677,633 packages in PyPI. Chances are 677,634 of those will be broken next week though :-P The problem with package managers is that they encourage piling on dependencies and creating deep (and thus fragile and often hard to reason about) dependency trees. I loathe having to install anything more complicated than simple scripts[0] based on Python because unless the developer constantly chases after all their dependencies to keep them in working order, i'll be the one who will have to do that when something inevitably breaks (assuming it wasn't already broken the time i decided to try it - which is sadly something i encountered more than a few times). And once the developer moves on, the bitrot spreads alarmingly fast. [0] and even that isn't reliable if the scripts rely on more than whatever comes preinstalled with Python
- bxparks 1y ago
  I'm not going to write things like Django, flask, requests, urllib3, numpy, scipy, mathplotlib, dateutils, and psycopg2 on my own. That would take multiple lifetimes. Sure, you can choose to write everything yourself, but you are limiting the size, scope, and complexity of the problems that you can solve. We have to stand upon the shoulders of others to get stuff done.
  - nemomarx 1y ago
    I think the suggestion here is to take a copy of those that you know works with your software and package in that particular version? instead of the user having to resolve conflicts or manage the dependencies
    - dwattttt 1y ago
      Those are properties of Python's package management strategy and language design, they're not inherent to package management.
  - skydhash 1y ago
    Package managers and libraries are orthogonal. if the language and the libraries are stable, you hardly need a package manager. And without one, I’d say you see much better quality in the wild.
  - badsectoracula 1y ago
    Nobody said to not use libraries. Hell, even the Odin site's main page links to one.
  - scuff3d 1y ago
    Meanwhile Ryan Fleury is writing a cross platform debugger almost entirely from scratch in C.
forrestthewoods 1y ago
He's written about it repeatedly. https://www.gingerbill.org/article/2025/09/08/package-managers-are-evil/ https://www.gingerbill.org/article/2025/09/08/package-manage... The short version is: projects should vendor their deps and manually resolve package versions. I don't think he states his argument very clearly. But I do think he's basically correct. Vendor your damn deps!
- MattPalmer1086 1y ago
  Umm... What does "vendor your deps" mean? I have no idea what using the noun vendor as a verb means. I'm guessing deps is dependencies.
  - pansa2 1y ago
    https://stackoverflow.com/questions/26217488/what-is-vendoring https://stackoverflow.com/questions/26217488/what-is-vendori...
  - jenadine 1y ago
    https://en.wiktionary.org/wiki/vendor https://en.wiktionary.org/wiki/vendor > To bundle third-party dependencies with the source code for one's own program.
    - MattPalmer1086 1y ago
      Thanks. It's not a particularly clear term. Bundle might have been better!
      - forrestthewoods 1y ago
        Bundle is both a noun and a verb the same as vendor! So not any better imho. I hate to say this, but vendor is an extremely common term for this operation. Rust’s cargo has a “vendor” sub command built in. You’re far from alone in not being familiar with the term. Which is a great travesty because it really should be considered best practice and default behavior!
pansa2 1y ago
> I will use it because it has 677,633 packages in PyPI Quality over quantity, please
dismalaf 1y ago
> Do you happen to know why? Look at Rust and NPM... Insane amounts of dependencies for almost every library. C and C++ famously don't have package managers, well, at least not blessed ones (although you could argue Linux/Unix is a C package manager). The idea is to be more informed about the dependencies you're bringing in, to encourage libraries to be more standalone things, and just not to automate dependency hell. On the plus side, the Odin compiler makes it very, very easy to compile your program with dependencies. Hell, even in my Ruby journey I've realised that 99% of what's on Rubygems is absolute trash. I basically use Rails, Faraday, RubyLLM, and not much else.
- 1718627440 1y ago
  > C and C++ famously don't have package managers > although you could argue Linux/Unix [package managers] [are] C package manager[s] Exactly. It's just that they don't have the bug, that they only work with programs written in a single language.
- skinnymuch 1y ago
  > Hell, even in my Ruby journey I've realised that 99% of what's on Rubygems is absolute trash. I basically use Rails, Faraday, RubyLLM, and not much else. Is this really the case? I just came back to Ruby and Rails recently. Haven’t explored that much yet beyond established major gems
  - dismalaf 1y ago
    I mean, trash is subjective. Certainly a lot of abandoned gems. Case in point, for one project, I needed to pull some financial data. So used an unofficial gem for that provider. It was a mess of spaghetti and object patterns for what could have been simply a few helpers, also dependencies that clashed with another gem I was using so I simply replicated the functionality myself in like, 100 lines of code. Btw, still worth it because Ruby is an amazing language and Rails is great. Just can't blindly trust other people's code.
1718627440 1y ago
Because pulling in, updating and verifying code is fundamentally a responsibility of the OS. Also language specific package managers are kind of stupid.
- sph 1y ago
  I never thought about it, but yeah, the concept of “fetch a repository of packages, resolve dependencies, download a tarball and put it in a special place on disk” is such a common operation that it should have been solved once and reusable across languages or anything else that needs this process (editor plugin, font management, gamedev and audio assets, OS packages, app store, etc.) Yet any language has to reinvent the wheel and write yet another archive downloader.
  - 1718627440 1y ago
    > Yet any language has to reinvent the wheel and write yet another archive downloader. No, I don't think they need to do that. They want to do that instead of using the already existing OS packager, breaking and messing up things left and right. Take for example the ridiculous state in the python ecosystem. It would be entirely eliminated by using the existing tools of make altinstall, the system-package manager and properly using Site files. I don't know when altinstall was introduced, but in this issue from 2013 it is already mentioned: https://bugs.python.org/issue19553 https://bugs.python.org/issue19553 . The OS package managers already go out of their way (e.g. Debian) and renamed site-packages to dist-packages, so that OS installed and other vendored python packages don't conflict. The Python maintainers provide make altinstall and the python program provides site files. Linux distros have /usr/ vs. /usr/local to avoid programs conflicting with the OS versions. So many problems could never occur by people using their tools correctly instead of adding layers on top, which causes other breakage and is "fixed" by even more layers on top.
scuff3d 1y ago
According to him, some things shouldn't be automated, and dependency hell is one of them. With package managers developers completely lose track of what code they're depending on, the quality of the code, and vulnerabilities it might have, etc. In addition they are probably pulling a ton of code they don't care about to do one thing, which leads to a lot of bloat. I think he would say either copy the code you want into your own project, or clone down the repo and control the code yourself. He hae interviews on Primeagens channel and Developer Voices where he talks about it.

FullGarden_S 1y ago

and yet it never truly became an issue at all because there is an officially maintained, high quality package collection. https://pkg.odin-lang.org/ https://pkg.odin-lang.org/ GingerBill and the Odin community put tremendous effort into making sure that the Odin compiler ships with "batteries included". You get base, core and vendor library collection that cover almost everything a developer would need to the point that you can argue that you don't need a package manager for Odin.

Ygg2 1y ago
That's great. But I need an Aerospike/YAML/JPEGXL/Slint libraries first thing in the morning. Is it in vendor package yet? No? Then Odin vendor package will be a bottleneck for development.
- skydhash 1y ago
  I see binding, so maybe interops with C is trivial. And just like that, you’ll have the thousand existing C libraries.
  - Ygg2 1y ago
    Binding is one thing, having idiomatic library is another.
- FullGarden_S 1y ago
  All the things you demanded require a significant amount of financial support to both create and maintain, and that is where Odin falls short. If you really do need all those libraries first thing in the morning, then forget about the language; it's out of your hands. You will always be at the mercy of the industry, and you will be forced to pick and use whatever language the majority of the industry is using while the industry keeps tailoring the majorly adapted languages to do things the languages weren't designed for in the first place. Also, all the libraries you demanded have almost nothing to do with the language itself. Odin, as a solo project, lacks both the financial backing and the cult-like obsessive adoption within its community-both of which are essential for breaking into the industry and reaching the mainstream status. It's the industry's adaptability and the community's enthusiasm that determine how many new libraries will emerge for a programming language. Unlike modern languages like Rust and Zig, which have their respective foundation organizations that employ and pay several full-time developers, languages like Odin and C3 that stripped-down complexity and subjectively annoying features got no serious fancy features to market to the target consumers, making it hard for them to gain any exponential momentum. So, give the current state of things, we can certainly say that Odin will not provide any of those libraries any time soon. Besides, the Odin developers are perfectly fine using libraries written in other languages, whether Rust, C, or anything else. If a library in another language works and will get the job done, re-writing it in Odin is logically pointless for getting the job done. The only people who seem to have an issue with Odin's ecosystem are backend developers. Low-level systems programmers and graphics developers have their needs well met(there are no built-in green threads or fibers but there is support for SIMD and all major graphics API bindings). Networking requires stable, secure maintenance, so unless someone from the community steps up to create and maintain an HTTP/3 or QUIC implementation, there will never be native HTTP/3 support in Odin. The same applies to Aerospike, YAML, JPEG XL, Slint, and everything else. Gotta see how things will turn out.