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 :)
> 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 :)