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

Why asynchronous Rust doesn't work

theta.eu.org

Post reply on HN
Print view View original

211–220 of 499 posts

Re: Why asynchronous Rust doesn't work

#211

Post by ben0x539 »

newpavlov wrote: post #152
comex wrote: post #133

Earlier quoted context omitted.

> How is to so, if he explicitly writes: There's a difference between "we decided this 3 years ago" and "we rushed the decision". At this point, it's no longer possible to weigh the two models on a neutral scale, because changing the model would cause a huge amount of ecosystem churn. But that doesn't mean they weren't properly weighed in the first place. Regarding cyclicity… well, consider something like a task runn…

>There's a difference between "we decided this 3 years ago" and "we rushed the decision". As far as I understand the situation, the completion-based API simply was not on the table 3 years ago. io-uring was not a thing and there was a negligible interest in properly supporting IOCP. So when a viable alternative has appeared right before stabilization of the developed epoll-centric API, the 3 year old decision has not…

What happens if you drop the task between 1 and 2? Does dropping block until the cancellation of both tasks is complete?

Re: Why asynchronous Rust doesn't work

#212

Post by orthoxerox »

int_19h wrote: post #170
hctaw wrote: post #26

I don't think any of this is actually a reason why async rust doesn't work. The function color problem is a bit overblown, it hasn't broken nodejs yet either. Most code is sync, sync can call async and vice versa, and the ecosystem hasn't come tumbling down yet (since most Rust isn't whichever async application runtime for web apps is currently in vogue - its a systems language after all). Either way there are bigger…

> The function color problem is a bit overblown, it hasn't broken nodejs yet either. I agree; and I would also point at C#, which is the originator of the async/await syntax, and has had it for over 8 years now, with the ecosystem embracing it for most of that period. It works.

I've been waiting for an async Oracle ADO.NET driver for over 8 years now.

Re: Why asynchronous Rust doesn't work

#213

Post by orthoxerox »

sudeepj wrote: post #59
gwbas1c wrote: post #18

For a few months while I was between jobs, I decided to learn Rust. Because async code is supposed to be better than threaded code, I spent all my time trying to write async Rust. Big mistake! I never accomplished what I set out to accomplish. Most of my experience is in C#, where the difference between async and threaded code is mostly syntax sugar. (Until you get into the details.) (And async code makes writing UI…

I am guessing you are a point D/D' in the diagram [1] Although the diagram is for the Rust overall, I think something similar is true for async Rust. All I would say is hang in there. It gets better (from my experience). Rust is not something you can code along as you think. There is a bit a of upfront thinking what the data-structures & data-flow look like. At present, I can know in advance without writing code whet…

> Rust is not something you can code along as you think.

This is my biggest gripe with Rust. I want to write code that produces the right result first and make it safe later.

Re: Why asynchronous Rust doesn't work

#214

Post by scoutt »

adamch wrote: post #132

This is pretty overblown. I write async rust every day for my job, just fine, with no real problems. Probably because I'm consuming other libraries, I'm not trying to write my own. I use well-tested libraries like Actix-Web or occasionally Tokio. I've migrated multiple projects from futures to async/await once the syntax came out. ' The problems the author is describing might apply more to library authors, but for th…

> The problems the author is describing might apply more to library authors

I don't know much about Rust, but I found the examples in the article kind of simple. As far as I can see, the author is trying to spawn a new thread and share an object between the main thread and the new one. It's seems like an everyday paradigm.

Perhaps the problems arise when passing complex objects instead of native types (i.e. u32).

Re: Why asynchronous Rust doesn't work

#215

Post by zesterer »

The article title is clickbaity as heck, but the content is (reasonably) sound.

A better title would be 'Rust's async model has some flaws that are a product of its desire to ensure safety and make the true cost of certain operations visible'.

Of course, such a title would never hit the front page of hacker news.

The problems the author identifies are real, but they're not unique to Rust. You can get around them fairly easily with dynamic dispatch, which is what basically every competitor to Rust's async model does by default.

I agree with the author that Rust's use of async in the ecosystem is increasingly universal and it's starting to become a little problematic. As the author of Flume and a (soon to be released) concurrent hashmap implementation, I'm trying to work on adding primitives that successfully marry sync and async with one-another. There's no doubt that it's hard though, and function colouring is a problem.

Re: Why asynchronous Rust doesn't work

#216

Post by imtringued »

valand wrote: post #184
fulafel wrote: post #179

Earlier quoted context omitted.

Are we talking about the same example? struct Database { data: Vec } impl Database { fn store(&mut self, data: i32) { self.data.push(data); } } fn main() { let mut db = Database { data: vec![] }; do_work_and_then(|meaning_of_life| { println!("oh man, I found it: {}", meaning_of_life); db.store(meaning_of_life); }); // I'd read from `db` here if I really were making a web server. // But that's beside the point, so I'm…

` fn do_work_and_then(func: fn(i32)) { thread::spawn(move || { // Figuring out the meaning of life... thread::sleep_ms(1000); // gee, this takes time to do... // ah, that's it! let result: i32 = 42; // let's call the `func` and tell it the good news... func(result) }); } ` you missed a snippet, a thread is spawned. edit: formatting

If for some magic reason thread::sleep_ms(1000) takes longer than 2000ms the main function would reach its end and deallocate the closure that is about to get called. Basically use after free.

Re: Why asynchronous Rust doesn't work

#217

Post by imtringued »

zelly wrote: post #171
lmm wrote: post #13

Async isn't really the problem - the same issue pops up with error handling, with resource management, with anything where you want to pass functions around. The real problem is that Rust's ownership semantics and limited abstractions mean it doesn't really have first-class functions: there are three different function types and the language lacks the power to abstract over them, so you can't generally take an expres…

Rust programs can theoretically be fast, but most of the ones I've used are slow. I tried two high profile implementations of the same type of software, one in Rust and one in Java. The Java one was faster and used less memory. Rust programmers tend to do all kinds of little hacks here and there to make the borrow checker happy. It can add up. The borrow checker is perfectly happy when you copy everything. Rust is be…

I can't reduce JVM memory usage below 100MB. It simply is impossible. Meanwhile with rust I can easily write 20 times more memory efficient applications.

Re: Why asynchronous Rust doesn't work

#218

Post by tick_tock_tick »

jcelerier wrote: post #191
CodeArtisan wrote: post #72

Earlier quoted context omitted.

Note that C++ offers async as a library and not as a programming language feature which Bjarne Stroustrup is strongly against. He talk more about why in "The Design and Evolution of C++" but i don't have the material at hand. As far as i remember, his main argument was that there is no concurrency model to fit them all and thus it doesn't worth to add new syntax and semantics for a specific model except to make the P…

> Note that C++ offers async as a library and not as a programming language feature which Bjarne Stroustrup is strongly against. https://www.modernescpp.com/index.php/c-20-coroutines-the-fi...

coroutines themselves have nothing todo with async/await.

Re: Why asynchronous Rust doesn't work

#219

Post by scoutt »

I started recently learning Rust, and a thing I don't understand is why they decided that threads have to be done this way and not simply wrapping what is available in the OS (I know that at some point, at the core, a Rust thread is the same thing I create with pthread_create).

Like, in both Windows and Linux, threads exist as a callback function (pointer to function) with its own stack, in which a void* parameter is passed. Can this be done in Rust? Can multithreading be done without closures?

Re: Why asynchronous Rust doesn't work

#220

Post by johnnycerberus »

newpavlov wrote: post #37

A bigger problem in my opinion is that Rust has chosen to follow the poll-based model (you can say that it was effectively designed around epoll), while the completion-based one (e.g. io-uring and IOCP) with high probability will be the way of doing async in future (especially in the light of Spectre and Meltdown). Instead of carefully weighing advantages and disadvantages of both models, the decision was effectively…

In all this time, maestro Andrei Alexandrescu was right when he said Rust feels like it "skipped leg day" when it comes to concurrency and metaprogramming capabilities. Tim Sweeney was complaining about similar things, saying about Rust that is one step forward, one step backward. These problems will be evident at a later time, when it will be already too late. I will continue experimenting with Rust, but Zig seems to have some great things going on, especially the colourless functions and the comptime thingy. Its safety story does not dissapoint also, even if it is not at Rust's level of guarantees.
Post reply on HN