Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Rust’s dependencies are starting to worry me

vincents.dev

Post reply on HN
Print view View original

11–20 of 593 posts

Re: Rust’s dependencies are starting to worry me

#11

Post by jampekka »

palata wrote: 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 take bit less unstable dependencies over the total mess of C++ dependencies with CMake, shared libraries, version conflicts etc any time. There's probably also a bit of an illusion about C++ transitive dependencies due to them usually being precompiled (because compiling them is such pain).

Re: Rust’s dependencies are starting to worry me

#12

Post by echelon »

demarq wrote: 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 libraries feel more first class: if cargo finally got namespaces and if the Rust project took on "@rust/" as the org name to launch officially sanctioned and maintained packages.

Re: Rust’s dependencies are starting to worry me

#13

Post by iammrpayments »

klooney wrote: post #10

> dotenv is unmaintained. How much maintenance could you possibly need to load secrets from .env into the environment.

I find hilarious when people judge the quality of a repository by how many commits it has, as if 10.000 commits means the code is better.

Re: Rust’s dependencies are starting to worry me

#14

Post by XxiXx »

I think it's a "cultural" thing. With Go you often find developers/projects proudly mentioning that any or just a few non-std dependencies are used. Coming from Go it really feels strange when you see pages of dependencies scrolling over your screen when you build a Rust project.

Re: Rust’s dependencies are starting to worry me

#15

Post by jerf »

demarq wrote: post #7
dralley wrote: post #6

Earlier quoted context omitted.

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.

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.

Re: Rust’s dependencies are starting to worry me

#16

Post by wofo »

dralley wrote: post #6
demarq wrote: 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.

Actually, a proposal for exactly this was published yesterday: https://github.com/rust-lang/rfcs/pull/3810

It's unfortunate that the response so far hasn't been very positive

Re: Rust’s dependencies are starting to worry me

#17

Post by antonvs »

palata wrote: 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…

> Sure, but that means I won't write my project, because I won't write those things from scratch.

You need to think a bit harder about that, to help you decide whether your position is rational.

Re: Rust’s dependencies are starting to worry me

#19

Post by neilv »

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't get many things done in feasible time, if you don't adopt the same reckless practices.

I'm also seeing it now with the cargo-culting of opaque self-hosted AI tools and models. For learning and experimenting, I'd spend more time sufficiently compartmentalizing an individual tool than with using it.

This weekend, I'm dusting off my Rust skills, for a small open source employability project (so I can't invest in expensive dependency management on this one). The main thing thing bothering me isn't allocation management, but the sinking feeling when I watch the cast-of-thousands explosion of transitive dependencies for the UI and async libraries that I want to use. It's only a matter of time before one of those is compromised, if not already, and one is all it takes.

Re: Rust’s dependencies are starting to worry me

#20

Post by shepmaster »

klooney wrote: post #10

> dotenv is unmaintained. How much maintenance could you possibly need to load secrets from .env into the environment.

I agree with your general point, but for this specific functionality, I’ll point out that setting environment variables of the current process is unsafe. It took us a long time to realize it so the function wasn’t actually marked as unsafe until the Rust 2024 edition.

What this means in practice is that the call to invoke dotenv should also be marked as unsafe so that the invoker can ensure safety by placing it at the right place.

If no one is maintaining the crate, that won’t happen and someone might try to load environment variables at a bad time.

Post reply on HN