4 ms·

> are you referring to the code you read? Yes, the code the developer needs to read, write and understand. I'm not familiar of how async/await will be in Rust

by arve0 8y ago

> are you referring to the code you read? Yes, the code the developer needs to read, write and understand. I'm not familiar of how async/await will be in Rust, but I guess some code differences/complexities can be: 1. Make sure, manually(?), that all things are async / non-blocking. 2. Implementing Future.poll / wrapping types in Future? (What is Pin? ref https://rust-lang.github.io/async-book/execution/future.html https://rust-lang.github.io/async-book/execution/future.html) 3. Async polution, a function that uses async must be async too? 4. Setup some scheduler that maintain how many concurrent async operations one thread has? 5. More verbose error-messages / stack-traces?

hobofan 8y ago
> 3. Async polution, a function that uses async must be async too? Coming from JS, that's a non-problem in Rust. You can easily make a function blocking by creating a event loop and resolving the future you get from another function in it. So when I refactor my code to be async, I'm starting by making a single function async, and the moving the event loop from function to function, until as much of the code is async as I want.
- asdkhadsj 8y ago
  To add to that, not too long ago I was wishing Rust was more like Go on the Async front. Where the scheduler was more built into the language, and I didn't have to use "ugly" async/await stuff everywhere. In hindsight, I prefer async/await. My reason is primarily that like your example points out, it really lets me be in full control over the scheduled behavior. I could even take non-io work and make it "async". Ie, some long processing application takes a break every million iterations to let other tasks steal some work. That's just cool! Arguably a similar thing could be designed in Go if every million iterations you used some type of IO primitive, like sending some data over a channel, but the behavior of Rust's model is more fine grained.
asdkhadsj 8y ago
Disclaimer: My understanding of Futures is limited. > 1. Make sure, manually(?), that all things are async / non-blocking. You'd have to make sure any IO you do is using Futures - ie, use a package to provide async IO primitives for disk and network access. You would also need to use the appropriate await syntax call on any future using methods - that would require a bit of overhead to know, but at least the compiler has your back on that. > 2. Implementing Future.poll / wrapping types in Future? In most cases I don't think you'd have a use case to implement a Future - would you? Ie, main IO calls are the big ones for wasting threads - and libraries like mio/hyper/etc provide your IO primitives. > 3. Async polution, a function that uses async must be async too? Yea, my understanding is that this is definitely an issue. I am already planning on using `async` tags on basically all my functions, because everything I use bound to IO in one form or another. On the bright side, I believe (don't quote me!) that you can drop ugly `fn foo() -> Futures<Item=Result<A,B>>` wrapping, since I believe `async fn foo() -> Result<A,B>` does the same thing. .. again, the syntax is not finalized haha. > 4. Setup some scheduler that maintain how many concurrent async operations one thread has? If you're using Async I'd imagine you'd already have chosen a scheduler. I believe Tokio will be the defacto - though Rayon might be involved here, not sure. > 5. More verbose error-messages / stack-traces? Errors themselves would be unaffected, if you're talking normal error values - remember those are just values in Rust, like Go, so not much special there. Though as you said, I imagine if you dump a trace it would look different, no idea. None of this post was meant to counter you in anyway. I just hoped to provide a bit of clarity on the tiny things I can contribute to. I hope I helped more than hurt. Have a nice day :)

by arve0 8y ago

hobofan 8y ago

> 3. Async polution, a function that uses async must be async too? Coming from JS, that's a non-problem in Rust. You can easily make a function blocking by creating a event loop and resolving the future you get from another function in it. So when I refactor my code to be async, I'm starting by making a single function async, and the moving the event loop from function to function, until as much of the code is async as I want.

asdkhadsj 8y ago
To add to that, not too long ago I was wishing Rust was more like Go on the Async front. Where the scheduler was more built into the language, and I didn't have to use "ugly" async/await stuff everywhere. In hindsight, I prefer async/await. My reason is primarily that like your example points out, it really lets me be in full control over the scheduled behavior. I could even take non-io work and make it "async". Ie, some long processing application takes a break every million iterations to let other tasks steal some work. That's just cool! Arguably a similar thing could be designed in Go if every million iterations you used some type of IO primitive, like sending some data over a channel, but the behavior of Rust's model is more fine grained.

asdkhadsj 8y ago

Disclaimer: My understanding of Futures is limited. > 1. Make sure, manually(?), that all things are async / non-blocking. You'd have to make sure any IO you do is using Futures - ie, use a package to provide async IO primitives for disk and network access. You would also need to use the appropriate await syntax call on any future using methods - that would require a bit of overhead to know, but at least the compiler has your back on that. > 2. Implementing Future.poll / wrapping types in Future? In most cases I don't think you'd have a use case to implement a Future - would you? Ie, main IO calls are the big ones for wasting threads - and libraries like mio/hyper/etc provide your IO primitives. > 3. Async polution, a function that uses async must be async too? Yea, my understanding is that this is definitely an issue. I am already planning on using `async` tags on basically all my functions, because everything I use bound to IO in one form or another. On the bright side, I believe (don't quote me!) that you can drop ugly `fn foo() -> Futures<Item=Result<A,B>>` wrapping, since I believe `async fn foo() -> Result<A,B>` does the same thing. .. again, the syntax is not finalized haha. > 4. Setup some scheduler that maintain how many concurrent async operations one thread has? If you're using Async I'd imagine you'd already have chosen a scheduler. I believe Tokio will be the defacto - though Rayon might be involved here, not sure. > 5. More verbose error-messages / stack-traces? Errors themselves would be unaffected, if you're talking normal error values - remember those are just values in Rust, like Go, so not much special there. Though as you said, I imagine if you dump a trace it would look different, no idea. None of this post was meant to counter you in anyway. I just hoped to provide a bit of clarity on the tiny things I can contribute to. I hope I helped more than hurt. Have a nice day :)