4 ms·

Rust finally got hit... This was motivating me to swap away from Rust towards because of the huge number of dependencies. It seemed inevitable. Ginger bill was

Rust finally got hit... This was motivating me to swap away from Rust towards because of the huge number of dependencies. It seemed inevitable. Ginger bill was right, https://www.gingerbill.org/article/2025/09/08/package-managers-are-evil/ https://www.gingerbill.org/article/2025/09/08/package-manage...

Ygg2 1mo ago
Honestly, Ginger Bill is plain wrong. Just because you don't develop a package manager for your language, doesn't mean someone else won't. See NPM.
- beanjuiceII 1mo ago
  yep which people have already done in odin
- aselimov3 1mo ago
  Well I think the main important argument here is you shouldn't use the package management. A third party package manager would be even more concerning to use imo. I generally try to stay away from the typescript world so unfamiliar with nuances of NPM.
  - Ygg2 1mo ago
    Sure. And people shouldn't steal people's credentials and publish malicious artifacts, yet here we are. Just because you expect people to behave like X doesn't mean they will. In this case people will automate packaging of artifacts. NPM was a third party manager (it's not part of EcmaScript nor was it part of Node.js at start) and so is Maven. Reputation matters more than origin. Those who do not know history are doomed to rediscover it.
jooops1 1mo ago
The author proposes to reinvent the wheel and depend on stale dependencies, which are EOL. Neither of that is an acceptable solution with LLM-based Agents being able to produce exploit(ExploitGym) chains in minutes from known bugs. The other issue is that Rust's forces the user to provide more information and APIs are usually kept generic for systems programmer, so standardizing things is not as straight-forward compared to Go where you can assume a memory-management, a virtual thread runtime and mostly ignore dynamic dispatching.
- aselimov3 1mo ago
  I don't think anyone is saying that you should depend on stale dependencies. You should not hand off your responsiblity to untrustworthy package managements services though. Evidence of the failure of automated package management is the near constant shai-hulud attacks as well as the originating post here. The fact is that your dependencies are your responsibility. You should be staying up to date on what you depend on and their vulnerabilities. Most vulnerabilities affect specific code paths which may not be present in your code base and do not require mitigation. These are decisions you can make by understanding what your dependencies are instead of offloading to automated package management systems. NPM has been the posterchild of these types of issues but the dependency stack I saw everytime I compiled even simple programs in Rust made me think Rust would be impacted next. Personally I think third party modules that are effectively universally used (axum, tokio, serde) should be integrated directly into the language.

Ygg2 1mo ago

Honestly, Ginger Bill is plain wrong. Just because you don't develop a package manager for your language, doesn't mean someone else won't. See NPM.

beanjuiceII 1mo ago
yep which people have already done in odin
aselimov3 1mo ago
Well I think the main important argument here is you shouldn't use the package management. A third party package manager would be even more concerning to use imo. I generally try to stay away from the typescript world so unfamiliar with nuances of NPM.
- Ygg2 1mo ago
  Sure. And people shouldn't steal people's credentials and publish malicious artifacts, yet here we are. Just because you expect people to behave like X doesn't mean they will. In this case people will automate packaging of artifacts. NPM was a third party manager (it's not part of EcmaScript nor was it part of Node.js at start) and so is Maven. Reputation matters more than origin. Those who do not know history are doomed to rediscover it.

jooops1 1mo ago

The author proposes to reinvent the wheel and depend on stale dependencies, which are EOL. Neither of that is an acceptable solution with LLM-based Agents being able to produce exploit(ExploitGym) chains in minutes from known bugs. The other issue is that Rust's forces the user to provide more information and APIs are usually kept generic for systems programmer, so standardizing things is not as straight-forward compared to Go where you can assume a memory-management, a virtual thread runtime and mostly ignore dynamic dispatching.

aselimov3 1mo ago
I don't think anyone is saying that you should depend on stale dependencies. You should not hand off your responsiblity to untrustworthy package managements services though. Evidence of the failure of automated package management is the near constant shai-hulud attacks as well as the originating post here. The fact is that your dependencies are your responsibility. You should be staying up to date on what you depend on and their vulnerabilities. Most vulnerabilities affect specific code paths which may not be present in your code base and do not require mitigation. These are decisions you can make by understanding what your dependencies are instead of offloading to automated package management systems. NPM has been the posterchild of these types of issues but the dependency stack I saw everytime I compiled even simple programs in Rust made me think Rust would be impacted next. Personally I think third party modules that are effectively universally used (axum, tokio, serde) should be integrated directly into the language.