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

221–230 of 392 posts

Re: Async-await on stable Rust

#221

Post by stuhood »

ceronman wrote: post #215
Felz wrote: post #203

Earlier quoted context omitted.

I think Project Loom would fit. It's a remarkably sane approach: https://cr.openjdk.java.net/~rpressler/loom/Loom-Proposal.ht...

As a Java developer I'm really looking forward for Project Loom. I think it's a great approach that avoids the pitfalls of the two-colored functions approach. However, Project Loom doesn't fit into the "zero cost abstraction" paradigm of rust. Project Loom requires quite a lot of support form the JVM runtime: > The main technical mission in implementing continuations — and indeed, of this entire project — is adding t…

I think that that makes it fairly similar to Rust's approach then... compiler support for suspension, and cooperative scheduling.

Re: Async-await on stable Rust

#222

Post by floatboth »

mratsim wrote: post #213
jstimpfle wrote: post #111

Earlier quoted context omitted.

Or just use a preemptive scheduler (such as a regular OS scheduler). Or just be explicit, and take difficulties with being explicit as an indication that the data flow is maybe not very well designed. I don't know, maybe there are valid applications for await (such as much frequented web servers, where you might want to have 10s of thousands of connections, that would be too expensive to model as regular threads, but…

await allows to write concurrent (for IO) or parallel (for CPU) code like it was serial. The issue it solves is programmer having trouble executing parallel code in their head, and when relationship became intricate (a computation graph) they just breakdown and write buggy software. A scheduler is targeted at use cases. A preemptive scheduler optimize for latency and fairness and would apply for real-time (say live a…

You don't need await for data (CPU) parallelism. You'd typically use something like https://github.com/rayon-rs/rayon or OpenMP instead.

Re: Async-await on stable Rust

#223

Post by Matthias247 »

bluejekyll wrote: post #129
phamilton wrote: post #120

Earlier quoted context omitted.

I am waiting for a language to solve this with the type system and compiler. Give me the ability to mark a thread as async only and a clean (async) interface to communicate with a sync thread. If my async code tries to do anything sync, don't let it compile.

Sorry, how is Rust not that language? You can use single threaded executors that only require Send and not Sync on data being executed on.

Nit: Singlethreaded executors also don't require "Send", since they don't move things between threads. That allows you too e.g. use non-atomically refcounted things (Rc) on singlethreaded executors, which you can't use in the multithreaded versions.

Re: Async-await on stable Rust

#224

Post by Matthias247 »

ComputerGuru wrote: post #22

I’ve been playing with async await in a polar opposite vertical than its typical use case (high tps web backends) and believe this was the missing piece to further unlock great ergonomic and productivity gains for system development: embedded no_std. Async/await lets you write non-blocking, single-threaded but highly interweaved firmware/apps in allocation-free, single-threaded environments (bare-metal programming wi…

Yeah, that's a super interesting idea that I'm also toying with in my head. One issue however is the "allocation-free" part. Sooner or later you typically hit a situation where you need to box a Future - either because you want to spawn it dynamically or need dynamic dispatch and type erasure. At that point of time you will need an allocator.

I'm still wondering if lots of the problems can be solved with an "allocate only on startup" instead of a "never allocate" strategy, or whether full dynamical allocation is required. Probably needs some real world apps to find out.

Re: Async-await on stable Rust

#225

Post by gdxhyrd »

kag0 wrote: post #209
grumpyprole wrote: post #47

Earlier quoted context omitted.

JavaScript automatically starts the tasks and this is bad design IMHO. One loses referential transparency and the ability to run the workflow with different schedulers. It looks like Rust has done a better job.

On referential transparency, I couldn't tell from the blog but are the Rust futures memoized/cached? If they are, then they're still not referentially transparent. But if they aren't then it might be a bit of a surprise to developers coming from other languages (especially ones not familiar with something like an IO monad).

Rust futures are just types that implement an interface providing a method to advance execution if possible and signal when they have more work to do.

Re: Async-await on stable Rust

#226

Post by Matthias247 »

School-Cotton wrote: post #27
nicoburns wrote: post #18

Earlier quoted context omitted.

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.

ML-inspired languages have all these features too; is the advantage of Rust over those just that it’s more mainstream, the ecosystem is bigger, etc.?

Right. You could use F#, and get the pretty big .NET ecosystem with it. I think some people are mainly attracted to Rust due it's novel and open-source attributes. There is certainly a hype factor involved in it. In my opinion Rust is great (I use it), but I think it's main strength are in different domains than web applications.

Re: Async-await on stable Rust

#227

Post by maccam912 »

pimeys wrote: post #205

The same day as async/await hits stable, the next Prisma alpha is released and is the first alpha that's based on Futures and async/await. https://github.com/prisma/prisma-engine/ Been working with the ecosystem since the first version of futures some years ago, and I must say how things are right now it's definitely much much easier. There are still optimizations to be made, but IO starts to be in a good shape!

What is this? The Github repo doesn't offer a description.

Re: Async-await on stable Rust

#228

Post by McWobbleston »

School-Cotton wrote: post #27
nicoburns wrote: post #18

Earlier quoted context omitted.

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.

ML-inspired languages have all these features too; is the advantage of Rust over those just that it’s more mainstream, the ecosystem is bigger, etc.?

One of my favorite features of Rust as someone who dabbles is that thread safety is expressed in the type system. F# is perfectly happy to let me share mutable data across threads without any synchronization, while the Rust compiler knows whether something can be safely accessed because you've either transferred ownership, or the type is thread safe.

The ownership system is also a very clever approach to managing mutable state. Usually in F# you'd get something of the same effect by using immutable structures and creating new copies, which does have a small performance impact

Re: Async-await on stable Rust

#229

Post by jeffdavis »

eeZah7Ux wrote: post #143

The level of fanboyism in the comments is saddening. Many other fast and productive languages have async since a while.

There is a reality behind the hype. I know, because I've been working on https://github.com/jeff-davis/postgres-extension.rs, and I've hit real problems. Those problems have been resolved one by one over the years.

I can't imagine doing that project it any other language.

Re: Async-await on stable Rust

#230

Post by bernawil »

jayd16 wrote: post #195
bernawil wrote: post #169

Earlier quoted context omitted.

>Whats a good language that shows off the style you're suggesting? javascript. What you describe sounds like native UI work since forever before javascript. "Don't block the main thread" and all that. Javascript is diferent in that it's a single-thread with an event loop. Synchronous functions execute until they end. Asynchronous functions are handled by the event loop which "loops" between the pool and runs each one…

Yes, I realize all this. My question is how you can have such a system and still keep UI thread synchronization without having the opposite problem of marking all your synchronous methods.

in a strict language? I don't think it's possible. Because if you take a better look you'll see that it's not enough to mark functions as sync or async since inside the functions each line of code can be considered a synchronous function in it's own.

What you want is something like Haskell that's lazy and its not about "executing statements" but rather "evaluting expressions".

Post reply on HN