5 ms·

It's usually easier to write the async version first and then write a sync wrapper. See for example the `postgres` crate.

• Klonoar 4y ago
  Right, I get that. I'm saying that the sync version shouldn't be "run tokio blocking in the background", because while you might be giving them an out on async infection in theory, you're still making them bring in the entire dependency tree and you're still creating more background resources than is necessary.
  • jhugo 4y ago
    The `postgres` crate launches a "current thread" tokio runtime which doesn't really have much overhead in terms of background resources. I agree about dependencies though. "async infection" is kinda interesting when you think about it. To use `postgres` as an example, talking to a database is asynchronous whether you like it or not. To use blocking APIs to access it is just to allow something (typically the OS) to pretend that it isn't. In general I've found the experience of writing a program async from the beginning to be very good in Rust, and in the very rare cases (in my field of work) where I have some genuine blocking to do, Tokio provides good tools for that (`tokio::task::spawn_blocking` and `tokio::task::block_in_place`). I can imagine that if you were writing a largely CPU-bound program, async would feel more like an "infection".