Hacker News Reader

Comment by killercup | Hacker News Reader

Because this code block looks quite complex, I want to add that it can also be just

    smol::block_on(async {
        println!("I'm async!");
    });

(I thought tokio had a helper like this too but could only find `tokio::runtime::Runtime::new().unwrap().block_on(async { println!("I'm async!"); });`.)

View on HN

Needing a helper library for something as simple as async so you don't go mental is really not good enough. I see the same thing with error handling - every Rust project I see imports a helper because it's too clunky otherwise.

If you don't want to pull in a helper library to run async code in a sync context, then why pull in an async library at all?

Rust is not a batteries-included language like Python. There are lots of libraries that are very commonly used in most projects (serde, thiserror, and itertools are in almost all of mine), but this is a conscious choice. They say in Python that the stdlib is where projects go to die. I'd rather have the flexiblity of choosing my dependencies, even for stuff I have to use in every project.

The problem is that a large number of popular libraries has converted to async, 95+% of them to Tokio.

So you are stuck with smaller, less battle tested products if you'd rather not pull in 100+ crates of dependencies that are doing nothing but inflating the build times and file sizes (for your particular usecase).

Example: reqwest vs ureq

OK, but like, can we just be honest then that the problem here is that your build times go up? People act like it's an insurmountable problem rather than just a trivial trade-off where, yes, your build times will go up because of some extra dependencies on an async runtime.

Increased build times are not great but holy shit the way people talk you'd never know that that's the actual trade-off here, an extra 3 seconds on a clean build.

Adding dependencies is not easy in some organizations. You have to trust them, in addition to waiting 3 seconds to compile them.

OK, in some niche scenarios I can see the cost being larger, but I think this is totally overstated.

Then use the code I posted if you don't want a helper library. Or just wrap it in your own function if it's too complex for your tastes.

Usually you're reaching for block_on because a library you want to use is async. Almost certainly the library you're using will have already be depending on an async library, so by pulling it in yourself you're not adding additional dependencies.

Reply on news.ycombinator.com