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

Async Rust never left the MVP state

tweedegolf.nl

Post reply on HN
Print view View original

131–140 of 273 posts

Re: Async Rust never left the MVP state

#131

Post by j16sdiz »

robmccoll wrote: post #127

Any solution that involves having to use a keyword to get the value returned from a function is such a poor design choice to me. Nearly every time I call a function I don't want to have to care if it is synchronous or not. I want the syntax and grammar (and illusion?) of one continuous thread of execution. The few times where I explicitly want to not wait are the places that should be special. This is why new languag…

What you want is quite the opposite of what rust is -- rust force rules.

Look at how the borrow works. Most of the time, the compiler can _suggest_ the fix.. and instead of fixing that silently, they want you to fix it.

This is the design choice they made.

Re: Async Rust never left the MVP state

#132

Post by aw1621107 »

robmccoll wrote: post #127

Any solution that involves having to use a keyword to get the value returned from a function is such a poor design choice to me. Nearly every time I call a function I don't want to have to care if it is synchronous or not. I want the syntax and grammar (and illusion?) of one continuous thread of execution. The few times where I explicitly want to not wait are the places that should be special. This is why new languag…

> Any solution that involves having to use a keyword to get the value returned from a function is such a poor design choice to me.

Technically speaking Rust didn't have to use a keyword (and in fact didn't for quite some time between 1.0 and when async was added), but the ergonomics of the library-based keyword-less solutions was considered to be less than optimal compared to building in support to the language.

> This is why new languages should build in green threading from the start.

This, just like most other decisions one can make when designing a language, is a tradeoff. Green threads have their niceties for sure, but they also have drawbacks which made them a nonstarter for what the point in the design space the Rust devs were aiming for. In particular, the Rust devs wanted something that did not require overhead for FFI and also did not require foreign code to know that something async-related is involved. Green threads don't work here because they either have overhead when copying stuff between the green thread stack and the foreign stack or need foreign code to understand how to handle the green thread stack.

Re: Async Rust never left the MVP state

#133

Post by tremon »

robmccoll wrote: post #127

Any solution that involves having to use a keyword to get the value returned from a function is such a poor design choice to me. Nearly every time I call a function I don't want to have to care if it is synchronous or not. I want the syntax and grammar (and illusion?) of one continuous thread of execution. The few times where I explicitly want to not wait are the places that should be special. This is why new languag…

> I want the syntax and grammar (and illusion?) of one continuous thread of execution

Then you shouldn't be using a low-level systems language? You can simply choose a higher-level abstraction language that better matches your programming preferences.

Re: Async Rust never left the MVP state

#134

Post by lame_lexem »

dragochat wrote: post #124

what's the modern "absolute beginner's guide to async in Rust" - ideally something dense that can bring someone motivated from beginner to expert in ~1 week of intense hacking on it?

there is a chapter on async in comprehensive rust and rustbook which ought to bring you up to speed

there is the async book but it is largely unfinished

you can watch John Gjengset's crust of rust async, decrusting tokio, and why what, and how of pinning in rust

then there are tokio-lessons and tokio tutorial which teach how to use tokio runtime

and there are also good blogposts by phil-oop and rose wright on how async works

https://doc.rust-lang.org/book/ch17-00-async-await.html https://google.github.io/comprehensive-rust/concurrency/welc...

https://rust-lang.github.io/async-book/intro.html

https://youtu.be/ThjvMReOXYM https://youtu.be/o2ob8zkeq2s https://youtu.be/DkMwYxfSYNQ

https://github.com/freddiehaddad/tokio-lessons https://tokio.rs/tokio/tutorial

https://os.phil-opp.com/async-await/ https://dev.to/rosewrightdev/from-futures-to-runtimes-how-as...

Re: Async Rust never left the MVP state

#136

Post by groundzeros2015 »

repelsteeltje wrote: post #57
groundzeros2015 wrote: post #11

Earlier quoted context omitted.

Such as? The entire premise of async is that callbacks were a mistake because they broke sequential reasoning and control. Every explanation of the feature starts with managing callback hell.

Beware, they are different concepts. Threads offer concurrent execution , async (futures) offer concurrent waiting . Loosely speaking, threads make sense for CPU bound problems, while async makes sense for IO bound problems.

Why? You write the same code with async await but with a keyword at the beginning of every function.

Re: Async Rust never left the MVP state

#137

Post by twic »

brabel wrote: post #89
ignoreusernames wrote: post #66

Agree with the other commenters that the title is a bit too dramatic. The content was well written and got the point across. I still don’t have enough experience to have a strong opinion on Rust async, but some things did standout. On the good side, it’s nice being able to have explicit runtimes. Instead of polluting the whole project to be async, you can do the opposite. Be sync first and use the runtime on IO “edge…

As you mentioned Java, it’s interesting to notice that it has had similar problems throughout its history: logging (now it’s settled on slf4j but you still find libraries using something else), commons (first Apache Commons, now Guava), JSON (it has settled on Jackson but things like Gson and Simple-json are not uncommon to see), nullability annotations ( first with unofficial distributions of JSR-305 which never bec…

The traditional approach in Java has been to let those things happen in third party space, then form an expert group to standardise a shared API for them. That was done with XML parsers and ORM fairly successfully. It doesn't always work, as with your examples - there was an attempt with logging, but it was done badly, JSR-305 ran around, etc. But I think it's a much better approach than the JDK maintainers trying to get it right first time.

Re: Async Rust never left the MVP state

#138

Post by groundzeros2015 »

K0nserv wrote: post #81
groundzeros2015 wrote: post #4

Async seems like an underbaked idea across the board. Regular code was already async. When you need to wait for an async operation, the thread sleeps until ready and the kernel abstracts it away. But We didn’t like structuring code into logical threads, so we added callback systems for events. Then realized callbacks are very hard to reason about and that sequential control is better. So threads was the right program…

I think you are correct, in so far that often N:M threading is overkill for the problem at hand. However, some IO bound problems truly do require it. I haven't kept up with the details, but AFAIK the fallout from Spectre and Meltdown also means context switches are more expensive than they were historically, which is another downside with regular threads. I also want to address something that I've seen in several sub…

I think rust didn’t need async at all.

Re: Async Rust never left the MVP state

#139

Post by pjc50 »

groundzeros2015 wrote: post #33
vlovich123 wrote: post #28

Earlier quoted context omitted.

That’s incorrect. Even when expressed suboptimally, it still tends to result in overall higher throughput and consistently lower latency (work stealing executors specifically). And when you’re in this world, you can always do an optimization pass to better express the concurrency. If you’ve not written it async to start with, then you’re boned and have no easy escape hatch to optimize with.

Why can’t you do the same optimization? Are you maxing out you OS system resources on thread overhead?

OS thread overhead can be pretty substantial. Starting new threads on Windows is especially expensive.

Re: Async Rust never left the MVP state

#140

Post by zozbot234 »

robmccoll wrote: post #127

Any solution that involves having to use a keyword to get the value returned from a function is such a poor design choice to me. Nearly every time I call a function I don't want to have to care if it is synchronous or not. I want the syntax and grammar (and illusion?) of one continuous thread of execution. The few times where I explicitly want to not wait are the places that should be special. This is why new languag…

> Nearly every time I call a function I don't want to have to care if it is synchronous or not.

The problem is that "nearly every time" bit. There's times where you are looking at the code and you absolutely want to be aware of where the function is suspending. Similar to the use of ? in error handling to surface all failable operations that might do an abnormal return.

Post reply on HN