Hacker News Reader

Comment by mobilemidget | Hacker News Reader

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...

View on HN

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.

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.

> 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.

> 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.

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.

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.

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.)

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)

I can sympathize with that, I'm very particular about some elements of my workflow. But when you decide to go homegrown rather than turnkey, you do accept responsibility for maintenance. It also seems to me that you can call Cargo from cmake if you so desire.

I would be very surprised if changing the arguments to rustc (or the equivalent in any language) wasn't considered a breaking change, so I'm not sure how well founded your skepticism is. If it's poorly documented, that is a shame.

Reply on news.ycombinator.com