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

241–250 of 593 posts

Re: Rust’s dependencies are starting to worry me

#241

Post by EasyMark »

rs186 wrote: 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)?

Re: Rust’s dependencies are starting to worry me

#242

Post by hedora »

pjmlp wrote: post #125
samus wrote: post #98

Earlier quoted context omitted.

It's certainly better than in Java where LTO is simply not possible due to reflection. The more interesting question is which code effectively gets compiled so you know what has to be audited. That is, without disassembling the binary. Maybe debug information can help?

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.

Re: Rust’s dependencies are starting to worry me

#243

Post by hedora »

andrepd wrote: post #216
kion wrote: post #85

IMO any system where taking a dependency is "easy" and there is no penalty for size or cost is going to eventually lead to a dependency problem. That's essentially where we are today both in language repositories for OSS languages and private monorepos. This is partly due to how we've distributed software over the last 40 years. In the 80s the idea of a library of functionality was something you paid for, and painsta…

Dead code elimination means binary size bloat does not follow from dependency bloat. So this point is pretty much invalid for a compiled language like Rust.

Dead code elimination is exactly the same as the halting problem. It’s approximate (and hopefully conservative!) at best.

Re: Rust’s dependencies are starting to worry me

#244

Post by hedora »

pjmlp wrote: post #130
harha_ wrote: post #121

Earlier quoted context omitted.

Regardless of language, really? I highly doubt that, you don't generally see such problems with C or even C++ because dependencies are more cumbersome to add, especially in a way that's cross-platform.

Kind of true, when not using vcpkg/conan.

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

Re: Rust’s dependencies are starting to worry me

#245

Post by hedora »

socalgal2 wrote: post #214

I'm curious if rust has this problem. The problem I notice in npm land is many developers have no taste. Example, there's a library for globbing call glob. You'd think it would just be a function that does globbing but no, the author decided it should ALSO be a standalone commandline executable and so includes a large commandline option parser. They could have easily made a separate commandline tool that include a li…

Historically, the borrow checker has been a good shield against developers that have no taste.

Not sure how long that’ll last.

Re: Rust’s dependencies are starting to worry me

#246

Post by mysterymath »

zozbot234 wrote: post #141
kion wrote: post #85

IMO any system where taking a dependency is "easy" and there is no penalty for size or cost is going to eventually lead to a dependency problem. That's essentially where we are today both in language repositories for OSS languages and private monorepos. This is partly due to how we've distributed software over the last 40 years. In the 80s the idea of a library of functionality was something you paid for, and painsta…

> In the 80s the idea of a library of functionality was something you paid for, and painstakingly included parts of into your size constrained environment (fit it on a floppy). You probably picked apart that library and pulled the bits you needed, integrating them into your builds to be as small as possible. If anything, the 1980s is when the idea of fully reusable, separately-developed software components first beca…

You're talking about different 80s. On workstations and Unix mainframes, beasts like Smalltalk and Objective C roamed the Earth. On home computers, a resident relocatable driver that wasn't part of ROM was an unusual novelty.

Re: Rust’s dependencies are starting to worry me

#248

Post by Charon77 »

One of the good thing in cargo packages are the feature flags. If a repo uses too much dependencies then it's time to open an issue or PR to hide them behind feature flags. I do that a lot with packages that requires std even though it could do with core and alloc.

cargo tree helps a lot on viewing dependency tree. I forgot if it does LoC count or not..

> to see what lines ACTUALLY get compiled into the final binary,

This doesn't really make much sense as a lot of the functions that make it to the binary get inlined so much that it often becomes part of 'main' function

Re: Rust’s dependencies are starting to worry me

#249

Post by ardit33 »

sitkack wrote: post #224
kion wrote: post #85

IMO any system where taking a dependency is "easy" and there is no penalty for size or cost is going to eventually lead to a dependency problem. That's essentially where we are today both in language repositories for OSS languages and private monorepos. This is partly due to how we've distributed software over the last 40 years. In the 80s the idea of a library of functionality was something you paid for, and painsta…

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.

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...

Re: Rust’s dependencies are starting to worry me

#250

Post by the__alchemist »

Orangeair wrote: post #81

I think that https://blessed.rs does a pretty good job of providing recommendations for things that probably can't be crammed into the standard library, but which you'll almost certainly end up needing at one point or another. I honestly like that system a lot, it makes it so that the only packages you need to worry much about are usually doing something rather specific.

Did a review; this is solid!
Post reply on HN