I suppose you could say, this way of programming is the future.
Zero-cost futures in Rust
201–210 of 348 posts
Re: Zero-cost futures in Rust
#202I suppose you could say, this way of programming is the future.
get off my lawn this isn't reddit grumble grumble doesn't add to the conversation blah blah
Re: Zero-cost futures in Rust
#203Re: Zero-cost futures in Rust
#204Curious if someone has tried this and Eventual[0] with any thoughts on how they compare. https://github.com/carllerche/eventual
The futures crate is intended to be the successor to eventual, the author of which, Carl, helped us with some key insights in the futures crate as well.
Cool! Thanks for the reply :) It's nice to see some collaboration as opposed to trying to decide between competing crates.
Re: Zero-cost futures in Rust
#205Earlier quoted context omitted.
Coroutines would still run on top of std::future, it would be Just syntactic sugar to avoid callback hell via then chaining. In same case this might save some allocation as the callback would be a plain pointer to the control block, but that's about it. I'm not part of the committee nor I attend meetings, but I follow the papers and the public online discussions.
From the last Gor paper, coroutine don't need to run on top of the std::future class. The type traits required allows for more computational patters (like generators, agent/actor, full coroutines) etc...
No, but they are still designed to work well with std::futures and that's going to be the standard blessed way to do async IO.
Re: Zero-cost futures in Rust
#206Earlier quoted context omitted.
No. they are not two different points. You are artificially restricting the argument, and saying that some parts are a different question by introducing this new idea of "inherent nature" of a closure in rust : Some humans have legs, some do not. Does it mean that having legs is not an "inherent" part of the human experience? So to go back to the argument, we are trying to compare using a coroutine base approach vs u…
You don't have to destroy the "stack frame" (by which I assume you mean the state retained between blocking operations) every time you enter and leave. Why do you think you need to?
He's talking about the difference between swapping the stack pointer and executing a single "jump" instruction vs initiating a full function call (pushing argument(s), function prologue/epilogue)
Re: Zero-cost futures in Rust
#207Earlier quoted context omitted.
I think Rust's approach here makes a lot more sense for the language than Go/CML style M:N would. You can recover most of the M:N ergonomics over time via async/await style syntax. But if your foundation is built on a (comparatively) slow "pthreads in userland" threading model, then you hit a performance ceiling that you can never break through. For a language like Rust, it makes sense to begin in the optimum place a…
> You can recover most of the M:N ergonomics over time via async/await style syntax. While i agree with the tradeoff made by rust (although i think the approach used by C++ coroutine is better), i don't think that having async/await syntax give you "most" of the ergonomics of the Go M:N model . The main advantage of the go model is that both asynchronous and synchronous operations are identical, with async/await you…
> The main advantage of the go model is that both asynchronous and synchronous operations are identical
There is a bit of misunderstanding on your part. There are no asynchronous operations in that go model, everything is synchronous. There is no event loop underneath, despite what some people claim. And this is absolutely not an advantage in a shared memory environment. Instead it forces you to do synchronization to access memory, while different-looking asynchronous operations do not precisely because they are different-looking, otherwise it would be impossible to know what is running when and you would have to think about synchronization too.
It is not a secret that shared memory multithreading, while useful for parallelism, is the worst possible model for concurrency and this includes all flavors of coroutines as well.
Re: Zero-cost futures in Rust
#208I'm confused by .map(|row| { json::encode(row) }) .map(|val| some_new_value(val)) Over .map(json::encode) .map(some_new_value) Is the explicit extra layer of lambda generally prefered in Rust over just passing the functions?
I wonder if it is information used by the compiler to do error checks. Keep in mind that one of the goals of Rust is to catch common errors in C like languages at compile time rather than run time.
No. If there were a type error with either form, the compiler will catch it.
Re: Zero-cost futures in Rust
#209Earlier quoted context omitted.
Well, they're two different points: closures in rust do not inherently have to heap allocate. But that also doesn't mean that they can _not_ be heap allocated either. And in this example, it's not even really the closures that allocate: it's still one allocation, regardless of the number of closures.
No. they are not two different points. You are artificially restricting the argument, and saying that some parts are a different question by introducing this new idea of "inherent nature" of a closure in rust : Some humans have legs, some do not. Does it mean that having legs is not an "inherent" part of the human experience? So to go back to the argument, we are trying to compare using a coroutine base approach vs u…
> Some humans have legs, some do not. Does it mean that having legs is not an "inherent" part of the human experience?
I mean - yes, that is what it means.
Re: Zero-cost futures in Rust
#210Earlier quoted context omitted.
Thanks for your reply. I'm still trying to understand what the restrictions look like. Say I sometimes have an outstanding asynchronous operation, i.e. validating some text in a document. I want to represent this by storing a Future representing this operation: struct Document { text:String, validating: Option > }; It seems like there's a problem: in order to have a struct of this type, we need to have the type of th…
One solution is to put the Future into a Box.
And I can't believe I missed this, but the other way is to make the struct generic over a type implementing Future.