True
Rust’s dependencies are starting to worry me
31–40 of 593 posts
Re: Rust’s dependencies are starting to worry me
#32In 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.
Re: Rust’s dependencies are starting to worry me
#33> dotenv is unmaintained. How much maintenance could you possibly need to load secrets from .env into the environment.
On the other hand loading .env from the environment is critical (since you are usually passing secrets through .env). I wouldn't want to maintain that myself and not share it with a xxK other projects in case there is a vulnerability.
Re: Rust’s dependencies are starting to worry me
#34> Many call for adding more to the rust standard library much like Go This is the way.
I think that the bare bones stdlib is a huge mistake in Rust. I would love to see that rectified. Unfortunately, approximately 5 other people share that view. The Rust community as a whole is very opposed to adding functionality to std.
Re: Rust’s dependencies are starting to worry me
#35A true enough statement, but "Rust" is unnecessarily specific. Dependencies are getting scary in general. Supply chain attacks are no longer hypothetical, they're here and have been for a while. If I were designing a new language I think I'd be very interested in putting some sort of capability system in so I can confine entire library trees safely, and libraries can volunteer somehow what capabilities they need/offe…
I've thought about this (albeit not for that long) and it seems like you'd need a non-trivial revamp of how we communicate with the operating system. For instance, allowing a library to "read from a stream" sounds safe until you realize they might be using the same syscalls as reading from a file!
Re: Rust’s dependencies are starting to worry me
#36> dotenv is unmaintained. How much maintenance could you possibly need to load secrets from .env into the environment.
The maintainers themselves give this warning in the repo's README, so even if it were maintained, it still wouldn't be production ready.
> Achtung! This is a v0.* version! Expect bugs and issues all around. Submitting pull requests and issues is highly encouraged!
Re: Rust’s dependencies are starting to worry me
#37> 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…
> We do not need to saddle Rust with garbage that will feel dated like Python's standard library.
Python's standard library is a strength, not a weakness. Rust should be so lucky. It's wonderful to have basic functionality which is guaranteed to be there no matter what. Many people work in environments where they can't just YOLO download packages from the Internet, so they have to make do with whatever is in the stdlib or what they can write themselves.
Re: Rust’s dependencies are starting to worry me
#38I'm quite careful to tightly control the dependencies of Tokio. All dependencies are under control by members of the Tokio team or others that I trust.
Re: Rust’s dependencies are starting to worry me
#39> when checking a rust security advisory mentioning that dotenv is unmaintained This is a problem with all languages and actually an area where Rust shines (due to editions). Your pulled in packages will compile as they previously did. This is not true for garbage collected languages (pun intended). > Out of curiosity I ran toeki a tool for counting lines of code, and found a staggering 3.6 million lines of rust ....…
> This is not true for garbage collected languages
JavaScript is backwards compatible going back effectively forever, as is Java. Rust's unique system is having a way to make breaking changes to the language without breaking old code, not that they prioritize supporting old code indefinitely.
The libraries are a different story—you're likely to have things break under you that rely on older versions of libraries when you update—but I don't see Rust actually having solved that.
> You can audit and most importantly modify the code. This is not that easy if you were using Nodejs where the runtimes are behind node/v8 or whatever.
Node and V8 are open source, which makes the code just as auditable and modifiable as the 3.6 million lines of Rust. Which is to say, both are equally unapproachable.
Re: Rust’s dependencies are starting to worry me
#40Earlier 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.
I agree. Unfortunately, I think that a lot of the people who ask for a bigger standard library really just want (a) someone else to do the work (b) someone they can trust.
The people working on Rust are a finite (probably overextended!) set of people and you can't just add more work to their plate. "Just" making the standard library bigger is probably a non-starter.
I think it'd be great if some group of people took up the very hard work to curate a set of crates that everyone would use and provide a nice façade to them, completely outside of the Rust team umbrella. Then people can start using this Katamari crate to prove out the usefulness of it.
However, many people wouldn't use it. I wouldn't because I simply don't care and am happy adding my dependencies one-by-one with minimal feature sets. Others wouldn't because it doesn't have the mystical blessing/seal-of-approval of the Rust team.