5 ms·

I'm sure this library does the thing it claims to do very nicely. However, as a programmer I am saddened that so many things that should have been in the standa

I'm sure this library does the thing it claims to do very nicely. However, as a programmer I am saddened that so many things that should have been in the standard library by now need to come from external repositories and have a weird and unintuitive names.

willothy 2y ago
Hey, I think the name is cool! Fair point though, there would definitely be some benefit to having some of these things in the stdlib.
bryanlarsen 2y ago
tokio itself is not mature/stable enough to be in the standard library, IMO, let alone anything based on tokio.
- rsanders 2y ago
  I'm pretty new to Rust so forgive me if I'm mistaken, but it seems to me that this crate doesn't require the use of tokio.
  - lesuorac 2y ago
    When all the examples are marked with `#[tokio::main]`, it probably requires tokio. Although I guess they do implement Future on their own so it shouldn't need a specific runtime then. https://github.com/fortress-build/whirlwind/blob/main/src/shard/futures.rs https://github.com/fortress-build/whirlwind/blob/main/src/sh...
    - blurbleblurble 2y ago
      They're just using tokio as a dev dependency. You could use this with any async runtime https://github.com/fortress-build/whirlwind/blob/main/Cargo.toml#L14 https://github.com/fortress-build/whirlwind/blob/main/Cargo....
    - willothy 2y ago
      Tokio is just used for async tests and the examples, the crate doesn’t depend on any specific async runtime :)
ghotli 2y ago
I try to tell all new programmers that ask me for advice that keeping abreast of the words of tools that are available for use is a big part of the work and shouldn't be left out. If I quit my daily / weekly trawl of what's out there, I'd surely start to atrophy.
lesuorac 2y ago
I kind of like the "thin" stdlib approach tbh. Rather than having 3-5 ways to do a say a GUI from the stdlib you have 0 and instead you can pick a dependency that suits your way. That then boils down to even data structures, there's a bunch of trade-offs to be made where one is better than the other and if Rust had to maintain 30 different types of maps for each use case that seems like a waste of their time. Push that work off to the people that need those maps.
- willothy 2y ago
  I agree with this take a lot. I think having lots of custom implementations is inevitable for systems languages - the only reason why Rust is different is because Cargo/crates.io makes things available for everyone, where in C/C++ land you will often just DIY everything to avoid managing a bunch of dependencies by hand or with cmake/similar.
- seanw444 2y ago
  I'm torn. I don't write Rust much at all, but I have been playing around with it a little here and there for the last couple years. When I first tried it out, I was shocked that almost nothing I was looking for could be found in the stdlib. I thought I was looking in the wrong place. Coming mostly from the Go world, it was jarring to me when it turned out that out no, it really just barely has a stdlib. Now after on some pondering though, there is a strength in that the Rust team doesn't have to focus on maintaining such a large stdlib, as you said. I find myself using external libraries for many things in Go already, so why not just extend that to slightly more fundamental things with lots of variance too. I think the largest downside with this approach, however, is that it's hard for me to know what the de facto, collectively-agreed-upon standard is for a given task.
schainks 2y ago
The teams who compile the standard libraries are still made up of people, and sometimes better libraries get written outside of those teams. It's just a natural consequence of the intense collaboration we have in this industry. In fact, I am GLAD things happen this way, because it shows how flexible and open minded folks are when it comes to such libraries. Naming things is... well, you know...

willothy 2y ago

Hey, I think the name is cool! Fair point though, there would definitely be some benefit to having some of these things in the stdlib.

bryanlarsen 2y ago

tokio itself is not mature/stable enough to be in the standard library, IMO, let alone anything based on tokio.

rsanders 2y ago
I'm pretty new to Rust so forgive me if I'm mistaken, but it seems to me that this crate doesn't require the use of tokio.
- lesuorac 2y ago
  When all the examples are marked with `#[tokio::main]`, it probably requires tokio. Although I guess they do implement Future on their own so it shouldn't need a specific runtime then. https://github.com/fortress-build/whirlwind/blob/main/src/shard/futures.rs https://github.com/fortress-build/whirlwind/blob/main/src/sh...
  - blurbleblurble 2y ago
    They're just using tokio as a dev dependency. You could use this with any async runtime https://github.com/fortress-build/whirlwind/blob/main/Cargo.toml#L14 https://github.com/fortress-build/whirlwind/blob/main/Cargo....
  - willothy 2y ago
    Tokio is just used for async tests and the examples, the crate doesn’t depend on any specific async runtime :)

ghotli 2y ago

I try to tell all new programmers that ask me for advice that keeping abreast of the words of tools that are available for use is a big part of the work and shouldn't be left out. If I quit my daily / weekly trawl of what's out there, I'd surely start to atrophy.

lesuorac 2y ago

I kind of like the "thin" stdlib approach tbh. Rather than having 3-5 ways to do a say a GUI from the stdlib you have 0 and instead you can pick a dependency that suits your way. That then boils down to even data structures, there's a bunch of trade-offs to be made where one is better than the other and if Rust had to maintain 30 different types of maps for each use case that seems like a waste of their time. Push that work off to the people that need those maps.

willothy 2y ago
I agree with this take a lot. I think having lots of custom implementations is inevitable for systems languages - the only reason why Rust is different is because Cargo/crates.io makes things available for everyone, where in C/C++ land you will often just DIY everything to avoid managing a bunch of dependencies by hand or with cmake/similar.
seanw444 2y ago
I'm torn. I don't write Rust much at all, but I have been playing around with it a little here and there for the last couple years. When I first tried it out, I was shocked that almost nothing I was looking for could be found in the stdlib. I thought I was looking in the wrong place. Coming mostly from the Go world, it was jarring to me when it turned out that out no, it really just barely has a stdlib. Now after on some pondering though, there is a strength in that the Rust team doesn't have to focus on maintaining such a large stdlib, as you said. I find myself using external libraries for many things in Go already, so why not just extend that to slightly more fundamental things with lots of variance too. I think the largest downside with this approach, however, is that it's hard for me to know what the de facto, collectively-agreed-upon standard is for a given task.

schainks 2y ago

The teams who compile the standard libraries are still made up of people, and sometimes better libraries get written outside of those teams. It's just a natural consequence of the intense collaboration we have in this industry. In fact, I am GLAD things happen this way, because it shows how flexible and open minded folks are when it comes to such libraries. Naming things is... well, you know...