4 ms·

Tangential, but does anybody else get real npm vibes from the rust ecosystem? Something about the “every productive project depends on this one external packag

Tangential, but does anybody else get real npm vibes from the rust ecosystem? Something about the “every productive project depends on this one external package” situation really makes me uneasy. And there are language features like async that can’t even really be used without going to crates.io for a bunch of stuff that really ought to be in the stdlib.

bryanlarsen 2y ago
withoutboats mentioned trying to get something like https://github.com/zesterer/pollster https://github.com/zesterer/pollster into the standard library. I think that's a great idea. They don't want to put an executor into the standard library because that would "pick a winner" before the ideas are settled. But pollster allows async crates to be useful to sync code, is obviously not a "winner" and its inclusion in the standard library would force crates to be properly executor-agnostic.
- zesterer 2y ago
  The problem with this is that pollster doesn't, by itself, provide a signalling mechanism by which bottom-level futures (such as OS-provided IO primitives) can signal the executor. It isn't a "light-weight replacement" for tokio, tokio does a lot of stuff that pollster simply can't because tokio is a reactor + a runtime, whereas pollster is just a runtime. [This page](https://rust-lang.github.io/async-book/08_ecosystem/00_chapter.html#determining-ecosystem-compatibility https://rust-lang.github.io/async-book/08_ecosystem/00_chapt...) gives some nice details about the difference, and hopefully some sense of the sheer difficult that comes with trying to integrate a default reactor into `std` without it falling well short when it comes to extensibility.
steveklabnik 2y ago
npm, being one of the most successful package management systems in history, was an express inspiration for Cargo, sure. It’s also not without flaw, and so Cargo and npm do differ in some key ways. Software engineers love to talk about how code re-use is good, and keeping code small and simple is good, and then somehow get upset when a lot of modular, small, reusable code is produced and widely shared.
- jpc0 2y ago
  > ... modular, small ... I think that's where the issue lies. It's either so small it would take 5 seconds to actually type or it is neither modular nor small... Very rarely is is one of those things never mind both of them at the same time.
- pjmlp 2y ago
  And sadly it shows, given the amount of crates some projects depend on, plus having to wait for the same crate to be re-compiled multiple times, due to how it is referenced across the whole dependency graph.

bryanlarsen 2y ago

withoutboats mentioned trying to get something like https://github.com/zesterer/pollster https://github.com/zesterer/pollster into the standard library. I think that's a great idea. They don't want to put an executor into the standard library because that would "pick a winner" before the ideas are settled. But pollster allows async crates to be useful to sync code, is obviously not a "winner" and its inclusion in the standard library would force crates to be properly executor-agnostic.

zesterer 2y ago
The problem with this is that pollster doesn't, by itself, provide a signalling mechanism by which bottom-level futures (such as OS-provided IO primitives) can signal the executor. It isn't a "light-weight replacement" for tokio, tokio does a lot of stuff that pollster simply can't because tokio is a reactor + a runtime, whereas pollster is just a runtime. [This page](https://rust-lang.github.io/async-book/08_ecosystem/00_chapter.html#determining-ecosystem-compatibility https://rust-lang.github.io/async-book/08_ecosystem/00_chapt...) gives some nice details about the difference, and hopefully some sense of the sheer difficult that comes with trying to integrate a default reactor into `std` without it falling well short when it comes to extensibility.

steveklabnik 2y ago

npm, being one of the most successful package management systems in history, was an express inspiration for Cargo, sure. It’s also not without flaw, and so Cargo and npm do differ in some key ways. Software engineers love to talk about how code re-use is good, and keeping code small and simple is good, and then somehow get upset when a lot of modular, small, reusable code is produced and widely shared.

jpc0 2y ago
> ... modular, small ... I think that's where the issue lies. It's either so small it would take 5 seconds to actually type or it is neither modular nor small... Very rarely is is one of those things never mind both of them at the same time.
pjmlp 2y ago
And sadly it shows, given the amount of crates some projects depend on, plus having to wait for the same crate to be re-compiled multiple times, due to how it is referenced across the whole dependency graph.