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

271–280 of 392 posts

Re: Async-await on stable Rust

#271

Post by bcrosby95 »

kgraves wrote: post #185
pixel_fcker wrote: post #168

Earlier quoted context omitted.

Or maybe there are just a lot of people who like using rust because it fits their use cases very well and are excited about the release of a big new feature that’s been in development for a long time?

>...because it fits their use cases very well and are excited about the release of a big new feature. a bit too excited. GP isn't wrong, Go pretty much has the same thing and I have never seen so much fanboyism for a single feature ever in my career. I don't get it, but that might be because I am a manager.

Go and Rust are completely different in many ways. It's kinda like you're asking why someone would want a hybrid minivan when they've been making hybrid sedans for over 10 years.

Re: Async-await on stable Rust

#272

Post by ClumsyPilot »

pimeys wrote: post #242
ClumsyPilot wrote: post #240

Earlier quoted context omitted.

Maybe, but you linked the repo and it don't even have link to the website, let alone a description. Looks like a great project, best of luck.

Sorry, didn't mean this to be product advertisement, so I wanted to just link to the core code. The user-facing product is typescript and go and in different repositories. The backend is Rust and we jumped into the async/await train some months ago already. Wanted to share some experience and how quickly in the end we were able to get a working system out with the new apis.

I am perfectly happy for you to advertise , it's just that most people reading this probably are not rust developers, so it would be great to know what the project is about.

Re: Async-await on stable Rust

#273

Post by roblabla »

jayd16 wrote: post #265
roblabla wrote: post #247

Earlier quoted context omitted.

Join doesn't do everything. It's just a way to take multiple futures, and return a Future wrapping them all. I think there's a misunderstanding of how Futures and Executors interact in rust here which is why everyone is having a hard time understanding things. A future in rust is really just a trait that implements a `poll` function, whose return type is either "Pending" or "Ready ". When you create a future, you're…

This is essentially what I assumed and what I believe what ralusek assumes to be the case. This does not change our question. What would be the syntax for how you would spawn a future, add it to the current Executor, cooperatively yield execution in the parent such that progress could be made on the child, but also return execution to the parent if the child yields but does not complete? In C# I believe you could sim…

With async-std, you can just do

    let future = async_std::task::spawn(timer_future());
And then do more work. The timer_future will run cooperatively, and the future returned by spawn is merely a “join handle”.

But this is a feature of the executor, not something that’s part of the core rust async/await. With tokio, you’d have to spawn a separate future and use channels to get the return value.

Re: Async-await on stable Rust

#274

Post by wwright »

fnord123 wrote: post #245
ibotty wrote: post #173

Earlier quoted context omitted.

There is rayon in rust land. This is a pretty different (simpler) thing.

Rayon uses iterators. Iterators are the dual of first order functions. Iterators are superior because they are more general. (You can implement pmap using iterators. You cannot implement iterators using pmap.)

Does Rayon use iterators, or just iterator-like combinators? I don’t think a for-loop would work with Rayon, would it?

You can also definitely implement iterators using first-order functions:

    const iterate = array => {
      const step = index => ({
        value: array[index],
        next: () => step(index + 1)
      });
      return step(0);
    }

    // add some combinators on top
First order functions can in fact implement anything if you’re willing to accept some bad syntax and speed — that’s the Church-Turing equivalence.

Re: Async-await on stable Rust

#275

Post by wwright »

bulldoa wrote: post #186
littlestymaar wrote: post #127

Earlier quoted context omitted.

> Programming languages have the power to implement concurrency patterns that offer the same kind of performances, without the hassle. Can you give one that reaches this goal? Go is often cited on that regard but it doesn't really fit your description since it trades performance for convinience (interactions with native libraries are really slow because of that) and still doesn't solve all problems since hot loops ca…

> since hot loops can block a whole OS thread Asking as a beginner, what does the above mean? Not sure what does hot loop means, and why does it block Os thread

An “OS thread” is the most basic part of the program that can actually do things. When it is blocked, it can’t do anything.

OS threads can be expensive, so libraries try to only create a few OS threads.

A “hot loop” (usually, I think, called a “tight loop”) is a loop that does a lot of work for a relatively large amount of time all at once. Things like “looping through a list of every building an Manhattan and getting the average price over two decades.”

With some code like networking, you end up having to wait on other parts of the computer besides the CPU often, for things like uploads and downloads.

“Asynchronous programming” tried to make it easy to keep the CPU busy doing helpful things, even while some of it’s jobs are stuck waiting on uploads/downloads/whatever. This keeps the program efficient, because it can do a little bit of many tasks at once instead of having to complete each task entirely before moving on to the next.

The problem comes when you have a tight loop in a thread that is mostly expecting to be doing asynchronous work around I/O or networking. It is basically trying to juggle with one hand. The program can’t multitask as well, and you end up having to wait longer before it can start each piece of work you want.

Re: Async-await on stable Rust

#277

Post by GolDDranks »

asdkhadsj wrote: post #17
GolDDranks wrote: post #11

Earlier quoted context omitted.

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…

I'm not going to elaborate super deeply in a HN comment, but here's the gist: inside a function body, you can take a reference to a thing, and store that reference in a variable. Then if that function were "yields" to the executor, we have a situation that we couldn't have with sync code: in sync code, the "yielding" only happens at the function return, and by that point, all the internal references must be gone, as the function stack frame is going to disappear. But with async, as the yielding can happen without the function actually ending, we have to be able to store the stack frame, and the references stay alive. The new feature helps the compiler to reason about this. Before the "yields" were implemented as just returns, so the compiler didn't allow borrowing over yield points.

Re: Async-await on stable Rust

#278

Post by saghm »

esotericn wrote: post #164
dunkelheit wrote: post #122

Earlier quoted context omitted.

Yes, it works, but feels unnatural. I also don't like the possibility (quite remote, I admit) that the function gets called with a field from another instance.

The latter case should be impossible if the method is private?

In Rust, privacy isn't enforced like that. Private just means that things outside the module can't access them. There's no concept of privacy at the instance level.

Re: Async-await on stable Rust

#279

Post by monocasa »

steveklabnik wrote: post #260
0xdead wrote: post #254

Earlier quoted context omitted.

Can Rust's async even work on an Arduino or any bare-metal system?

Yes. Right now the implementation requires TLS but that will be going away.

To whoever downvoted Steve, he's talking about thread local storage, not transport level security.

Re: Async-await on stable Rust

#280

Post by db48x »

kd5bjo wrote: post #23
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…

It's probably worth noting that an async scheduler (executor in Rust terms) is required for this to be useful, hard to write yourself, and not provided by the standard library. There are crates that provide ready-made ones, and that will work for almost all cases, but it's another dependency that you have to evaluate and stay on top of. It is entirely possible to do yourself, though. Last month, I dove into the detai…

That looks like a great document. It's nice to know that people occasionally still write literate programs, and do it well.
Post reply on HN