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

231–240 of 499 posts

Re: Why asynchronous Rust doesn't work

#231

Post by alexisread »

stormbrew wrote: post #131
comex wrote: post #110

Earlier quoted context omitted.

There's a workaround, but it's unidiomatic, requires more traits, and requires inefficient copying of data if you want to adapt from one to the other. However, I wouldn't call this a problem with a polling-based model. At least part of the goal here must be to avoid allocations and reference counting. If you don't care about that, then the design could have been to 'just' pass around atomically-reference-counted buff…

Wouldn't a more 'correct' implementation be moving the buffer into the thing that initiates the future (and thus, abstractly, into the future), rather than refcounting? At least with IOCP you aren't really supposed to even touch the memory region given to the completion port until it's signaled completion iirc. Ie. to me, an implementation of read() that would work for a completion model could be basically: async rea…

I'm not a rust expert, so I'm not sure how close this proposal is to Composita

http://concurrency.ch/Content/publications/Blaeser_Component...

Essentially each component has a buffered interface (an interface message queue), which static analysis sizes at compile time. This buffer can act as a daemon, ref counter, offline dropbox, cache, cancellation check, and can probably help with cycle checking.

Is this the sort of model which would be useful here?

Re: Why asynchronous Rust doesn't work

#232

Post by sai_c »

roca wrote: post #224
sai_c wrote: post #148

Earlier quoted context omitted.

Disclaimer: I've only dabbled in Rust from time to time, but have not written anything serious with it. Those kind of comments are not based on looking at Rust's features on a theoretical level. It's more from the viewpoint of "How hard is it to get something (correctly) done". Those impressions are mostly formed either from using the language and failing (or having severe difficulties) to solve a given problem, or b…

It is hard to stop people perceiving Rust as over-complex if they are motivated to perceive it as over-complex.

Yes, indeed. Yet, this is the problem to solve.

I don't know if you are using Rust, but what would you say, why is that? Where does that motivation come from?

Re: Why asynchronous Rust doesn't work

#233

Post by thu2111 »

nynx wrote: post #10
spamizbad wrote: post #7

I'm surprised Rust went with a Scala-inspired async/await considering it wasn't well-liked outside of PLT enthusiasts. JavaScript adopted it as I don't think you could bolt any other type of sugar on top of the event loop in browsers... but Rust shouldn't suffer from such baggage.

What's an alternative to async/await that's explicit about runtime costs?

How explicit do you want?

The loom model is VM managed thread stacks with user space context switching. The costs are all quantifiable and a suspended "virtual" thread uses memory directly proportional to the amount of stuff on the stack, same as any coro implementation. However there is no async/await or coloured functions. The VM just makes threads super cheap

Re: Why asynchronous Rust doesn't work

#234

Post by the_mitsuhiko »

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 will agree that Rust programs can be surprisingly slow. That said, in most cases I have experienced this it came down to very simple to detect situations that are usually resolved by enclosing some large things in smart pointers.

I consider this a plus because that's a pretty simple change.

Re: Why asynchronous Rust doesn't work

#236

Post by scoutt »

rcxdude wrote: post #225
scoutt wrote: post #219

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

What you've described with pthread_create is basically a closure, just implemented within the limitations of C and like many things in C, wildly unsafe. You can of course interact with the underlying implementation if you want (Rust is quite capable of calling into libc directly), but then you're responsible for ensuring safety. Rust provides a safe wrapper over this with a closure which is generally easier to use an…

Thanks.

> a closure which is generally easier to use

I didn't experimented much with closures so I can't discuss about simplicity yet (but the article explains that "Closures can be pretty radioactive").

> within the limitations of C

Threads are exposed like that by the operating system. The C implementation is just a way to have access to what the operating system exposes, so I think it should be more like a limitation of the operating system?

Re: Why asynchronous Rust doesn't work

#237

Post by pas »

zamalek wrote: post #193
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…

> A bigger problem in my opinion is that Rust has chosen to follow the poll-based model This is an inaccurate simplification that, admittedly, their own literature has perpetuated. Rust uses informed polling: the resource can wake the scheduler at any time and tell it to poll. When this occurs it is virtually identical to completion-based async (sans some small implementation details). What informed polling brings to…

Could you explain what is informed and stateless informed polling? I haven't really found anything on the web. Thanks!

Re: Why asynchronous Rust doesn't work

#238

Post by scoutt »

dthul wrote: post #226
scoutt wrote: post #219

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

Note that you don't need a closure in Rust to start a thread. You can just specify a function to be called (because functions implement FnOnce).

Thanks. My question emerged from the fact that all the Rust threads examples I see are in the closure form || {}.

Re: Why asynchronous Rust doesn't work

#239

Post by [deleted] »

doteka wrote: post #204
zelly wrote: post #171

Earlier quoted context omitted.

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…

Interesting, could you elaborate on this software and what it does? At work, we also offer two backends for the same kind of functionality. One is the industry standard Java implementation, one is a homegrown Rust implementation. We find that for this usecase (essentially text processing, string manipulation and statistical algorithms), the rust version is much faster while using less memory. However, it is not as fe…

[deleted]

Re: Why asynchronous Rust doesn't work

#240

Post by lutoma »

noncoml wrote: post #39

> And, as I said at the start, that makes me kinda sad, because I do actually like Rust. I think that’s the most important part of the article. People like Rust but it’s becoming more complex than C++. But unlike C++ it’s more difficult to pick and choose what you use. Rust’s death will be one by thousand cuts. “I really like the language but can’t justify all that complexity in my new small and simpke project” is wh…

As a C developer who has never really used C++ or Rust I sort of agree. Looking at Rust introductory guides I increasingly get the same feeling as looking at C++ things, where there's just _too much_ of everything. I know it's a subjective feeling that is probably unfair to the language, but it's still the impression I get.

I'm confident if I actually put in the work to learn Rust I would end up liking it and I plan on doing that at some point, but it certainly doesn't help my motivation.

Post reply on HN