3 ms·

Isn't this what forks are meant for? Fork FreeBSD to RustBSD and experiment? Personally I'd prefer if it stays out of FreeBSD. All languages with package syste

Isn't this what forks are meant for? Fork FreeBSD to RustBSD and experiment? Personally I'd prefer if it stays out of FreeBSD. All languages with package systems turn into a horrible quality over time. PHP Composer, Python Pip, node NPM and so on, initially it seems effective but the version dependency/issue hells are true nightmares. And I fear rust with cargo is going to be the same. Maybe I'm wrong, and in case it does go into base, I really hope I'm wrong so the quality of FreeBSD doesn't go down...

majewsky 2y ago
You could say the same about C library dependency hell. I have not used FreeBSD myself, but if I'm remembering correctly, the main reason that dependency hell does not affect the BSDs is that they have their own internal set of C libraries that are developed in tandem. As an OS vendor, FreeBSD could do something like that with Rust. If a Rust application is developed inside the FreeBSD source tree, make it so that it can only use the Rust standard library plus whatever libraries exist inside the FreeBSD source tree.
- pjmlp 2y ago
  Just like any UNIX proper, the ways of GNU/Linux are the exception. And non-UNIX OSes, where by definition C library belongs to the compiler it is shipped with.
deleted 2y ago
[deleted]
emporas 2y ago
> All languages with package systems turn into a horrible quality over time. If a new package manager (or the existing one, cargo) tries to fetch packages and doesn't fetch it correctly, the users will be faced with thousands of compilation errors in a moments notice. The new package manager will be abandoned, or the users will revert the existing one to a previous version in which it worked as expected.
quectophoton 2y ago
> Isn't this what forks are meant for? Fork FreeBSD to RustBSD and experiment? There's even a precedent for this, check out DragonFly BSD if interested in reading more.
maxbond 2y ago
Is there reason to believe that language package managers are universally destined to decline in quality rather than, for instance, that we've made progress one bad package manager at a time? I also don't see reason to declare npm to be a failure, and frankly pip was never good. Cargo is excellent. I don't see why it would decline.
- bluGill 2y ago
  I'm sure cargo is great if you only write rust. However the world is more than rust and so a languare package manager doesn't work well.
  - maxbond 2y ago
    I don't really understand what you're getting at. No language should provide a package manager? All languages should use the same package manager? That seems unnecessarily constrained and coupled. This is all so vague, and that confuses me. Language package managers are "destined to decline in quality" for unstated reasons. Language package managers are "don't work well" because there are multiple languages (and I presume you also mean multiple operating systems/distributions). That argument would seem to apply equally well to any package manager (including those maintained by OSs), so why are we singling any of them out? (Cargo does have a build script mechanism, with a major use case being integrating with other languages at compile time. Eg, running `make`. The other package managers I'm familiar with have similar mechanisms. I would assume they all do, since it's a problem they all have.)
    - bluGill 2y ago
      I do not know of a solution. I'm pointing out a problem. > Cargo does have a build script mechanism, with a major use case being integrating with other languages at compile time I already use cmake and my own custom build environment manager. While there are warts it is setup and works well enough that I don't want to switch. But rust wants me to forget about all that and use cargo. While in theory I can use something else, they don't bother documenting those workflows (I'm not convinced they will keep them working if I do get it working)

majewsky 2y ago

You could say the same about C library dependency hell. I have not used FreeBSD myself, but if I'm remembering correctly, the main reason that dependency hell does not affect the BSDs is that they have their own internal set of C libraries that are developed in tandem. As an OS vendor, FreeBSD could do something like that with Rust. If a Rust application is developed inside the FreeBSD source tree, make it so that it can only use the Rust standard library plus whatever libraries exist inside the FreeBSD source tree.

pjmlp 2y ago
Just like any UNIX proper, the ways of GNU/Linux are the exception. And non-UNIX OSes, where by definition C library belongs to the compiler it is shipped with.

deleted 2y ago

[deleted]

emporas 2y ago

> All languages with package systems turn into a horrible quality over time. If a new package manager (or the existing one, cargo) tries to fetch packages and doesn't fetch it correctly, the users will be faced with thousands of compilation errors in a moments notice. The new package manager will be abandoned, or the users will revert the existing one to a previous version in which it worked as expected.

quectophoton 2y ago

> Isn't this what forks are meant for? Fork FreeBSD to RustBSD and experiment? There's even a precedent for this, check out DragonFly BSD if interested in reading more.

maxbond 2y ago

Is there reason to believe that language package managers are universally destined to decline in quality rather than, for instance, that we've made progress one bad package manager at a time? I also don't see reason to declare npm to be a failure, and frankly pip was never good. Cargo is excellent. I don't see why it would decline.

bluGill 2y ago
I'm sure cargo is great if you only write rust. However the world is more than rust and so a languare package manager doesn't work well.
- maxbond 2y ago
  I don't really understand what you're getting at. No language should provide a package manager? All languages should use the same package manager? That seems unnecessarily constrained and coupled. This is all so vague, and that confuses me. Language package managers are "destined to decline in quality" for unstated reasons. Language package managers are "don't work well" because there are multiple languages (and I presume you also mean multiple operating systems/distributions). That argument would seem to apply equally well to any package manager (including those maintained by OSs), so why are we singling any of them out? (Cargo does have a build script mechanism, with a major use case being integrating with other languages at compile time. Eg, running `make`. The other package managers I'm familiar with have similar mechanisms. I would assume they all do, since it's a problem they all have.)
  - bluGill 2y ago
    I do not know of a solution. I'm pointing out a problem. > Cargo does have a build script mechanism, with a major use case being integrating with other languages at compile time I already use cmake and my own custom build environment manager. While there are warts it is setup and works well enough that I don't want to switch. But rust wants me to forget about all that and use cargo. While in theory I can use something else, they don't bother documenting those workflows (I'm not convinced they will keep them working if I do get it working)