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

531–540 of 593 posts

Re: Rust’s dependencies are starting to worry me

#531

Post by blub »

tialaramex wrote: post #418
blub wrote: post #308

Earlier quoted context omitted.

If something is in the standard library, then it’s written and vetted by the standard library provider, not by a random third party like you make it sound. With Rust, it’s literally a random third party.

> it’s written and vetted by the standard library provider, not by a random third party All three modern C++ standard libraries are of course Free Software. They are respectively the GNU libstdc++, Clang's libc++ and the Microsoft STL. Because it's a huge sprawling library, you quickly leave the expertise of the paid maintainers and you're into code that some volunteer wrote for them and says it's good. Sounds like r…

One Stephan T. Lavavej is worth more than 1000 random github rustaceans, some of which will be bots, AIs, rank amateurs, bought or North Korean spies. Any of the libraries has one or more Stephans.

Having paid maintainers, code review, test suites, strict contribution guidelines, etc is state of the art for open source software that some transitive crate dependency can only dream to achieve.

Re: Rust’s dependencies are starting to worry me

#532

Post by blub »

simonask wrote: post #326
blub wrote: post #308

Earlier quoted context omitted.

If something is in the standard library, then it’s written and vetted by the standard library provider, not by a random third party like you make it sound. With Rust, it’s literally a random third party.

Maintainers of all open source standard libraries are effectively "random third parties". With heavily used ecosystem dependencies (such as Tokio, but also swaths of small libraries, such as `futures` or `regex`), the number of people who have looked at the code and battle-tested it is also huge. On crates.io, a good heuristic is to look at two numbers: the number of dependents and the number of downloads. If both ar…

People are paid to work on standard libraries and there’s a whole process behind developing and releasing this software.

Tokio on the other hand is the library whose maintainer decided to download a binary blob during build: https://github.com/tokio-rs/prost/issues/562 https://github.com/tokio-rs/prost/issues/575

Good luck catching such issues across dozens of crates.

Re: Rust’s dependencies are starting to worry me

#533

Post by throwitaway1123 »

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…

It's worth pointing out that Node has a built in globbing function: https://nodejs.org/docs/latest-v24.x/api/fs.html#fspromisesg...

> Also there's arguably design. Should a 'glob' library actually read the file system and give you filenames or should it just tell you if a string matches a glob and leave the reset to you?

There's a function in Node's stdlib that does this as well (albeit it's marked as experimental): https://nodejs.org/docs/latest-v24.x/api/path.html#pathmatch...

Re: Rust’s dependencies are starting to worry me

#534

Post by mustache_kimono »

bsrkf wrote: post #401
mustache_kimono wrote: post #315

Earlier quoted context omitted.

> 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" t…

"Perhaps this explains why Odin has found such widespread usage and popularity. /s" What an unnecessarily snark and dismissive comment to make about someone's work. - I'd say within a certain niche Odin is becoming well known and gets its use - you do realize using an `Odin package` is putting a program into a sub-folder and that's it - It comes with a rich stdlib + vendor libraries out of the box - and isn't it kind…

> What an unnecessarily snark and dismissive comment to make about someone's work.

The snark was intended, however any dismissiveness concerning Ginger Bill's effort was not. However, when you make a decision like "Odin will never have a package manager", you may be choosing to condemn your project to niche status, in this day and age. Now, niche status is fine, but it definitionally comes with a limited audience. Like "this game will only ever be a text based roguelike."

Re: Rust’s dependencies are starting to worry me

#535

Post by munificent »

dathinab wrote: post #190
munificent wrote: post #116

Earlier quoted context omitted.

> relies on V8 to run, which has multiple orders of magnitude more dependencies. Actually, this isn't true. (Or at least wasn't a while back.) I used to work with a bunch of ex-V8 folks and they really despised third-party dependencies and didn't trust any code they didn't write. They used a few third-party libs but for them most part, they tried to own everything themselves.

they are also Google .. as in they can afford to rewrite everything .. can afford to suffer from not invented here syndrome .. and are under _massive_ threat of people doing supply chain attacks compared to most other projects (as they end up running on nearly any desktop computer and half the phones out there) this just isn't viable for most projects, not just resource/time investment wise, but also reinventing/writ…

I think the folks who wrote V8 have always been this way, even before their company got acquired by Google and they switched to writing V8.

Re: Rust’s dependencies are starting to worry me

#536

Post by mike_hearn »

samus wrote: post #98
nicoburns wrote: post #90

Earlier quoted context omitted.

As far as I'm aware, LTO completely solves this from a binary size perspective. It will optimise out anything unused. You can still get hit from a build time perspective though.

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?

It's possible and in recent years the ecosystem has been evolving to support it much better via native-image metadata. Lots of libraries have metadata now that indicates what's accessed via reflection and the static DCE optimization keeps getting better. It can do things like propagate constants to detect more code as dead. Even large server frameworks like Micronaut or Spring Native support it now.

The other nice thing is that bytecode is easy to modify, so if you have a library that has some features you know you don't want, you can just knock it out and bank the savings.

Re: Rust’s dependencies are starting to worry me

#537

Post by pjmlp »

fiedzia wrote: post #435
WuxiFingerHold wrote: post #271

Earlier quoted context omitted.

> 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. Go and C# (.NET) are counterexamples. They both have great ecosystems and just as simple and effective package management as Rust or JS (Node). But neither Go or C# have issues with dependency hell like Rust or even more JavaScript, because they have exceptional std libs a…

> but neither Go or C# have issues with dependency hell like Rust or even more JavaScript, because they have exceptional std libs They also have a lot narrower scope of use, which means it is easier to create stdlib usable for most people. You can't do it with more generic language.

I would say C# gets used almost everything at Microsoft between GUIs, backends, DirectX tooling (new PIX UI, Managed DirectX and XNA back in Creative Arcade days), Azure,..., alongside C++, and even if Microsoft <3 Rust, in much bigger numbers.

Re: Rust’s dependencies are starting to worry me

#539

Post by Seattle3503 »

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

What if I pass in components from one library with permissions to another library that doesn't have those permissions?

Re: Rust’s dependencies are starting to worry me

#540

Post by dietr1ch »

taeric wrote: post #144
dietr1ch wrote: post #107

Earlier quoted context omitted.

I don't think libraries are the problem, but we don't have a lot of visibility after we add a new dependency. You either take the time to look into it, or just add it and then forget about the problem (which is kind of the point of having small libraries). It should be easy to build and deploy profiling-aware builds (PGO/BOLT) and to get good feedback around time/instructions spent per package, as well as a measure o…

I agree that I don't like thinking of libraries as the problem. But they do seem to be the easiest area to point at for a lot of modern development hell. Is kind of crazy. I'll note that it isn't just PGO/BOLT style optimizations. Largely, it is not that at all, oddly. Instead, the problem is one of stability. In a "foundation that doesn't move and cause you to fall over" sense of the word. Consider if people made a…

> I'll note that it isn't just PGO/BOLT style optimizations. Largely, it is not that at all, oddly.

Well, it's not required to trim code that you can prove unreachable, true. But I was thinking about trying to measure if a given library really pulls it's non-zero weight, and how much CPU is spent in it.

A library taking "too much time" for something you think can be done faster might need replacement, or swapping for a simple implementation (say the library cares about edge cases you don't face or can avoid).

Post reply on HN