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

Async-await on stable Rust

blog.rust-lang.org

Post reply on HN
Print view View original

11–20 of 392 posts

Re: Async-await on stable Rust

#11

Post by GolDDranks »

takeda wrote: post #7
GolDDranks wrote: post #2

This is big! Turns out that syntactic support for asynchronous programming in Rust isn't just syntactic: it enables the compiler to reason about the lifetimes in asynchronous code in a way that wasn't possible to implement in libraries. The end result of having async/await syntax is that async code reads just like normal Rust, which definitely wasn't the case before. This is a huge improvement in usability.

Why would it be different for async code than sync code? The goal of Rust's checker is to track lifetime of an object so for example it knows that at the end of a function the object should be freed. Async shouldn't matter here.

The point is that Rust's borrow checker can't reason about lifetimes very well over function boundaries. It can reason about coarse things that are expressable in the type language, but everything more nuanced than that, such as reasoning about how control flow affects the lifetimes is limited to inside function bodies.

The difference between synchronous code and async code implemented as libraries is that async code involves jumping in and out of functions a lot, while employing runtime library code in between. A piece of code that is conceptually straightforward, may, in the async case, involve multiple returns and restores. In the sync case it doesn't need to do that, since it just blocks the thread and does the processing in other threads and in kernel land.

Rust's async/await support makes it possible to write code that is structurally "straightforward" in a similar way than synchronous code would be. That allows the borrow checker to reason about it in a similar way it would reason about sync code.

Re: Async-await on stable Rust

#12

Post by asdkhadsj »

sudeepj wrote: post #4

This is going to open the flood gates. I am sure lot of people were just waiting for this moment for Rust adoption. I for one was definitely in this boat. Also, this has all the goodness: open-source, high quality engineering, design in open, large contributors to a complex piece of software. Truly inspiring!

Maybe. I love Rust and use for all my work and hobby programming. With that said, I'm not in a super rush to use Async as it stands now.

This is a foundational implementation and while you _can_ use it, you are also likely to run into a host of partially implemented support problems. No fault of anyone, just a lot left to do. Examples being, you may run into needing async FS ops, so you bring in one of those libs. You may need async traits, so you bring in macro helper libs, you may need async DB interaction, so you check your db lib and hope they have support. Etcetcetc.

None of those are problems to stop you from using Async if you want. They're merely reasons you may not want to use Async quite yet.

Personally I've found Rust's development cycle to be such a joy, including manual threading, that I can get by happily without Async for the time being.

But, I'm not currently doing a lot of work where I'm dying to use greenthreads-like paradigms. Threading works fine in my web frameworks, db pooling, parallel libs like Rayon, etc. So because I've got all the power in Rust I need currently I just have no reason to use Async.

WITH THAT SAID.. use it if you want it! I just might not recommend it to people coming into Rust unless they explicitly need Async. It's bound to introduce a few - hopefully mild - headaches, currently.

Re: Async-await on stable Rust

#13

Post by kodablah »

I've been working with alpha futures, tokio, hyper, etc with async/await support on rust beta (didn't use async std yet) and can attest to them working quite well. There was quite a learning curve for me to know when to use arc, mutex, different stream combinators, and understand raw polling, but after I did, writing the code became a bit easier. I suggest anyone wanting to learn to grab a tcp-level networking project/idea/protocol and grind on it for days, heh.

Re: Async-await on stable Rust

#14

Post by nicoburns »

asdkhadsj wrote: post #12
sudeepj wrote: post #4

This is going to open the flood gates. I am sure lot of people were just waiting for this moment for Rust adoption. I for one was definitely in this boat. Also, this has all the goodness: open-source, high quality engineering, design in open, large contributors to a complex piece of software. Truly inspiring!

Maybe. I love Rust and use for all my work and hobby programming. With that said, I'm not in a super rush to use Async as it stands now. This is a foundational implementation and while you _can_ use it, you are also likely to run into a host of partially implemented support problems. No fault of anyone, just a lot left to do. Examples being, you may run into needing async FS ops, so you bring in one of those libs. Yo…

The library support's not quite there yet. But I'd bet on it being pretty good by the end of the year. A lot of popular libraries have async support on their master branches.

Re: Async-await on stable Rust

#15

Post by epage »

takeda wrote: post #7
GolDDranks wrote: post #2

This is big! Turns out that syntactic support for asynchronous programming in Rust isn't just syntactic: it enables the compiler to reason about the lifetimes in asynchronous code in a way that wasn't possible to implement in libraries. The end result of having async/await syntax is that async code reads just like normal Rust, which definitely wasn't the case before. This is a huge improvement in usability.

Why would it be different for async code than sync code? The goal of Rust's checker is to track lifetime of an object so for example it knows that at the end of a function the object should be freed. Async shouldn't matter here.

The challenge with async code is that the state across yield points is put into a struct and if a reference to a stack variable is used across yield points, then that struct is self-referential which Rust can't reason about (yet?). I honestly do not know who much can be recreated with `unsafe` and `Pin` vs how much is built-in.

I'd love for Rust to eventually get a Move trait (something like C=+ move constructors) to resolve this. Besides some complexity in designing it, there is resistance from some corners about having anything execute on a move.

Re: Async-await on stable Rust

#16

Post by buybackoff »

sudeepj wrote: post #4

This is going to open the flood gates. I am sure lot of people were just waiting for this moment for Rust adoption. I for one was definitely in this boat. Also, this has all the goodness: open-source, high quality engineering, design in open, large contributors to a complex piece of software. Truly inspiring!

Agree. I was starting with Rust a couple of times, but complicated async IO was exactly the reason I waited. Especially when knowing that async/await is coming there was zero reasons to learn the old way. But even when it hit nightly channel, it was impossible to use until major libraries expose the new API. So waiting now until Tokio and other mentioned libraries fully implement this. The next year is likely going to be the year of Rust, at least for me.

Re: Async-await on stable Rust

#17

Post by asdkhadsj »

GolDDranks wrote: post #11
takeda wrote: post #7

Earlier quoted context omitted.

Why would it be different for async code than sync code? The goal of Rust's checker is to track lifetime of an object so for example it knows that at the end of a function the object should be freed. Async shouldn't matter here.

The point is that Rust's borrow checker can't reason about lifetimes very well over function boundaries. It can reason about coarse things that are expressable in the type language, but everything more nuanced than that, such as reasoning about how control flow affects the lifetimes is limited to inside function bodies. The difference between synchronous code and async code implemented as libraries is that async code…

If you're familiar with this, can you describe some of those new concepts in ... slightly more detail? I say slightly, because I'm still seeking high level explanations, but at the same time I'm curious what new features might be making this async lifetime talk possible.

To further frame that question: I had assumed Rust was implementing Async within the capabilities of normal Rust. Such that, if lifetimes were being managed across function bounds, I assumed the lifetime would have "simply" been bound to the scope of the executor, polling the future you're actively waiting on.

However quickly I can see confusions in that description. Normal lifetimes within a function would need to bubble up and be managed by a parent, since that function's lifetime is, as you put it, being jumped in and out of frequently.

So I imagine that is partly where new features come into play? Giving Rust the ability to take a normal lifetime and extend or manage it in new ways?

Re: Async-await on stable Rust

#18

Post by nicoburns »

ChrisSD wrote: post #5
sudeepj wrote: post #4

This is going to open the flood gates. I am sure lot of people were just waiting for this moment for Rust adoption. I for one was definitely in this boat. Also, this has all the goodness: open-source, high quality engineering, design in open, large contributors to a complex piece of software. Truly inspiring!

Are there that many people looking for a new low level language for server side software?

Rust isn't only great because it's low level. Things like sum types (called enums in rust), pattern matching and expression orientation mean that it is often much more expressive than other languages for high level code.

Re: Async-await on stable Rust

#19

Post by losvedir »

Exciting! I know this has been a long time coming, so congrats to everyone for finally landing it in stable.

As a rust noob, small question based on the example given: Why does `another_function` have to be defined with `async fn`? Naively, I would expect that because it calls `future.await` on its own async call, that from the "outside" it doesn't seem like an async function at all. Or do you have to tag any function as async if it calls an async function, whether or not it returns a future?

Re: Async-await on stable Rust

#20

Post by asdkhadsj »

nicoburns wrote: post #14
asdkhadsj wrote: post #12

Earlier quoted context omitted.

Maybe. I love Rust and use for all my work and hobby programming. With that said, I'm not in a super rush to use Async as it stands now. This is a foundational implementation and while you _can_ use it, you are also likely to run into a host of partially implemented support problems. No fault of anyone, just a lot left to do. Examples being, you may run into needing async FS ops, so you bring in one of those libs. Yo…

The library support's not quite there yet. But I'd bet on it being pretty good by the end of the year. A lot of popular libraries have async support on their master branches.

Agreed - just trying to temper expectations. I'd hate for new users to come in and be frustrated due to implied "completeness" of Async. While Async itself might be "complete", as a broad concept it really needs so much more to be end-user complete.

Traits are a big one for me. Though, I've seen good things with the Async Trait Macro libraries. So hopefully those do good.

It doesn't make this Async-Stable event any less big of course, not trying to downplay it. We can't really move forward without this, so I'm super happy to see it merged! I'm just hoping to manage expectations :)

Post reply on HN