Comment by ozgrakkurt

Comment by ozgrakkurt a day ago

You are skipping the massive point here.

If you are using a library in rust, it has to be async await, tokio, send+sync and all the other crap. Or if it is sync api then it is useless for async application.

This approach of passing IO removes this problem and this is THE main problem.

This way you don’t have to use procedural macros or other bs to implement multi versioning for the functions in your library, which doesn’t work well anyway in the end.

https://nullderef.com/blog/rust-async-sync/

You can find 50 other ones like this by searching.

To be honest I don’t hope they will solve cooperative scheduling, high performance, optionally thread-per-core async soon and the API won’t be that good anyway. But hope it solves all that in the future.

dwattttt a day ago

> Or if it is sync api then it is useless for async application.

The rest is true, but this part isn't really an issue. If you're in an async function you can call sync functions still. And if you're worried it'll block and you can afford that, I know tokio offers spawn_blocking for this purpose.

Reply View 0 replies

tcfhgj a day ago

> If you are using a library in rust, it has to be async await, tokio, send+sync and all the other crap

Send and sync is only required if you want to access something from multiple threads, which isn't required by async await (parallelism vs concurrency)

1) You can use async await without parallelism and 2) send and sync aren't a product of async/await in Rust, but generally memory safety, i.e. you need Send generally when something can/is allowed to move between threads.

Reply View 3 replies

m11a 21 hours ago

Yes, but async Rust is basically built on tokio's runtime, which is what most the big async libraries depend on, like hyper/axum/tokio etc. And tokio is a thread-per-core work-stealing architecture, which requires Send + Sync bounds everywhere. You can avoid them if you depend on tokio-proper, but it's more icky when building on something like axum, where your application handlers also require these bounds.
A good article on this: https://emschwartz.me/async-rust-can-be-a-pleasure-to-work-w...

Reply View | 1 reply
- tcfhgj 19 hours ago
  
  Iirc I had a situation a while back, in which I used async await with tokio with a non Send or Sync type and it compiled when I didn't use spawn[1] (implying multithreading) but a simple loop with sequential processing.
  Only when I wanted to enable parallelism using spawn, I got a compilation error.
  [1]: https://docs.rs/tokio/latest/tokio/task/fn.spawn.html
  
  Reply View | 0 replies
WhyNotHugo 17 hours ago

> Send and sync is only required if you want to access something from multiple threads, which isn't required by async await (parallelism vs concurrency)
In theory this is correct. In practice, a lot of APIs (including many in tokio) require both traits even for single-thread use cases.

Reply View | 0 replies

dminik a day ago

I'm not skipping anything. And in fact acknowledge this exact point:

> That being said, I don't think Zig's implementation here is bad. If anything, it does a great job at abstracting the usage from the implementation. This is something Rust fails at spectacularly.

Reply View 0 replies

junon 18 hours ago

This comment is justly flatly incorrect. You don't need Tokio at all to write an async library. Nor do you need send sync. Not sure what other crap you are speaking of, either.

Sync APIs can be spawned in worker threads as futures, too. Generally executors have helper methods for that.

Reply View 0 replies