Live data from Hacker News

Rust’s dependencies are starting to worry me

vincents.dev

311–320 of 593 posts

Re: Rust’s dependencies are starting to worry me

#311
post #166

Earlier quoted context omitted.

I don't think so. Software is maybe the only "engineering" discipline where it is considered okay to use mainstream tools incorrectly and then blame the tools.

Do the “mainstream” tools change every five years in other disciplines?

To be fair they only change when chasing trends, consumers don't care how software is written, provided it does the job.

Which goes both ways, it can be a Gtk+ application written in C, or Electron junk, as long as it works, they will use it.

Re: Rust’s dependencies are starting to worry me

#312
post #244
post #130

Earlier quoted context omitted.

Kind of true, when not using vcpkg/conan.

Don’t forget cmake. (It makes adding dependencies easy, and everything else basically impossible)

Sure, despite all the hate it gets, except for IDE project files, it is the best experience in C and C++ build tools since forever, including IDE integration just like those project files.

I thought the whole UNIX mentality was worse is better.

No build tool is without issues, my pain points with cargo, are always compiling from source, build caching requires additional work to setup, as soon as it is more than pure Rust, we get a build.rs file that can get quite creative.

Re: Rust’s dependencies are starting to worry me

#313
post #71

I once wanted to contribute to the popular swc project ( https://github.com/swc-project/swc ). I cloned the repo, ran build, and a whooping 20GB was gone from my disk. The parser itself ( https://github.com/swc-project/swc/blob/main/crates/swc_ecma... ) has over a dozen dependencies, including serde. Meanwhile, the heaviest JavaScript parser implemented in JavaScript is more lightweight. I decided that I should leave…

I just built it with "git clone --depth 1 ..." and the build from cargo build --release is 2.9GB (2.3GB in the target folder)?

Rust generates absurd amounts of debug info, so the default debug builds are much much larger.

Zero-cost abstractions don't have zero-cost debug info. In fact, all of the optimized-away stuff is intentionally preserved with full fidelity in the debug info.

Re: Rust’s dependencies are starting to worry me

#314
post #242
post #125

Earlier quoted context omitted.

Not only it is possible, it has been available for decades on commercial AOT compilers like Aonix, Excelsior JET, PTC, Aicas. It is also done on the cousin Android, and available as free beer on GraalVM and OpenJ9.

Those all break compatibility to achieve that.

No they don't, PTC, Aicas, GraalVM and OpenJ9 support reflection.

The others no longer matter, out of business.

Re: Rust’s dependencies are starting to worry me

#315
post #208

Excuse me for not having much to add to the discussion but two interesting references for people to check out, if so inclined of course: a) Ginger Bill (the Odin language creator, no affiliation) stated on a podcast that Odin will never have an official pkg manager, since what they're, in his opinion, mainly automating is dependency hell, and this being one of the main reasons for rising software complexity and lower…

> a)... Odin will never have an official pkg manager

Perhaps this explains why Odin has found such widespread usage and popularity. /s

> b)... Jonathan Blow, who's talk "Preventing the Collapse of Civilization"

With such a grandiose title, before I first watched I thought it must be satire. Turns out, it is food for the credulous. I believe Jonathan Blow is less "seriously worried about software quality/complexity" than he is about marketing himself as the "last great hope". At least Blow's software has found success within its domain. However, I fear Blow's problem is the problem of all intellectuals: “An intellectual is a person knowledgeable in one field who speaks out only in others.” Blow has plenty of opinions about software outside his domain, but IMHO very little curiosity about why his domain may be different than your own.

My own opinion is there is little evidence to show this is a software quality problem, and any assertion that is the case needs to compare the Rust model against the putatively "better" alternatives. Complex software, which requires many people to create, sometimes across great distances of time and space, will necessarily have and require dependencies.

Can someone show me a material quality difference between ffmpeg, VLC, and Samba dependencies and any sufficiently complex Rust program (even which perhaps has many more dependencies)?

     ~ ldd `which ffmpeg` | wc -l
     231
Now, large software dependency graphs may very well be a security problem, but it is a problem widely shared with all other software.

Re: Rust’s dependencies are starting to worry me

#316
post #135

Earlier quoted context omitted.

True, hence we can go next level and also deal with limited accounts for developers, and I can tell you most folks on HN would hate to work in such corporate environments.

I'd leave. If I have to beg IT security every other day for something,it's just not worth it. I was in that situation once before and it was endlessly frustrating. It also wasn't even their choice, the CEO dictated it after attending some security talk once upon a time, and then instantly "you can't trust anyone or anything". You can trust my stay there will be short though :)

No doubt, although this is always a job market situation, in many places around the globe being a developer isn't much different from any other office job, where many folks have to be happy to have a job in first place.

Re: Rust’s dependencies are starting to worry me

#317
post #29

A 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…

Capslock sort of does this with go https://github.com/google/capslock

Interesting. I hadn't seen it yet. I'll check out how fine-grained it really is. My first concern would (naturally) be network calls, but calling a local service should ideally is distinguishable from calling some address that does not originate in the top level.

Re: Rust’s dependencies are starting to worry me

#318
> What's the solution?

Big things you use off-the-shelf libraries for. Small things you open-code, possibly by cribbing from suitably-licensed open source libraries. You bloat your code to some degree, but reduce your need to audit external code and reduce your exposure to supply chain attacks. Still, the big libraries are a problem, but you're not going to open code everything.

This isn't just Rust. It's everything.

Re: Rust’s dependencies are starting to worry me

#319

Earlier quoted context omitted.

Way back when, I used to vendor all the libraries for a project (Java/Cpp/Python) into a mono repo and integrate building everything into the projects build files so anyone could rebuild the entire app stack with whatever compiler flags they wanted. It worked great, but it took diligence, it also forces you to interact with your deps in ways that adding a line to a deps file does not.

This is the default way of doing things in the monorepo(s) at Google. It feels like torture until you see the benefits, and the opposite ... the tangled mess of multiple versions and giant transitive dependency chains... agony. I would prefer to work in shops that manage their dependencies this way. It's hard to find.

It's the same that we're doing for external crates in QEMU's experiments with Rust. Each new dependency is added to the build by hand.

Re: Rust’s dependencies are starting to worry me

#320

Earlier quoted context omitted.

Maven was the one the started the downfall into dependency hell. (Ant as well, but it was harder to blindly include things into it) Kids today don't know how to do that anymore...

Yet Maven repository is still not that bloated even after 20+ years Java et al. being one of the most popular language. Compared to Rust where my experience with protobuf lib some time ago was that there is a choice of not 1 but even 3 different libraries, one of which doesn't support services, another didn't support the syntax we had to support, and the third one was unmaintained. So out of 3 choices no single one w…

More time enables more consolidation.
Post reply on HN