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

131–140 of 236 posts

Re: A four year plan for async Rust

#131

Post by untitaker_ »

no_wizard wrote: post #105
untitaker_ wrote: post #63

Earlier quoted context omitted.

This is a popular sentiment that I share to some degree, but I really wish we could just move on from this discussion. It happens in every post that is even just vaguely about Rust or async. It's like reading complaints about the GIL on a post that is loosely connected to Python! At some point it just gets boring. "I will forever argue that [...]" -- Why are you forever arguing? "I feel like I am alone with [...]" --…

to be honest, HN is one of the few venues where I think someone who is core to a project might actually see what is said about a language. I've tried getting involved in mailing lists and stuff, but they aren't often as welcoming to this discussion as one might assume. My hope is that by raising these things on HN, someone will take notice in a different way and at least start considering / revisiting alternatives

All of this would be correct in an alternative reality where everybody in the Rust community, including every person ever involved in the language's evolvement isn't aware of these complaints.

Re: A four year plan for async Rust

#132

Post by littlestymaar »

tuetuopay wrote: post #111
nextaccountic wrote: post #71

Earlier quoted context omitted.

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).

Only for file access, which wasn't supported by async on Linux until io-uring.

Re: A four year plan for async Rust

#133

Post by devit »

steveklabnik wrote: post #99
explodingwaffle wrote: post #92

Tangential to some comments here: Why does the standard library not have block_on?

As far as I know, the proposal to add one was determined to need an RFC: https://github.com/rust-lang/rust/pull/65875

Another instance of a trivial and obvious feature that can only really be designed one way that is not implemented 4 years after initial proposal.

Re: A four year plan for async Rust

#134

Post by cmollis »

insanitybit wrote: post #60
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…

IO shouldn't be going to one thread, as far as I know. Blocking IO would go to a threadpool. But you can just `block_on` your futures if you want and not think about it at all.

+1

Re: A four year plan for async Rust

#135

Post by insanitybit »

TBH I think that, for the most part, I will only benefit from a few of these - mostly in terms of sugar. I routinely have positive experiences with Async rust and basically never have negative experiences/ issues that crop up because of it. In 3 years of writing Rust full time I had one async problem one time - I accidentally was causing an infinite select! loop in a tonic server, so the server would hang. Not really a big deal for 3 years of async work. I could have done the same thing in sync code just as easily tbh.

I also don’t think that async-drop as quite as necessary or desirable as it may seem. I really wanted it at one point and then I realized that it’s just too tricky. It reminds me of how File calls sync_all on drop but ignores the error - ultimately, “drop” is just a really tricky place for anything complex. I’d rather see a linear type, like:

    struct LinearFile {
        fn close(self) -> Result { self.sync_all(); File { inner: self.inner } }
    }
Where Linear can’t be implicitly drop’d, you have to .close() it, get a File, and File can be dropped. Hand wavy and not necessarily a good implementation but hopefully this is getting the point across. This would be preferable to shoving more into a drop impl when drop is such a constrained interface.

Or maybe add a try_drop(&mut self) that will run implicity but also ? implicity. I don’t know.

I guess the point is that I’m not sure an async drop can ever be worth it.

TBH I feel like ~30% of people's complaints about async are solved by:

a) Encouraging a sync + async API in libraries

b) Adding `block_on` to the stdlib, which will help with (a)

People mostly seem to care (and imo this is stupid but whatever) about using async in sync contexts when they don't want to, and they don't seem to know that you can just block.

Re: A four year plan for async Rust

#136

Post by mplanchard »

This is a really interesting post, and it's predictable if disappointing the degree to which the comments are rehashing all of the same tired arguments about async rust.

I for one am pretty satisfied with async rust, and I'm excited for the stabilization of async-trait. I'd love to see some of the improvements discussed in this post come to fruition. Generators in particular are something I've found myself wanting on multiple occasions, because writing custom Iterators is relatively complex.

The point about return-type notation is really interesting. Once async-trait is stabilized, we'll probably go through and rip out as much usage of the `async-trait` macro as possible, so I'll be curious to see how often we run into the issue described there. I also really like the idea highlighted in the blog post of adding async sugar to function closure types as part of expanding the support for async closures, e.g.:

    where F: async FnOnce() -> T
    // rather than
    where F: FnOnce() -> impl Future
Personally, the lack of good support for async in closures remains one of my only issues with async, just because we often write code in a more "functional" style, and whenever we're dealing with complex async stuff we often wind up having to drop out of that.

Re: A four year plan for async Rust

#137

Post by samus »

jayd16 wrote: post #123
samus wrote: post #112

Earlier quoted context omitted.

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

Structured concurrency looks good but is it really better than async syntax?

I have to admit that async syntax has a certain charm, as it has deep connections to iterators. (I have to program with Unity for my master thesis). But Structured Concurrency leverages well-known blocking syntax that doesn't require further explanation. It's not even specific to virtual threads.

Re: A four year plan for async Rust

#138

Post by withoutboats3 »

munificent wrote: post #85

> AsyncIterator and async generators For what it's worth, Dart has had synchronous and asynchronous generators (including `await for` statements) for as long as its had async/await. They are neat features. I've definitely written code using synchronous generators that would be hard to manually transform into a custom Iterable implementation. But they add a large amount of complexity to the language implementations an…

A big difference between Rust and other languages like Dart is that our async/await is based on the same sort of coroutine transform as generators would be, rather than continuations, so its a lot less additional complexity to add generators compared to another language that has both async/await based on continuations and generators based on coroutines.

Re: A four year plan for async Rust

#139

Post by brabel »

munificent wrote: post #85

> AsyncIterator and async generators For what it's worth, Dart has had synchronous and asynchronous generators (including `await for` statements) for as long as its had async/await. They are neat features. I've definitely written code using synchronous generators that would be hard to manually transform into a custom Iterable implementation. But they add a large amount of complexity to the language implementations an…

For what it's worth: thanks to Dart's async/await and async* and sync* , I find it incredibly easy to write performant, clean concurrent code in Dart. I've implemented an application (very IO heavy, highly concurrent) that is half Dart, half Java (for reasons) and the async code in Java is atrocious, while the Dart code is just beautiful.

Re: A four year plan for async Rust

#140

Post by LtWorf »

littlestymaar wrote: post #8
wongarsu wrote: post #7

Earlier quoted context omitted.

Another viable strategy is to start a single-threaded tokio executor and treat it like another thread that you communicate with over (flume) channels.

Yes this works too. People complaining about async being contaminant are often so much prejudiced against it that that haven't even tried to understand the basics.

Having written an async library (as in, the non-blocking stuff and state, that to the caller looks like async)... Understanding it isn't the easiest.
Post reply on HN