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

21–30 of 236 posts

Re: A four year plan for async Rust

#21

Post by CyberDildonics »

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.

You are absolutely right.

Integrating 'async' into a language is not a good approach to concurrency. If you want to run a single function on a different thread it can work. If you want something to run after that, that can work out.

Once you go beyond that, you are building a graph with very crude tools. Then you have lots of problems, including how you handle packaging dependencies when something you want to run depends on data coming from multiple other async sources.

Treating this as a language issue and not a library and tools issue is a huge mistake. Another reason is exactly what you outlined - libraries getting infected with a languages half baked concurrency solution instead of doing what they are supposed to while the user can fit them in where they want.

What actually works is graphs that handle dependencies and data structures for synchronization, but ultimately those need to be done well too.

Re: A four year plan for async Rust

#22

Post by withoutboats3 »

the__alchemist wrote: post #19
withoutboats3 wrote: post #13

Earlier quoted context omitted.

What Rust libraries use async that you think should not? I can think of one, but otherwise every library I've encountered uses async because its intended for the kind of networking service that benefits from using non-blocking IO.

> the kind of ... service that benefits from using non-blocking IO. Async, in the sense from the article, and non-blocking aren't synonyms. Not using Async doesn't imply blocking.

What Rust libraries use non-blocking IO without using async syntax? I don't know of any. This interpretation of the request is new to me: I've exclusively heard complaints about libraries using async from people who want to use blocking IO.

(Also, in case it isn't obvious: I wrote the article in question.)

Re: A four year plan for async Rust

#23

Post by bobbylarrybobby »

andrewstuart wrote: post #14

I thought async and await were kind of logical builds on top of generators but this is saying rust has no generators. That’s how it works in javascript and as a commenter mentions in Python too, right?

They are logical builds on top of coroutines, as are generators. There is a generator initiative in the works, but it does seem odd that async exists and generators don’t given that the “pausable state machine” nature of them is so similar.

Re: A four year plan for async Rust

#24

Post by dymk »

echelon wrote: post #17
seanw444 wrote: post #10

Earlier quoted context omitted.

The point can be made equally well without the elitist condescension.

It's not elitist. I'm sick of people perpetuating this about the Rust ecosystem. It's not a month that goes by that there isn't some article badmouthing the language and its features. Stop it. We want our language to gain support in enterprise so we can get paid to write it as our day job. These articles and negative comments are not helping.

This article is by a Rust contributor. I'm sure they want to see Rust be more widely adopted as well. Async is pretty great, but it's not perfect, and in some situations its shortcomings cannot be worked around easily.

Re: A four year plan for async Rust

#25

Post by pdw »

pm215 wrote: post #12
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…

This was not my experience. I had a working program that used the reqwest crate for a very basic synchronous-is-fine "just give me the contents of this web page" function. When I tried upgrading it to a newer reqwest that had decided async was the way to go, I found that that nice easy to use synchronous function had simply disappeared entirely, and I seemed to have to figure out async in order to use the library now…

For reqwest, using the feature "blocking" will enable the reqwest::blocking API.

Re: A four year plan for async Rust

#26

Post by potatochup »

andrewstuart wrote: post #14

I thought async and await were kind of logical builds on top of generators but this is saying rust has no generators. That’s how it works in javascript and as a commenter mentions in Python too, right?

That's true for implementations like python async, but rust operates a bit differently (mostly to avoid allocations across await points). The author of this article has some other very good posts about it.

Re: A four year plan for async Rust

#27

Post by __s »

andrewstuart wrote: post #14

I thought async and await were kind of logical builds on top of generators but this is saying rust has no generators. That’s how it works in javascript and as a commenter mentions in Python too, right?

They're intertwined, but generators have yet to stabilize https://doc.rust-lang.org/beta/unstable-book/language-featur...

Re: A four year plan for async Rust

#28

Post by vlovich123 »

Adding Move and deprecating pin/unpin would be a huge ergonomic improvement I think. I also think the Rust project should consider “out-of-band” editions if they can deliver big features like that sooner rather than waiting until 2027.

Re: A four year plan for async Rust

#29

Post by theossuary »

pm215 wrote: post #12
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…

This was not my experience. I had a working program that used the reqwest crate for a very basic synchronous-is-fine "just give me the contents of this web page" function. When I tried upgrading it to a newer reqwest that had decided async was the way to go, I found that that nice easy to use synchronous function had simply disappeared entirely, and I seemed to have to figure out async in order to use the library now…

Reqwest still has a block client available [1]. I assume you upgraded across a major version, and are mad that there were backwards breaking changes? Don't do that if you don't want to update your code to account for changes in the dependency.

[1]: https://docs.rs/reqwest/latest/reqwest/blocking/index.html

Re: A four year plan for async Rust

#30

Post by killercup »

dymk wrote: post #18
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.

> 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…

Because this code block looks quite complex, I want to add that it can also be just

    smol::block_on(async {
        println!("I'm async!");
    });
(I thought tokio had a helper like this too but could only find `tokio::runtime::Runtime::new().unwrap().block_on(async { println!("I'm async!"); });`.)
Post reply on HN