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

521–530 of 593 posts

Re: Rust’s dependencies are starting to worry me

#521

Post by steveklabnik »

iainmerrick wrote: post #505
steveklabnik wrote: post #501

Earlier quoted context omitted.

Like many compiled languages, Rust does dead code elimination on everything.

Right, but it depends on how the code is written, right? If you use mostly free functions things will shake out naturally, if you use lots of dynamic dispatch you'll pull in stuff that doesn't get called.

Rust does static dispatch even for non-free functions. Only trait objects are dynamically dispatched, and most people argue they’re under-used in Rust, not overused.

If that does become a problem, there are also techniques like https://github.com/rust-lang/rust/issues/68262 too.

Re: Rust’s dependencies are starting to worry me

#522

Post by shwouchk »

simonask wrote: post #327
uecker wrote: post #253

Earlier quoted context omitted.

That does not help you if the bug is one of many unmaintained crates and never noticed. Linux distributions aim to make sure that C application dynamically link to the right libraries instead of vendoring the code. Then the library can be updated once. IMHO this is the only reasonable approach.

It's trivial to see on crates.io whether a crate is unmaintained.

is it trivial to see if a third level dependency is unmaintained?

Re: Rust’s dependencies are starting to worry me

#523

Post by galangalalgol »

Aurornis wrote: post #518
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…

> Eventually you end up in a world where your simple binary is 500 MiB of code you never actually call, It’s getting hard to take these conversations seriously with all of the hyperbole about things that don’t happen. Nobody is producing Rust binaries that hit 500MB or even 50MB from adding a couple simple dependencies. You’re also not ending up with mountains of code that never gets called in Rust. Even if my Rust b…

I agree on the bloat, considering my rust projects typically don't use any shared libraries other than a libc a few Mb for a binary including hundreds of crates in dependencies (most pf which are part of rustc or cargo itself), doesn't seem so bad. I do get the asynch thing. It just isn't the right tool for most of my needs. Unless you are in the situation where you need to wait faster (for connections usually) threads are better for trying to compute faster than asynch is.

Re: Rust’s dependencies are starting to worry me

#524

Post by xnickb »

jongjong wrote: post #168
zaptheimpaler wrote: post #111

This is just a modern problem in all software development, regardless of language. We are doing more complex things, we have a much bigger library of existing code to draw from and there are many reasons to use it. Ultimately a dependency is untrusted code, and there's a long road to go in hardening entire systems to make running arbitrary dependencies safe (if its even possible). In the absence of a technical soluti…

Yes, but a lot of the complexity is unnecessary bloat. Almost every project I've ever seen or worked on was full of unnecessary complexity. People naturally tend to over-complicate things, all the programming books, including software design books focus on unimportant aspects and miss all the important ones. It's incredibly frustrating. Yet, if someone were to write a book which explained things properly (probably a…

To quote one famous developer: "Talk is cheap. Show me code!"

Re: Rust’s dependencies are starting to worry me

#525

Post by kbolino »

thayne wrote: post #515
kbolino wrote: post #506

Earlier quoted context omitted.

Indeed, it has no bearing on binary size at all, because none of it will be included. If you are coming from the perspective where the standard library is entirely unusable to begin with, then improving the standard library is irrelevant at best. It also likely means that at least some time and effort will be taken away from improving the things that you can use to be spent on improving a bunch of things that you can…

> Indeed, it has no bearing on binary size at all, because none of it will be included. That depends on the language. In an interpreted language (including JIT), or a language that depends on a dynamically linked runtime (ex c and c++), it isn't directly included in your app because it is part of the runtime. But you need the runtime installed, and if your app is the only thing that uses that runtime, then the runtim…

Embedded Rust usually means no_std Rust, in which case no, neither the standard library nor any runtime to support it get included in the resulting binary. This isn't getting externalized either; no_std code simply cannot use any of the features that std provides. It is roughly equivalent to freestanding C.

What you say is true enough for external-runtime languages and Go, though TinyGo is available for resource-constrained environments.

Re: Rust’s dependencies are starting to worry me

#526

Post by vacuity »

yubblegum wrote: post #520

So asking HN: whatever happened with OSGi? Does that architecture solve the problem, and if no, why not? https://docs.osgi.org/specification/osgi.core/7.0.0/framewor... "How OSGi Changed My Life" (2008) https://queue.acm.org/detail.cfm?id=1348594

This is my first encounter with OSGi. It seems to me that the "Lego hypothesis" reflects an increasing justified approach. The ACM Queue article mentions hot plugging and dependency injection, and a comment[0] in this thread brings up Sans IO. This also ties into capabilities, as a security measure but also an approach to modularity. The common thread is that programs should be written with a strong sense of boundaries: both what is included and what is not included is vital, and the boundary must allow the inside to communicate with the outside. Push dependencies to the boundary and create interfaces from them. The general principles for trivially pluggable components are all out there now. More efforts like OSGi will be needed to principles into practice.

[0] https://news.ycombinator.com/item?id=43944511

Re: Rust’s dependencies are starting to worry me

#527

Post by pixl97 »

MeetingsBrowser wrote: post #203
pixl97 wrote: post #123

Earlier quoted context omitted.

Number of dependencies isn't exactly arbitrary... If you have one huge dep it's easier to keep track you're on the latest update, also it's much less likely you'll fat finger it and import something typosquatting. Also if you're in enterprise you'll have less 100 page SBOM reports.

What is more likely to be vulnerable, a 100k LoC project developed by ten people, or ten 10k LoC single maintainer projects. Keeping track of the latest version is trivial with cargo.

I work in SCA/SBOM.

>What is more likely to be vulnerable,

At the end of the day you are at much higher risks of one of those 10 packages getting owned by some external party and suddenly the next version is pulling a bitcoin miner, or something that steals everything it can from your CI/CD, or does a take over on your customers.

And it's never 10 (well at least for JS), it's hundreds, or if you're team is insane, thousands.

Re: Rust’s dependencies are starting to worry me

#528

Post by shwouchk »

dsr_ wrote: post #499
sunrunner wrote: post #89

Earlier quoted context omitted.

I agree that some amount of friction when including third party dependencies is a vital thing to push people to consider the value versus cost of dependencies (and license review, code review, channel subscriptions are all incredibily important and almost always overlooked), however how should this work for transitive dependendencies? And the dependencies of _those_ dependencies? The dependency trees for most interpr…

You understand the problem clearly, but you haven't put your finger on the solution. It's an obvious one, but distasteful to many people.

Perhaps the distaste is blinding me.

Would you care to state the obvious very clearly, for the dense ones among us?

Re: Rust’s dependencies are starting to worry me

#529

Post by blub »

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…

What you’re describing regarding glob is not lack of taste, it’s an architectural “bug”.

Taste is what Steve Jobs was referring to when he said Microsoft had none. In software it’s defined by a humane, pleasant design that almost(?) anybody can appreciate.

Programming languages cannot be tasteful, because they require time and effort to learn and understand. Python has some degree elegance and Golang’s simplicity has a certain je ne sais quoi… but they’re not really fitting the definition.

Still, some technologies such as git, Linux or Rust stand out as particularly obscure even for the average developer, not just average human.

Re: Rust’s dependencies are starting to worry me

#530

Post by shwouchk »

MeetingsBrowser wrote: post #203
pixl97 wrote: post #123

Earlier quoted context omitted.

Number of dependencies isn't exactly arbitrary... If you have one huge dep it's easier to keep track you're on the latest update, also it's much less likely you'll fat finger it and import something typosquatting. Also if you're in enterprise you'll have less 100 page SBOM reports.

What is more likely to be vulnerable, a 100k LoC project developed by ten people, or ten 10k LoC single maintainer projects. Keeping track of the latest version is trivial with cargo.

Unlike my sibling commment, i don’t work in SBOM, but if you consider social dynamics and what trust means, it should be pretty obvious that trusting in a group of 10 strangers is much less risky than trusting in 10 separate strangers.

consider the probabilities

Post reply on HN