top | item 43284964

(no title)

bfLives | 1 year ago

Looks really interesting. I like the approach of writing pure functions that return descriptions of IO tasks to perform. A couple of questions:

1. Why async?

2. Why couple to anyhow instead of using an associated error type?

discuss

order

cmrdporcupine|1 year ago

+1 for #1. In general, I would recommend providing non-async alternative APIs, with the async runtime as an option rather than assumed default. Not all of us drink the kool-aid there. And no, I don't mean just providing a "sync" API that uses "block_on" behind the scenes but still uses tokio...

Also, for async don't mandate tokio, use the "agnostic" crate to abstract it so people can use alternative runtimes.

And yes, don't use anyhow in a library like this. Anyhow is for your internal code, not public libraries/crates. Define a set of error enums, or use thiserror for it if you have to.

cat-whisperer|1 year ago

Yup, I am planning to use thiserror and error-stack for this in the future updates. But, anyhow provides an insanely easy interface for the person using this library, and keeps their mind off the error handling and rather in managing the domain stuff.

dhon_|1 year ago

Could you elaborate on why using block_on wouldn't be an acceptable solution for users that want a blocking API?