Hacker News Reader

Comment by littlestymaar | Hacker News Reader

> However, if a library uses async, you have little choice but to make your whole project async. This adds to its horrible reputation.

No.

This is how yo do: you look what executor your dependency is using (most likely tokio) you add it to your cargo.toml (at zero cost, since it's already there in your dep) and then you wrap the async library calls in `block_on` and call it a day. You don't need to change a single other line in your project.

View on HN

You breeze over the dependency weight by abusing "zero cost" to mean "sunk cost". They're not the same!

They are. If you're using a dependency you're using your dependency dependencies, there's no way around it.

If it matters to you, you don't have the same priority as your dependency's author anyway and probably shouldn't be using it in the first place, and it has nothing to do with async.

This was not my experience. I had a working program that used the reqwest crate for a very basic synchronous-is-fine "just give me the contents of this web page" function. When I tried upgrading it to a newer reqwest that had decided async was the way to go, I found that that nice easy to use synchronous function had simply disappeared entirely, and I seemed to have to figure out async in order to use the library now. Luckily it was only a toy project so I just left it at the older version of the library. But as my first exposure to "async" as a rust feature it was a pretty off-putting one.

For reqwest, using the feature "blocking" will enable the reqwest::blocking API.

Reqwest still has a block client available [1]. I assume you upgraded across a major version, and are mad that there were backwards breaking changes? Don't do that if you don't want to update your code to account for changes in the dependency.

[1]: https://docs.rs/reqwest/latest/reqwest/blocking/index.html

Another viable strategy is to start a single-threaded tokio executor and treat it like another thread that you communicate with over (flume) channels.

Yes this works too. People complaining about async being contaminant are often so much prejudiced against it that that haven't even tried to understand the basics.

I have plenty of gripes about async in rust, but one of the things it's surprisingly good at is isolation of async runtimes. There's no reason you can't have multiple tokio runtimes, or transient runtimes, in your application.

Now if only the other warts were fixed, like the particularly poor compiler errors when there's an issue within an async function...

Yup. I was blown away when I spun up five different tokio runtimes in the same app all communicating through channels. I expected at least the tokio-aware channels to be problematic but not in the slightest. It's now humming in prod doing its business. Once you get the basics, it's quite easy to lego stuff out and get the best of both worlds.

Having written an async library (as in, the non-blocking stuff and state, that to the caller looks like async)... Understanding it isn't the easiest.

Yeah writing the underlying machinery is definitely much more complicated! Most users of async libraries don't need to worry about this though

Reply on news.ycombinator.com