Well, given that this has been going on for years, you can already start to empirically evaluate that question.

> (So far, it's a not-very-complete client. But watch this space!)

Yes, it's a beginning not the end.

Or, you could look at other projects who have been using Rust for many years, and consider these factors there too. The folks who have have generally concluded the opposite.

Do you think the sibling comment was flagged to "protect me" whatever that means, or is it because "Are you high on Prozac?" is not really a productive comment?

EDIT: And now that I've scrolled down, I see you've left this comment many times as random replies. I'm sure those will get flagged, but for spam reasons, not due to some grand conspiracy.

The distribution I use already has limited security updates for Rust: https://www.debian.org/releases/trixie/release-notes/issues.... which reduces my security. The cargo supply chain issues are also very obvious, I am far more worried about this than I ever will be about memory safety, but hopefully tor reduces its reliance on random dependencies.

I find that surprising given that Debian breaks Rust programs up into individual apt packages, but ultimately, other distros do not have this issue. It’s also about userspace programs and not the kernel, which does not use external packages and so sidesteps this completely.

Debian forky has Rust in the kernel on by default.

I guess the want to be able to update individual libraries to provide security updates.

Right, from my understanding, Debian was packaging Rust programs in the same way as C ones. So they’d update the individual library and it should be all good. They deduplicated all of the dependencies in their trees.

This seems reasonable to me. If you have a tarmaggeedon, you update one library instead of thousand of packages. Although I am not sure how well this can work in Rust with monomorphization.