4 ms·

Coming from C++ and Python, Go's packaging + deployment tooling really enlightened me. It's SO EASY to depend on things and deploy my apps, I love it! I've als

by bbkane 2y ago

Coming from C++ and Python, Go's packaging + deployment tooling really enlightened me. It's SO EASY to depend on things and deploy my apps, I love it! I've also heard Rust gives folks similar warm fuzzy feelings in regards to building and deploying, one day I'll try that too

nox101 2y ago
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 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
- nicce 2y ago
  > 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.
  - nox101 2y ago
    That's the same argument node people make. See how well it's worked out.
    - pxc 2y ago
      NPM's got bigger problems than just having lots of small libraries, like for instance allowing circular dependency relations in packages
  - kergonath 2y ago
    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.
    - nicce 2y ago
      Rust, the language itself depends on 220 packages: https://github.com/rust-lang/rust/blob/e8753914580fb42554a79a4b5c5fb4cc98933231/src/tools/tidy/src/deps.rs#L191 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.
      - hu3 2y ago
        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.
        nicce 2y ago
        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 https://github.com/rust-lang/rust/tree/master/src/librustdoc
- deleted 2y ago
  [deleted]
- steveklabnik 2y ago
  > 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.

by bbkane 2y ago

nox101 2y ago

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

nicce 2y ago
> 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.
- nox101 2y ago
  That's the same argument node people make. See how well it's worked out.
  - pxc 2y ago
    NPM's got bigger problems than just having lots of small libraries, like for instance allowing circular dependency relations in packages
- kergonath 2y ago
  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.
  - nicce 2y ago
    Rust, the language itself depends on 220 packages: https://github.com/rust-lang/rust/blob/e8753914580fb42554a79a4b5c5fb4cc98933231/src/tools/tidy/src/deps.rs#L191 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.
    - hu3 2y ago
      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.
      - nicce 2y ago
        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 https://github.com/rust-lang/rust/tree/master/src/librustdoc
deleted 2y ago
[deleted]
steveklabnik 2y ago
> 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.