Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Async and Await in Rust: a full proposal

boats.gitlab.io

Post reply on HN
Print view View original

151–160 of 196 posts

Re: Async and Await in Rust: a full proposal

#151

Post by pas »

kuon wrote: post #135
lapinot wrote: post #101

And yet we somehow don't acknowledge the fact that this is just do-notation for some specific monad--yeah, that powerful abstraction that can't be expressed in Rust because we don't allow higher-order polymorphism. Don't get me wrong, i'm bitter because i feel like Rust really is almost in the right direction for the future of language design. Yet there is a long time before we get a language with a really precise ty…

I have been doing programming, including functional programming for more than two decades, I still don't really know what a "monad" is. Each time someone explains it to me, I understand something different.

Monads are containers for which .map, and .flatMap (>>= in Haskell) make sense.

Future, Option, List, State/IO, etc.

And the do-notation that some comments mention become a long list of flatMap/filter/map invocations.

  do {
    futRecord  record.id)
    username = futRecord.map(record -> record.name)
    futResult
This is just an abstraction, and it's not exactly a pretty one, but better than the flatMap hell in functional languages.

The do-notation uses the same monad throughout, in this example the Future one. The final yield is a map, the "Finally, Monads are very much like Vector Spaces in Maths. You have Axioms for both, and if the object satisfies them, it's a Monad or Vector Space!

https://devth.com/2015/monad-laws-in-scala

https://en.wikipedia.org/wiki/Vector_space#Definition

Re: Async and Await in Rust: a full proposal

#152

Post by pimeys »

Matthias247 wrote: post #142
kuon wrote: post #135

Earlier quoted context omitted.

I have been doing programming, including functional programming for more than two decades, I still don't really know what a "monad" is. Each time someone explains it to me, I understand something different.

The way I accepted it after years of confusion, and without still understand the word: A monad is any type which supports 2 specific operations. One maps an type into it's monadic form, and the other allows to apply functions to monadic types and returns the monadic type again. The latter is sometimes called bind or flatmap. For Future types, the first thing could be called MakeReadyFuture(type), the second one Futur…

... which allows a generic composition enabling imperative programming in a purely functional language. Haskell has do notation, that sugars the syntax to look like one is writing imperative code, even though it's all about composing Monads.

Re: Async and Await in Rust: a full proposal

#153

Post by wruza »

dpc_pw wrote: post #144
wruza wrote: post #143

This thread is so confusing to me. Not because of complex differences in a language theory, but on choices that developers do follow due to experience in ‘the past’, regarding light threads. I understand that rust has no stdlib, that go has, and that js just doesn’t have switchable stacks. But why does almost everyone inclined to async-await in general? The answers I got in other threads (not on this exact question,…

Note sure if I fully grasped your quesiton but here it goes. Light threads and stackfull coroutines require stack allocation. That is their cost and it is unbearable for system-level language priding itself in zero-cost abstractions. Eg. AFAIK, it's the main reason that is making Go calling C code slow. Also, (again AFAIK) Rust stackless coroutines and futures compile down to state machines, so I don't understand the…

To clarify: not why extreme requirements discourage heavier methods, but why people don’t use them for daily jobs that don’t require anything than fastest delivery time.

Re: Async and Await in Rust: a full proposal

#154

Post by Tehnix »

wruza wrote: post #143

This thread is so confusing to me. Not because of complex differences in a language theory, but on choices that developers do follow due to experience in ‘the past’, regarding light threads. I understand that rust has no stdlib, that go has, and that js just doesn’t have switchable stacks. But why does almost everyone inclined to async-await in general? The answers I got in other threads (not on this exact question,…

Does async/await alleviate the need for a runtime component? Because then I could see the decision make sense, else I am also really puzzled why anyone would not, given the opportunity, go with green threads (other than complex implementation, maybe).

Re: Async and Await in Rust: a full proposal

#155

Post by forkerenok »

pas wrote: post #151
kuon wrote: post #135

Earlier quoted context omitted.

I have been doing programming, including functional programming for more than two decades, I still don't really know what a "monad" is. Each time someone explains it to me, I understand something different.

Monads are containers for which .map, and .flatMap (>>= in Haskell) make sense. Future, Option, List, State/IO, etc. And the do-notation that some comments mention become a long list of flatMap/filter/map invocations. do { futRecord record.id) username = futRecord.map(record -> record.name) futResult This is just an abstraction, and it's not exactly a pretty one, but better than the flatMap hell in functional languag…

I would remove "containers" from the first line. In my reading it is ANYTHING for which monad laws hold.

Re: Async and Await in Rust: a full proposal

#156

Post by [deleted] »

lapinot wrote: post #101

And yet we somehow don't acknowledge the fact that this is just do-notation for some specific monad--yeah, that powerful abstraction that can't be expressed in Rust because we don't allow higher-order polymorphism. Don't get me wrong, i'm bitter because i feel like Rust really is almost in the right direction for the future of language design. Yet there is a long time before we get a language with a really precise ty…

[deleted]

Re: Async and Await in Rust: a full proposal

#157

Post by majewsky »

AndyKelley wrote: post #139
kibwen wrote: post #94

Earlier quoted context omitted.

Can you explain "this is less overhead than immediately suspending"? AFAICT Rust's approach is as low-overhead as it gets, since the inherent separation between future creation and future execution means that future creation doesn't need to have any cost at all. I'm also not sure it makes sense to refer to Rust's behavior as "immediately suspending", since it's not suspending anything: until someone chooses to start…

My understanding is that Rust uses LLVM coroutines[1]. In order to have the behavior where the function does not start executing immediately, you would follow the example that you can find by searching for "injected suspend point, so that the coroutine starts suspended". So what this looks like is: * Function call * The coroutine creates its frame (I believe this maps to "future creation".) * Function return (the inj…

> My understanding is that Rust uses LLVM coroutines[1].

IIRC it doesn't. Coroutines would induce a significant cost (one stack allocation per future) which would make futures unsuitable e.g. for embedded systems.

My understanding is that Rust will compile futures into state machines. So a future would be a closure with a data object that's a sum type with one variant per suspend point, that contains all the variables and references that are in scope at that suspend point. (That's also why Pin needs to be added for futures/generators: This set of variables may be self-referential.)

Re: Async and Await in Rust: a full proposal

#158

Post by gpderetta »

staticassertion wrote: post #108
infogulch wrote: post #103

Earlier quoted context omitted.

> you need to compile each function twice ... This can be wasteful. More wasteful than writing each function twice ? See C# for endless examples of libraries that have manual duplicate X() and XAsync() for every single method. If you compare the two they're almost always have the exact same body, except the async version has "async" and "await" peppered in and calls duplicate XAsync methods (which are implemented the…

I don't think you'd need to have two versions. If I have a sync function and I call something async, I should be able to just .wait() it, I think, and get the sync behavior.

Technically you do not, as you pointed out you can use the cps version for everything, but it is suboptimal, especially for interoperability with other languages and the os.

Re: Async and Await in Rust: a full proposal

#159

Post by pimeys »

k__ wrote: post #62
TekMol wrote: post #5

I'm waiting for the day when 'async' will be the default function type and 'await' will be the default type of function call. If anywhere down the callstack a function needs to await something it has to become an async function. And this needs to be done to the whole callstack recursively. So over time more and more functions of every codebase turn into async functions.

So we remove async/await from our async functions and add sync/block to our sync functions? :D

Actually Tokio already has `blocking` implemented!

https://docs.rs/tokio-threadpool/0.1/tokio_threadpool/fn.blo...

Re: Async and Await in Rust: a full proposal

#160

Post by pron »

avodonosov wrote: post #63
pron wrote: post #28

Earlier quoted context omitted.

This is the situation in Scheme, Erlang and Go (although the latter two strongly bind continuations with a specific, built-in scheduling), and what we're doing in Java as part of Project Loom. All Java functions will be able to run inside delimited continuations without modification. Continuations/coroutines are thus a purely dynamic rather than a syntactic entity.

Any news on Project Loom? When to expect it available?

We should have a public repo you can use to build Loom (a prototype at this stage) in a couple of weeks.
Post reply on HN