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

A four year plan for async Rust

without.boats

Post reply on HN
Print view View original

111–120 of 236 posts

Re: A four year plan for async Rust

#111

Post by tuetuopay »

nextaccountic wrote: post #71
sargun wrote: post #56

I was a huge opponent of Rust, but finally decided to give it a try in anger once again. I began writing a large application, and noticed that many of my libraries only offered async versions, and the promise was quite appealing -- not having to worry about threads or concurrency as long as I followed certain rules. What I ended up with was an incredibly slow application because of the limitations of Rust async, and…

Why didn't you use the multithreaded executor from Tokio?

Tokio does sync I/O in the background with dedicated I/O threads if memory serves. (it is sync in the sense it does syscalls, which are pushed to a dedicated thread).

Re: A four year plan for async Rust

#112

Post by samus »

jayd16 wrote: post #59
no_wizard wrote: post #47

Earlier quoted context omitted.

I will forever argue that things like goroutines and the Java Loom Project are proving that it is long term more successful than making an explicit async keyword / operation that has its own semantics when invoked, because it won't dictate your code and cause the color function problem to exist. I'd love to see this in Rust, and I know that it initially had something like this, perhaps its not a bad idea for someone…

Async handles thread contexts better. Maybe I'm out of the loop but implicit blocking patterns haven't taken over gui programming just yet.

Loom is very new, and Java on the desktop is almost dead. Even though virtual threads could be useful for GUI programming, I don't expect significant innovation in that area. But the upcoming Structured Concurrency[0] and Scoped Values[1] JEPs make things hopefully easier.

[0]: https://openjdk.org/jeps/462

[1]: https://openjdk.org/jeps/446

Re: A four year plan for async Rust

#113

Post by lambdaone »

What makes Rust great is that its design drew upon decades of understanding of programming language theory and practice, and the designers took bold decisions based on that understanding to avoid the mistakes of other programming languages.

The problem with async Rust is that the async idiom is new, and its interactions with the rest of the software ecosystem not particularly well understood. This makes async support glaringly different from the rest of the language.

I'm glad the designers seem to be taking a step back and reconsidering how everything fits together.

Re: A four year plan for async Rust

#114

Post by empath-nirvana »

inamberclad wrote: post #2

Async is a huge wart and I try and avoid it wherever possible. It's simply not useful in a lot of cases that I encounter. However, if a library uses async, you have little choice but to make your whole project async. This adds to its horrible reputation.

I genuinely don't understand the problems people have with async code... at least for anything involving http/api requests it's largely just a matter of decorating stuff with 'async/await'. It makes a few things difficult (iterators with futures, ugh), but mostly it's easy.

Re: A four year plan for async Rust

#115

Post by bryanlarsen »

lucasyvas wrote: post #40

I think std needs a default runtime, and we might as well make it tokio, but maybe make the single-threaded executor the default instead and tweak the API where appropriate to align with this change. Swapping the executors out should absolutely be a feature, and the traits should be portable, but a way to start fixing the situation beyond the great suggestions in this proposal is to acknowledge that std and no-std us…

I believe that without.boats (or somebody of similar prominence) proposed that pollster (https://docs.rs/pollster/latest/pollster/) or a similar async executor be pulled into std.

I think it's a great idea. By blessing something that's not tokio you give a good incentive for library authors to test against more than one executor. And by being so far from fully featured pollster is never going to "win" so blessing it doesn't appoint a winner. And it gives an obvious solution for what people who don't want to use async in their code but do want to pull in an async library should do.

edit: it was without.boats in this post: https://without.boats/blog/why-async-rust/

Re: A four year plan for async Rust

#116

Post by mplanchard »

gnulinux wrote: post #76
sargun wrote: post #56

I was a huge opponent of Rust, but finally decided to give it a try in anger once again. I began writing a large application, and noticed that many of my libraries only offered async versions, and the promise was quite appealing -- not having to worry about threads or concurrency as long as I followed certain rules. What I ended up with was an incredibly slow application because of the limitations of Rust async, and…

In these debates I find myself very confused. I feel very comfortable with async ergonomics in Rust. It seems like the argument against it is that it has poor ergonomic... but how? It's rather straightforward to go from sync to async and async to sync you just have to code the strategy in. If you're in sync and need to run async, you need to run it in some executor (either in threads or in single-thread concurrency o…

Just noting for the sake of countering this narrative that async rust is fundamentally broken that I feel the same way as you, having been working with async rust professionally for 2.5 years.

Re: A four year plan for async Rust

#117

Post by samus »

kroltan wrote: post #97
samus wrote: post #58

Earlier quoted context omitted.

The problem with C++ is that every feature - attempts to solve too many problems, - has significant papercuts that have to be considered, - has significant runtime cost, - interacts poorly with other features, or at least leaves significant edge cases open, - has non-uniform compiler support (although in OSS land only GCC and LLVM matter), and - creates arcane error messages that are anything but fun to analyze. Espe…

That list of bullet points (except the compiler one) is also applicable to the whole async ecosystem in Rust :)

I for sure hope that Rust gets at least the safety aspect right :) I could endure a lot of suffering if I knew that concern to be taken care of.

Re: A four year plan for async Rust

#118

Post by dymk »

wavemode wrote: post #108
dymk wrote: post #18

Earlier quoted context omitted.

> However, if a library uses async, you have little choice but to make your whole project async. This isn't true. I'm writing an application right now that is mostly sync, but has a small amount of async code in it. It's easy to spin up a tokio runtime which can run inline on the current thread. Then use it to evaluate a Future. tokio::runtime::Builder::new_current_thread().enable_all().build().unwrap().block_on(asyn…

The complexity of this code snippet almost seems satirical (though I do get the point you're making, and agree with you).

On one hand, I agree that on the surface, this looks complex, if you don't read it.

But on the other hand, just read the code. It's not complex.

You drill down into a tokio namespace. You make a builder object. You unwrap it. This is idiomatic Rust. It's verbose, but explicit is better than vague. There's no conditional logic. There's no weird type-fu. No macros. There's not even any parameters to supply, other than the Future to block on.

It's trivial to write a wrapper to go from chained methods a helper call.

Re: A four year plan for async Rust

#119

Post by tuetuopay »

devit wrote: post #65

For some reason the Rust project seems to be plagued by glacial development speed, with features taking years and years to be stabilized after design and often even after initial implementation. Not sure why, progress used to be way faster years ago. For example, this "four year plan" should be implemented in 6 months at most, not 4 years. And the "long-term features" that "should be considered carefully, could not b…

> Not sure why, progress used to be way faster years ago.

Yes, and the language was qualified as unstable for evolving so quickly. Move fast and people complain, move slow and people complain. They lose both ways.

I find the development cycle to be quite good: they ship features and improvements and refinement, and I don't need to rewrite my codebase every three months because something subtly broke.

Re: A four year plan for async Rust

#120

Post by littlestymaar »

couchand wrote: post #9
littlestymaar wrote: post #4

Earlier quoted context omitted.

> However, if a library uses async, you have little choice but to make your whole project async. This adds to its horrible reputation. No. This is how yo do: you look what executor your dependency is using (most likely tokio) you add it to your cargo.toml (at zero cost, since it's already there in your dep) and then you wrap the async library calls in `block_on` and call it a day. You don't need to change a single ot…

You breeze over the dependency weight by abusing "zero cost" to mean "sunk cost". They're not the same!

They are. If you're using a dependency you're using your dependency dependencies, there's no way around it.

If it matters to you, you don't have the same priority as your dependency's author anyway and probably shouldn't be using it in the first place, and it has nothing to do with async.

Post reply on HN