3 ms·
> 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:
by littlestymaar 3y ago
> 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.
- wongarsu 3y agoAnother viable strategy is to start a single-threaded tokio executor and treat it like another thread that you communicate with over (flume) channels.
- littlestymaar 3y agoYes 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.
- dymk 3y agoI 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...
- tuetuopay 3y agoYup. 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.
- LtWorf 3y agoHaving 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.
- mplanchard 3y agoYeah writing the underlying machinery is definitely much more complicated! Most users of async libraries don't need to worry about this though
- couchand 3y agoYou breeze over the dependency weight by abusing "zero cost" to mean "sunk cost". They're not the same!
- littlestymaar 3y agoThey 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.
- pm215 3y agoThis 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.
- pdw 3y agoFor reqwest, using the feature "blocking" will enable the reqwest::blocking API.
- theossuary 3y agoReqwest 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 https://docs.rs/reqwest/latest/reqwest/blocking/index.html
- deleted 3y ago[deleted]