Live data from Hacker News

Rust’s dependencies are starting to worry me

vincents.dev

41–50 of 593 posts

Re: Rust’s dependencies are starting to worry me

#41
We need a term like “Mature” or similar for dependencies that are done. Mature dependencies have two characteristics:

1. Well defined scope

2. Infrequent changes

Nomad has many of these (msgpack, envparse, cli, etc). These dependencies go years without changing so the dependency management burden rapidly approaches zero. This is an especially useful property for “leaf” dependencies with no dependencies of their own.

I wish libraries could advertise their intent to be Mature. I’d choose a Mature protobuf library over one that constantly tweaked its ergonomics and performance. Continual iterative improvement is often a boon, but sometimes it’s not worth the cost.

Re: Rust’s dependencies are starting to worry me

#42
post #12
post #5

> Many call for adding more to the rust standard library much like Go This is the way.

No way. I'd much prefer we have a constellation of core companion libraries like Google's Guava. We do not need to saddle Rust with garbage that will feel dated like Python's standard library. Cargo does the job just fine. We just need some high quality optional batteries. Embedded projects are unlikely to need standard library bloat. No_std should be top of mind for everyone. Something that might make additional lib…

I don't think an additional standard library layer, whatever you call it, has to have the same tight controls on backwards compatibility and evolution that the actual standard library has. IMO the goal of creating it should be to improve supply chain security, not to provide an extremely stable API, which might be more of a priority at lower levels but chokes off the kind of evolution that will be needed.

I think what you're suggesting is a great idea for a new standard library layer, you're just not using that label. A set of packages in a Rust namespace, maintained by the same community of folks but under policies that comply with best practices for security and some additional support to meet those best practices. The crates shouldn't be required, so no_std should work just as it would prior to such a collection.

Re: Rust’s dependencies are starting to worry me

#43
I feel like leftpad has given package managers a very bad name. I understand the OP's hesitation, but it feels a little ridiculous to me.

tokio is a work-stealing, asynchronous runtime. This is a feature that would be an entire language. Does OP consider it reasonable to audit the entire Go language? or the V8 engine for Node? v8 is ~10x more lines than tokio.

If Cloudflare uses Node, would you expect Cloudflare to audit v8 quarterly?

Re: Rust’s dependencies are starting to worry me

#44
post #32
post #19

In the past (not in Rust, but other languages), for important systems, I've instituted policies of minimizing dependencies from these language-specific package repositories, and for the ones you do use, having to copy it to our own repos and audit each update before use. But that's not practical for all situations. For example, Web frontend developer culture might be the worst environment, to the point you often can'…

Best way is to have CI/CD systems only connected to the official internal repos. Devs can add whatever they feel like on their workstations but it will be a sad build server if they get pushed without permission.

s/Best way/The only safe way/

Anything else will get abused in the name of expediency and just-this-one-time.

Also, the process for adding a crate/gem/module/library needs to be the same as anything else: license review, code review, subscription to the appropriate mailing list or other announce channel, and assignment of responsibility. All of these except code review can be really, really fast once you have the process going.

All problems are, at least in part, dependency chain management problems.

Re: Rust’s dependencies are starting to worry me

#45
post #3

Similar feeling here. Cargo makes it so simple to add tons of dependencies that it is really hard not to do it. But that does not stop here: even if I try to be careful with adding dependencies, a couple dependencies are likely to pull tens of transitive dependencies each. "Then don't depend on them", you say. Sure, but that means I won't write my project, because I won't write those things from scratch. I could prob…

I have been wasting 6 hours yesterday on getting the bullet examples to compile outside of bullet itself with no success. It's more likely that a lot of software simply doesn't get written because C++ and CMake are a pain in the ass.

Re: Rust’s dependencies are starting to worry me

#47
Everyone is in such a rush to get their project out the door, no one has time to generate a key and properly code sign releases and begin developing a more secure chain. Now we have JS package "whatever code" ecosystem but for Rust. As if we haven't watched NPM get hacked many times over the last decade or so.

Re: Rust’s dependencies are starting to worry me

#48
post #15
post #7

Earlier quoted context omitted.

Yeah, I agree. Something like the Boost lib for C++

A strong advantage of that approach is that you don't need to be the core Rust team to do it. Anyone who wants to do this can just start doing it now.

This is only an advantage if the core Rust team is uncooperative, which is sad rather than something to be happy about.

Re: Rust’s dependencies are starting to worry me

#49

Everyone is in such a rush to get their project out the door, no one has time to generate a key and properly code sign releases and begin developing a more secure chain. Now we have JS package "whatever code" ecosystem but for Rust. As if we haven't watched NPM get hacked many times over the last decade or so.

> Everyone is in such a rush to get their project out the door

This is the cause of so many issues.

And its not like we're at war or trying to cure the next pandemic, we're writing CRUD apps and trying to convince people to click on adds for crap they don't need.

Re: Rust’s dependencies are starting to worry me

#50
post #6
post #5

> Many call for adding more to the rust standard library much like Go This is the way.

There should be a second stdlib with relaxed stability guarantees. Don't fill the normal stdlib full of cruft that can never be changed again.

The non-standard library, if you will.
Post reply on HN