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

181–190 of 196 posts

Re: Async and Await in Rust: a full proposal

#181

Post by steveklabnik »

fmap wrote: post #180
withoutboats wrote: post #116

Earlier quoted context omitted.

I don't have time to write a whole essay, so let me just establish my credentials: - I wrote the generic associated types RFC (how Rust will implement higher kinded polymorphism). - I wrote the const generics RFC (the closest Rust will get to dependent types). - I wrote the async/await RFC, as well as the linked blog post. That is to say that I am intimately familiar with how Rust's type system can be extended to sup…

Have you considered algebraic effects and handlers? If you add a linearity restriction on the return continuations (easily doable with the existing type system of Rust) their implementation is no harder than async/await, yet they can express many useful monadic abstractions. ...I saw this thread too late, hopefully you will still see this comment. I'm genuinely curious.

There's a sibling subthread about this. https://news.ycombinator.com/item?id=17538191

Re: Async and Await in Rust: a full proposal

#182

Post by avodonosov »

pron wrote: post #167
avodonosov wrote: post #162

Earlier quoted context omitted.

What does such build produce? A JVM? A bytecode converter which produced code for existing JVMs?

A full JDK (with a VM, of course). Loom includes both changes to the VM and the core JDK libraries.

Is there any roadmap for inclusion into release?

Re: Async and Await in Rust: a full proposal

#183

Post by Tyr42 »

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.

Just to add more different explanations, since that'll help.

http://blog.sigfpe.com/2006/08/you-could-have-invented-monad...

This one is my favourite, and does it well by example and walking through three different cases, then generalizing.

Re: Async and Await in Rust: a full proposal

#184

Post by runT1ME »

withoutboats wrote: post #130
lapinot wrote: post #127

Earlier quoted context omitted.

Didn't mean to bash the lang design team at all, actually i was kinda hoping for you folks to reply interesting and tricky stuff about how things are not so simple. This is probably only because you didn't develop the answer fully but i still struggle to see how monads (or other structures in that family) couldn't apply here: they aren't implemented in any way and just provide interface (eg not caring about rust at a…

Here are three problems: Higher kinded polymorphism results in trivially undecidable type inferences without something like currying; the restrictions needed to support it would be arbitrary and weird given that Rust does not have currying (essentially some rules to reconstruct the restrictions of currying in type operator context). Instances of both Future and Iterator do not implement the Monad type class as define…

You don't need HKTs to implement 'do' notation. A good example is LINQ query syntax from C#! You actually have full blown monadic comprehension that you can use to easily write 'flattened' (ie, no async pyramid of doom) Future/Promise code with.

Re: Async and Await in Rust: a full proposal

#185

Post by snuxoll »

runT1ME wrote: post #184
withoutboats wrote: post #130

Earlier quoted context omitted.

Here are three problems: Higher kinded polymorphism results in trivially undecidable type inferences without something like currying; the restrictions needed to support it would be arbitrary and weird given that Rust does not have currying (essentially some rules to reconstruct the restrictions of currying in type operator context). Instances of both Future and Iterator do not implement the Monad type class as define…

You don't need HKTs to implement 'do' notation. A good example is LINQ query syntax from C#! You actually have full blown monadic comprehension that you can use to easily write 'flattened' (ie, no async pyramid of doom) Future/Promise code with.

A better example would be computation expressions in F#, the async {} and query {} builders are super easy to work with and don't rely on HKT's to work (since there's no such thing in .Net). I think such a design would work pretty well in rust, and doesn't require adding a bunch of single-purpose keywords - something I wish the C#/.Net team did considering F# had async first.

Re: Async and Await in Rust: a full proposal

#186

Post by steveklabnik »

snuxoll wrote: post #185
runT1ME wrote: post #184

Earlier quoted context omitted.

You don't need HKTs to implement 'do' notation. A good example is LINQ query syntax from C#! You actually have full blown monadic comprehension that you can use to easily write 'flattened' (ie, no async pyramid of doom) Future/Promise code with.

A better example would be computation expressions in F#, the async {} and query {} builders are super easy to work with and don't rely on HKT's to work (since there's no such thing in .Net). I think such a design would work pretty well in rust, and doesn't require adding a bunch of single-purpose keywords - something I wish the C#/.Net team did considering F# had async first.

async blocks require keyword in rust because it conflicts with a struct constructor.

Re: Async and Await in Rust: a full proposal

#187

Post by snuxoll »

steveklabnik wrote: post #186
snuxoll wrote: post #185

Earlier quoted context omitted.

A better example would be computation expressions in F#, the async {} and query {} builders are super easy to work with and don't rely on HKT's to work (since there's no such thing in .Net). I think such a design would work pretty well in rust, and doesn't require adding a bunch of single-purpose keywords - something I wish the C#/.Net team did considering F# had async first.

async blocks require keyword in rust because it conflicts with a struct constructor.

F# works around this by having expression builders be normal types, `async` is just an alias for Control.AsyncBuilder (actually, it's an instance of it if I want to be technical), it's not even a reserved word in the language specification. This is why I feel such an implementation would be a great fit for Rust, the parser already has to figure out different contexts curly braces could be used (struct initializers, lexical scoping constructs, closures, the list goes on) - you can avoid adding an extra reserved keywords and get support for more than just async expressions.

Re: Async and Await in Rust: a full proposal

#188

Post by wahern »

kevingadd wrote: post #10
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.

One of the biggest advantages of await is that it's explicit. Otherwise literally any function call can block, and whether or not it blocks is dependent on the body of the function so you can end up with races appearing in random parts of your code because you update a package. It's bad. At that point you might as well just use threads and blocking calls.

Data races like that can only happen when you share mutable state across logical flows of control. Don't share mutable state, regardless of your concurrency framework. I don't see how explicit vs implicit yield points change this fact. Either way there's precisely one logical flow of control that should own your data. In a language like Rust this is strongly enforced, regardless.

Futhermore, in any complex asynchronous I/O app most functions will end up being tagged async. The only ones that won't are simple leaf functions that wouldn't implicitly yield, anyhow. If someone has the bad idea to, e.g., put a yield point in non-obvious leaf functions as part of some kind of hack (e.g. logging, tracing), they're gonna do it in the async/await case, too, because they're already convinced it has value. Having to a drop a few more annotations here or there won't stop them from breaking the app.

Lastly, the bugs that do occur in these sorts of cases usually have to do with unpredictable latencies violating implicit or accidental ordering assumptions. async/await doesn't mitigate that at all because latencies are just as unpredictable. The solution, as always, is to avoid these ordering dependencies by not sharing mutable state.

This defense of async/await is a red herring.

Re: Async and Await in Rust: a full proposal

#189

Post by pas »

sullyj3 wrote: post #176
pas wrote: post #169

Earlier quoted context omitted.

I guess flatMap is very misleading to newcommers. Probably simply calling it chaining, composition, or even "then" would help.

I like chaining, that's a good analogy. I feel like, now that I have a certain level of intuitive understanding of what bind does, to me, the `>>=` symbol best represents what the operation does. It just looks like some kind of physical gadget that extracts a thing from a container, does something to it, and injects it into the next container. This is pretty ironic given Haskell's (somewhat deserved) reputation as im…

I know a lot of symbols, but I still get irritated when I encounter a new one, and I can't search for it. (At least math got a nice list: https://en.wikipedia.org/wiki/List_of_mathematical_symbols )

For math it's kind of okay. Because there the point is to talk about that theory. You introduce definitions, and theorems, and use them in proofs. Or in calculations.

And even in math proofs usually come with a lot of explanation. (At least the better ones.)

In software engineering maintainability is important.

And, sure, we can just accept that Haskell is something that you can't learn by looking at real world Haskell code. After all, you can't really learn real world "research math" by looking at it.

But I think real world code, especially one that is looking for maintainers should not err on the side of indecipherability and inapproachability.

I continue to chastise Scalaz for its bad naming and documentation convention. (Haskell is ... well, it's irredeemable.)

And TypeScript is getting into this mess too. The documentation for new releases with new type system goodies (and I really mean it, I like powerful type systems, I just don't want to spend my life on understanding them, I'm happy to use them to get particular jobs done), but with barely enough documentation to let serious TS users with many years of experience understand it.

Re: Async and Await in Rust: a full proposal

#190

Post by Retra »

EGreg wrote: post #147

I know this may sound silly, but can someone make a quick rundown of the pros (and maybe cons) of Rust as compared to NodeJS, Go and Erlang? Why would people use it as opposed to these far more mature ecosystems, especially if it’s hard to master based on the comments I have seen from Rust users? (Not trying to be biased, actually want to ask people who do choose it.)

Hard to master doesn't mean it isn't worthwhile to master. And the only reason the Rust ecosystem is not more mature is because not enough effort has been put into it. By learning the language and working in it, both of the problems you point out will solve themselves.

This is a classic "being traffic" comparison. If you're in a traffic jam, you are as much the cause of it as anyone else is. Likewise, if the ecosystem is immature, you are as much the reason for that as anyone else who doesn't participate in it.

Post reply on HN