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

281–290 of 392 posts

Re: Async-await on stable Rust

#281

Post by dnautics »

jabl wrote: post #189
jsiepkes wrote: post #130

Earlier quoted context omitted.

Erlang probably comes closest?

Not an Erlang user, but my understanding is that the Erlang VM (BEAM) schedules on function calls. Which works fine for that use, since Erlang does looping with tail calls, but is not a solution for procedural languages.

Erlang vm is fully preemptive and schedules on something called a reduction. You can call an external function with EFI that can screw things up, but otherwise it's not necessarily on what you might consider a function call .

Re: Async-await on stable Rust

#282

Post by stubish »

This seems very similar to Python's approach, which I've been finding poor to use.

I was wondering if a more pleasant approach would be to add a 'defer' keyword to return a future from an async call, and have the default call be to await and return the result (setting up a default scheduler if necessary). Requiring the await keyword to be inserted in the majority of locations seems poor UX, as is requiring callsites to all be updated when you update your synchronous API to async.

Re: Async-await on stable Rust

#284

Post by zelly »

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 is more high level than Java.

Re: Async-await on stable Rust

#285

Post by sbmthakur »

Rust beginner here who writes a lot of async code in Node.js. If I am to start writing async code in Rust, should I directly pick up async-await? Or should I first understand how it is done in the current way?

Re: Async-await on stable Rust

#286

Post by jchw »

ameixaseca wrote: post #206
brandonbloom wrote: post #194

Earlier quoted context omitted.

Yup. See https://journal.stuffwithstuff.com/2015/02/01/what-color-is-... for a pretty good explanation of the async/await problem. I know Rust is all about zero-cost abstractions, "but at what cost" beyond just runtime cost? I appreciate their principled approach to mechanical sympathy and interop with the C abstract machine, but I'm just not enthused about this particular tradeoff. An alternative design would have k…

Async adds a runtime requirement, so Rust cannot just take the same approach as Go. You only have a scheduler if you instantiate one. And having a runtime or not has nothing to do with the C abstract machine, but with precise control on what the code does. For instance, Go does not give you the option to handle this yourself: you cannot write a library for implementing goroutines or a scheduler, since it's embed in e…

Go is even more different. Rust async has explicit yields with await, but Go does it implicitly at various key locations. This is actually pretty surprising to many folks, it was in the past and maybe still is possible to deadlock Go with a certain incantation of tight looping.

Another difference with Rust is that async functions are stackless. Go has to contend with having a non-conventional stack and interoperability with C code (and sometimes syscalls, vDSO, etc.) that expects a relatively large stack requires pivoting.

I do wish Rust could solve this problem, but the two approaches are very different indeed. I think it’s a fact of life that accidental blocking will exist in Rust, approaches that prevent it are complicated and indeed have runtime costs.

Re: Async-await on stable Rust

#287

Post by pcwalton »

pron wrote: post #255
pcwalton wrote: post #149

Earlier quoted context omitted.

We tried this in Rust and found it was slower than 1:1 threading.

What you tried wasn't "this", though. It was one particular implementation of lightweight threading that has to cope with Rust's peculiarities, special requirements and compilation targets. There is absolutely nothing essential about lightweight threads that prevents them from emitting essentially the same code as the stackless-coroutine approach. It's just that in Rust it might be very hard or even not worth it, giv…

I don't understand what your objection is. It's a given that what I wrote applies to Rust. This is a thread about Rust. I didn't say that M:N threading is always slower than 1:1.

Besides, fibers don't emit essentially the same code as async code. One has a stack, and the other doesn't. That's a significant difference.

Re: Async-await on stable Rust

#288

Post by pcwalton »

pron wrote: post #268
matklad wrote: post #259

Earlier quoted context omitted.

Fibers under the magnifying glass [1] might be a relevant paper here. Its conclusion, after surveying many different implementations, is that lightweight threads are slower than stack less coroutines. [1]: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p136...

No, its conclusion is that fibers with certain properties in C/C++ are slower -- and particularly hard to implement correctly -- than stackless coroutines in C/C++ . That's because of the particular characteristics of those languages. In fact, you'll note that the only negative thing he says about Go is that it incurs an overhead when interacting with non-Go code.

And that overhead is a deal-breaker in Rust.

Re: Async-await on stable Rust

#289

Post by vanderZwan »

naasking wrote: post #133
vanderZwan wrote: post #114

Earlier quoted context omitted.

> you can get similar "structured concurrency"-like control flow with things like `futures::join!` or `futures::select!`. That sounds very promising, I should give it a closer look (I don't program in Rust myself so I only read blogs out of intellectual curiosity)

Or you can use something like protothreads or async.h [1] if you're stuck with C/C++ and need something lightweight. [1] https://news.ycombinator.com/item?id=21033496

Céu compiles to C actually, and I believe Francisco Sant’Anna (the author of the language) makes a direct comparison to protothreads and nesC in one of his papers (probably the PhD thesis). I had not seen async.h before though, interesting!

[1] http://ceu-lang.org/publications.html

Re: Async-await on stable Rust

#290

Post by jeffdavis »

johnisgood wrote: post #270
jeffdavis wrote: post #219

Earlier quoted context omitted.

Yes! Rust is the first language that is both truly good as a low-level systems language and also truly good as a high-level modern labguage at the same time . To me, it's amazing to finally have another option aside from just C/C++. Technically, I might have had some other options before, but rust gets it right.

I would say Ada/SPARK gets a lot of things right, too. What it lacks is hype and thus, a vibrant ecosystem. It can be a huge deal-breaker to many people.

Ada does have a good ecosystem and community, just not what we'd call modern and mainstream.

I looked specifically at Ada, and for my use case macros are quite important. If I were to use Ada, I would need a separate code gen step.

I also need concurrency without making new threads. I know Ada can do async but it doesn't have something like tokio.

A shame. I wanted to give Ada a try, but didn't get very far before losing hope.

Post reply on HN