Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

I felt that way about node and yet node lead to an explosion of poorly written and designed packages and constant notifications about needing to upgrade project X because it depended on Y which depends on Z and Z has some DoS issue if you pass the wrong regex to it.

I don't feel confident that rust won't go the same way when I tried to update the rust docs (https://github.com/rust-lang/docs.rs)

    cargo build
    Downloaded 541 crates (55.2 MB)
Seriously? 541 crates for a static site generator for docs?

rust is clearly off to copy npm in all of it's faults. I have no idea if go is similar in the explosion of dependencies and supply side attack surface area explosion



> for a static site generator for docs?

docs.rs has a lot more to do than just that. But also, actually building those static pages takes a lot. To do so, it has to actually build every crate, sandboxed, of course. This makes it closer to "universal CI for the entire ecosystem" than "generate a few html pages."

If you look at the dependencies, they're pretty normal for a website that does this kind of thing. It's roughly 80 dependencies, then 11 used for development only, and a couple more that are build-time only. The larger number is the sum of all transitive dependencies.


> Seriously? 541 crates for a static site generator for docs? rust is clearly off to copy npm in all of it's faults. I have no idea if go is similar in the explosion of dependencies and supply side attack surface area explosion

In Rust, it is design choice. They try to keep the standard library small, and let community create competitive packages. You see the result in those numbers.

It is hard judge based on those numbers only.


The philosophy does not really matter, though. Any one of these dependencies could be a vector for a supply chain attack and all these libraries being updated independently and a synchronously is just asking for 2 dependencies requiring incompatible version of something else. We’ve seen this happening already and it usually ends up in 2 ways:

- the node approach: who cares? YOLO!

- the particular circle of hell that is Python and its 25 ways of doing virtual environments. Wait, 26, yet another one just dropped.

For all its faults (and there are some), a centralised approach like with Boost has some merit.


Rust, the language itself depends on 220 packages: https://github.com/rust-lang/rust/blob/e8753914580fb42554a79...

If you trust nobody, it is hard to use anything.

But about your second note, (environment, mismatched dependencies), I would argue that Rust provides the best tooling to solve or identify issues on that area.


Rust depending on 220 packages is somewhat understandable.

After all it runs on many platforms. I counted 16 Windows packages just by glancing over and also many macOS related.

But 541 for docs?

Surely there's a gradient between trusting no one and trusting 541 packages to generate static files.


Are you confusing `docs.rs` with `cargo doc`?

It is indeed many packages, but if you look into the dependencies and code, docs is full blown standalone HTTP async server which uses tokio, AWS S3 and Postgresql. It is used to host the docs.rs where is the documentation of every cargo project.

Maybe they should feature-gate some functionality and also split the dependencies

Static site generator is mostly in the Rust itself: https://github.com/rust-lang/rust/tree/master/src/librustdoc


That's the same argument node people make. See how well it's worked out.


NPM's got bigger problems than just having lots of small libraries, like for instance allowing circular dependency relations in packages




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: