News for hackers. Stuff that matters.
Re:Async and Await in Rust: a full proposal by lapinot on Sunday July 15, 2018 @08:00PM (#17537808)
Yeah, sure, i understand that, hn comments just need to be a bit spicy (btw, any ref of papers or other stuff in that area? i didn't follow closely but didn't see too much moving, actually i don't even know what the big question marks are). Although i really believe it's not about if but how, so let's hope that when the time comes Rust will be able to take the tough changes necessary to unify the different branches that split off.

Like what is the real road-blocker, since we're talking here about abstractions that are gonna be monomorphised (at most into lifetime-polymorphic function, which anyway get erased) and known statically, right? Is it only a problem of getting the typing rules consistent and robust?

Re:Async and Await in Rust: a full proposal by steveklabnik on Sunday July 15, 2018 @08:22PM (#17537878)
There's multiple issues. The biggest ones that I can recall, off the top of my head:

First off, do notation desugars to closures. But Rust has three different kinds of closures. How does that work?

Furthermore, Rust has imperative control structures. How does all of this interact with each other? Are you now no longer allowed to use those constructs inside of do notation? That feels inconsistent.

I don't know of any languages that have something like do notation but don't have everything boxed. It makes everything easier, but that's not generally acceptable in Rust. For example, we can use async/await with no dynamic allocation. Could we with do notation?

"Open question" doesn't mean "impossible", mind you. But nobody has ever come up with a design. In the meantime, we have users to support...

Re:Async and Await in Rust: a full proposal by lapinot on Sunday July 15, 2018 @08:32PM (#17537909)
Thanks, that's interesting, i should dive a bit more into how async is implemented. On "which closure kind to choose" i feel like that's not the worst part (closure syntax already infers which trait to implement), but the fact that it is a closure and how it fares with allocation seems not trivial.
Re:Async and Await in Rust: a full proposal by kibwen on Sunday July 15, 2018 @08:31PM (#17537906)
For the moment, you can see the progress on empowering the type system in the RFC for generic associated types, which is intended both to be the simplest extension to the type system that allows for some important patterns (e.g. streaming iterators and collection traits) and to be forward-compatible with any additional extensions in the direction of HKT. Importantly, it's also intended to be intuitive for users who have no prior experience with higher-kindedness and usable without (hopefully) requiring anyone to learn anything about type theory. The RFC text can be read at https://github.com/rust-lang/rfcs/blob/master/text/1598-gene... and comments can be left on the tracking issue at https://github.com/rust-lang/rust/issues/44265 .
Re:Async and Await in Rust: a full proposal by steveklabnik on Sunday July 15, 2018 @08:37PM (#17537932)
Note also that HKT and do notation are their own separate things; you can have HKT without do notation. That's all HKT stuff, not do notation stuff.
Re:Async and Await in Rust: a full proposal by chongli on Sunday July 15, 2018 @08:51PM (#17537986)
If you have HKT then isn't do notation a piece of cake? It just desugars into monadic bind and return operators. Or is there something specific to rust that would mess with that?
Re:Async and Await in Rust: a full proposal by pcwalton on Sunday July 15, 2018 @08:55PM (#17538003)
Imperative control flow, for one. Think about how you would implement "break" that can break out of multiple nested loops in do-notation…
Re:Async and Await in Rust: a full proposal by steveklabnik on Sunday July 15, 2018 @08:56PM (#17538006)
Re:Async and Await in Rust: a full proposal by dagenix on Sunday July 15, 2018 @11:43PM (#17538589)
I thought I had read at some point that generic associated types we're equivalent to HKTs in terms of what they can express. Or maybe that they were theorized to be so. Is that not the case? (Not critical, just curious)