Hacker News Reader

> Cargo and Rustup seem to be in competition to the existing package management systems. Why not integrate rust and the libraries into the existing packagement systems, like so many other software projects do? How is Cargo and rustup better than Apt?

> Also, Apt is perfectly usable without internet. One can download the entire Debian archive to a hard drive and use it without any external connections. How would I do that with Cargo and Rustup? This is just one point. There are so many scenarios Apt already has solutions for, that Cargo and Rustup probably didn't even consider yet.

You can't simply ignore 98% of the users of other operating systems just because it happens for you today to use a Debian based system. The fact that Rust has an OS independent package manager is a huge plus for Rust adoption.

I didn't mean to exclude other systems by naming Apt, it was rather meant as an example. The non-Debian based systems, and even the non-Linux based systems are important.

I agree that an OS independent package manager is a plus for Rust adoption. I also think it cannot replace the OS package managers, and therefore Rust should also play nice with them, and integrate as much as possible.

Well, now you've got to have people covering those integrations with apt, pacman, homebrew, etc. And instead of this work benefiting everyone, it just kind of benefits some people. Not saying that means you ignore the idea, but especially an early stage language is going to prioritise trying to answer questions that improve life for the majority of its users, and things that are most demanded by interested, but for some reason dissuaded potential users.

You're welcome! And thanks for your posts too.

> WebAssembly is essentially the same as JavaScript

In some senses, but not others. Regardless of personal feelings though, WebAssembly isn't just happening, it's already happened. And also regardless of personal feelings, many people in the Rust world seem to be very excited about WebAssembly; see https://mgattozzi.com/rust-wasm for example.

(I personally am very interested, but if the community was against it, would accept that. It seems like the majority, at this time, is pretty pro.)

> How is Cargo and rustup better than Apt?

There's a multitude of ways to tackle this problem, but I'll give you the biggest one: I'm a Windows user these days. Apt is 100% useless to me. This problem is the same even on Linuxes, while I do use Debian, I used to use Arch: Apt would be 100% useless to me.

> Apt is perfectly usable without internet.

Cargo is perfectly usable without internet. It's a hard requirement of projects like Firefox, and the various distros that are shipping Rust today. Now, we want to make it even easier to use without internet, so there's work to be done, but the fundamentals already exist and are used in production systems today.

> Another thing I forgot to mention is IDE support.

Yeah, this is super huge, agreed. We've been working on various things, but obviously it depends on what IDE you use, and there's a long tail there. We'll get there!

> You're welcome! And thanks for your posts too.

Thanks :-)

> And also regardless of personal feelings, many people in the Rust world seem to be very excited about WebAssembly

WebAssembly and JavaScript are used to create locked-in software to deliver uncopyable experiences, to ultimately exercise power over other people. Clearly, there will be people interested in this, because the power can be used to generate profit. Ethically, I think it must not be supported. It goes frontally against the idea and intent of free software. I think this problem is glaring, and I'm interested in your view about this very aspect.

> How is Cargo and rustup better than Apt?

I didn't mean to restrict this to Apt. Many projects and programming languages are available on multiple platforms, all while playing nice with the existing package management systems. Apt is not special in this regard, and was just used as an example.

> I'm interested in your view about this very aspect.

I'm conflicted. I personally waver between "stallman is always right" and "free software misses the point" near constantly, myself. With regards to WebAssembly, it's also complicated. You can argue that JavaScript is basically in the same place, and so for me, it's kind of a moot point. That is, there's no requirement for JavaScript to be free software today either. In practice, obfuscated/minified JS and WebAssembly are basically the same, with the exception that the tooling for de-{obfuscating,compiling} JS is currently more robust and mature since it's been around a lot longer.

TL;DR: I don't think that WebAssembly really changes the game here, for good or for bad.

> I didn't mean to restrict this to Apt

Quite fair! And as I alluded to above, it's not just the thing that I posted. This is quite long but I have little time, so I'm gonna be brief. https://medium.com/@sdboyer/so-you-want-to-write-a-package-m... basically is, IMO, the gold standard for talking about these things. However, I think the distinction of OS/system package manager vs Language package manager is important. Basically, Cargo and Apt (I'll follow your lead here with using Apt as a standin) have very different goals, and very different constants. This is because they're doing two very different jobs. Specifically, system package managers are about providing a unified set of packages to end-users. Language package managers are for developers to build applications.

With Cargo, we've very strongly stayed away from giving it any sort of "system package manager" features, because that's not what we're trying to do. However, at some point, a developer delivers an application to an end user, and so I agree strongly that Cargo should play well with Apt. It cannot, however, be replaced by Apt. To that end, I think tools like https://crates.io/crates/debcargo are the path forward, and in fact that tool is (in my understanding) being used by Debian to manage this bridge. I would love to have a simple Cargo command to generate a compatible system package for any of these systems. It's a long tail thing though, so it's gonna take some time.

Anyway, yeah, that's the root of it. There's tons of other details too. Package management is a very hard thing. Maybe someday I'll write a blog post about all of this at length, when I have the time.

> Many projects and programming languages are available on multiple platforms, all while playing nice with the existing package management systems

What's the gold standard example for you, exempting C and C++?

I'll try to keep it brief this time.

> TL;DR: I don't think that WebAssembly really changes the game here, for good or for bad.

It's a step in the wrong direction. Working on WebAssembly is not as bad as it could be because there already is JavaScript, but instead of working on WebAssembly, I think we should bury JavaScript.

> Package management is a very hard thing. Maybe someday I'll write a blog post about all of this at length, when I have the time.

Fair enough. Looking forward to it.

> What's the gold standard example for you, exempting C and C++?

Maybe Python on Debian. But why shouldn't C be the benchmark? And why compare to another language instead of what's desireable?

> Maybe Python on Debian.

Cool, thanks. I'll look into it. I'm more familiar with Ruby and Debian which has a... storied history :)

> But why shouldn't C be the benchmark?

In some sense, it shouldn't, I'm in agreement that in some sense, we should talk about what's desireable. However, there's a reason that it's significant: apt is designed around C. Its compilation model, everything. So of course C works with apt very well; I'd hope so! But non-C languages have a much larger hurdle. In terms of Rust's integration into a system, it'd face challenges similar to non-C than to C.

> apt is designed around C

It would be nice to have a list of what each of Apt, Pacman and Portage needed to change to accommodate Rusts needs.

Thanks for your comments!

Arch is already packaging Rust applications. One of mine is in the community repo. People are working on debs, but it's slow going: https://github.com/BurntSushi/ripgrep/issues/10

There's also another split, honestly. Anyone can make an Apt package, but getting your apt package into Debian is another story. There's friction in both sides. Most of them are related to (very sensible when talking about C) distro policies. It's as much cultural as it is technical.

Someday I might write some of this up, but honestly, I deeply appreciate the work that the humans who build OS packages do, and don't really want to add more friction to the pile, or appear to be denigrating their work. It's more likely to just be an "argue on the internet" situation than actually cause any change that'd be helpful.

To be clear, again, this stuff already works. It's about the difference between "easy" and "possible".

> Specifically, system package managers are about providing a unified set of packages to end-users. Language package managers are for developers to build applications.

One thing that might help people see this distinction better is if Cargo offered better post-build hooks to allow community-driven add-ons that handle packaging for the various system package managers. If a Rust developer could run cargo dist-package (or whatever it's called) and have it build a deb/rpm/pkg/msi, it'd be really easy to use cargo for the development phase and the other package managers for the distribution phase. As it is, if I want to run someone else's Rust software, I'm basically using cargo install to pull from crates and build locally.

You don't need hooks to do that today; name an executable `cargo-dist-package`, put it in your $PATH, and `cargo dist-package` Just Works. Well, you still have to implement it, but the workflow is there. Have it invoke `cargo build` and you're good to go.

We've been wary to add more hooks because then you can start to emulate a system package manager with them.

It's not just triggers, though having the post-build equivalent of build.rs would be a nice feature that doesn't really change the nature of cargo in any way. It would be quite useful for doing post-build logic...for example, when building a Neon module for Node, the dylib is that cargo compiles doesn't have the .node extension that Node wants it to have. It'd be a lot simpler (and more portable) to just put that rename into a post-build.rs rather than having to do it after every build or, as I do now, using a justfile to run both commands.

But 'hooks' also means making cargo more extensible. IIRC, cargo will error out if it finds a key in Cargo.toml that it doesn't recognize. It would be nice to be able to store configurations for extensions to the cargo build lifecycle in that file as well. Cargo could just ignore them. Also, it'd be nice to have a crate to read and safely write from/to Cargo.toml to make it easy for extension executables like you mentioned to use information about the build.

Just being able to pass through to an executable in $PATH isn't really enabling much and, aside from that, cargo seems pretty hostile towards implementing features that the team doesn't believe in. I guess what I'm advocating for is providing generic extension points in Cargo and then sitting back to watch what the community comes up with. My experience with the Rust community is that there are a lot of exceptionally smart developers who love the language and the tooling and I think we'd get a lot of exciting and creative features if the main team were removed from the critical path. A more organic approach to evolving the way we build Rust code might come up with something better and can serve as free user research for what should be included in the official cargo tool and become the officially-recommended best practice.

I hear you. I'm of two minds about this.

> I'm conflicted. I personally waver between "stallman is always right" and "free software misses the point" near constantly, myself.

I haven't heard the phrase, "free software misses the point", before, and a quick web search turns up too many links to stallman's "why open source misses the point" article. Could you elaborate a little or link somewhere that does?

Thank you!

I actually have to thank you, deeply and truly, because in trying to respond to you, it clarifies a bunch of things for me. I've re-written this comment three times. Thanks.

I made that phrase up. But I'm sympathetic to the essay, and I think maybe I was subconsciously referring to it.

Okay so, my issue with free software is similar to my issue with liberalism. I mean that in a philosophical, historical sense, not a "the Democrats" sense.

Liberalism (and much thought from the Enlightenment) is focused on freedom with regards to exchange. The Four Freedoms are focused on "I have this artifact, what can I do with it in relation to others." Marxism, which I am more sympathetic to, instead focuses on production over exchange. That is, the issue is not in individuals exchanging things, but how those things are produced in the first place. So in some sense, it's pre-occupied with the wrong thing.

Let's make this more concrete. You know the concept of "source dumps"? Let's say that I'm MegaEvil Inc. I can create some software, and once a year, release a new version. I also give you a copy of the source code, licensed under the GPL. There's no mailing list, no way to send patches, no governance. Just a copy of the source, once a year. This is 100% Free Software, but I'd argue that it misses the point. It's still better than being proprietary! But it doesn't let me, as the user, exercise any control over how the software is made. Yes, I could create a fork, but what happens when one year, there's an extensive internal re-write? At some point, a fork is a completely separate project, and we're back to step 1.

That is, the question I'm interested in is, who has the power to affect the development of the software? Free Software has nothing to say about this. But that's the real step forward. Being at the complete whim of upstream isn't that different from being at the whim of a proprietary vendor.

Given that I've literally just thought of this, this might be a bit rambly, a bit too deep, and a bit under-developed. But there you go. :)

I'd say its pretty well written, and the disclaimer on a public forum goes without saying.

I suppose I could sum it up as: "GPL doesn't include anything about the infrastructure of the software." The lack of an infrastructure for developers to hook into, could be GPL in literal word (or law), but not GPL in spirit (or morals). Likewise, and to add to your example, client-server architecture such as cloud computing might be GPL compatible in literal word, but not in spirit.

>I'm conflicted. I personally waver between "stallman is always right" and "free software misses the point" near constantly, myself.

Can I suggest a compromise with the belief that "Stallman is almost always right," because no human being with an extremist ideology is ever always right. A philosophy can be useful, even beneficial, but still be flawed.

I don't believe in the argument to moderation.

> A philosophy can be useful, even beneficial, but still be flawed.

I agree wholeheartedly.

Within this context, "Stallman is always right" applies to Stallman_with_FSF_hat_ie._FSF.org not Stallman_and_his_side_interests_on_Stallman.org.

Yes, thank you. I find many of Stallman’s personal views reprehensible, I’m purely talking about FSF stuff.

> Maybe, probably, I'm missing something here, but JavaScript and WebAssembly seem to be things that are not in the interest of users.

The Rust project does not have a goal to destroy every single piece of technology that could be construed as user hostile. The reality is that if you want to write a widely used browser application, you need to use Javascript, and probably soon, optionally WebAssembly. Rust is well positioned to take advantage of that.

(This is not an argument against the claim that Javascript/WebAssembly are user hostile. I have no real interest in discussing that, and frankly, there is no obvious conclusion to draw there. Instead, I'm pointing out a category error.)

> Why not integrate rust and the libraries into the existing packagement systems, like so many other software projects do?

This makes me curious: can you tell me some examples of other software projects which are not written in C that integrate libraries into existing package management systems?

Personally, I feel like `apt` could almost be called a C/C++ package manager at this point. It does have some packages written in other languages, but most languages still have their own package manager for development. For example:

* Python: has pip and virtualenv, packaging with apt is difficult due to incompatible version requirements * Ruby: not personally using ruby much, but seems like most apps are installed via bundler or gem and not packaged * Haskell: Small binary compatibility of libraries make traditional packages difficult (even dependencies of dependencies need to match for compatibility) * Java: I don't even know how java libraries would work with apt * PHP: I have never used a PHP package installed through the package manager

Granted, I may be missing something here, but the majority of the packages in apt repository seem to be C/C++, maybe some perl or python which are "made to work" simply because too many things depend on them.

Debian and Python seem to play nice with each other.

> As such, with hundreds of Python modules and multiple versions of Python supported, Debian is the largest "integrated Python distribution". (https://wiki.debian.org/Python)

Even if other languages don't play as nice as possible, or even foul, that doesn't mean it's not important for Rust to play nice.

Coming from a Ruby background, keeping your language versions independent from your OS package manager is really useful. There are situations where having different versions running alongside one-another is really handy, or not having to wait for your distro to include support for the version you require.

Agreed that it looks like re-inventing the wheel from the outside; rest assured, it's useful!