Why asynchronous Rust doesn't work • Hacker News Board

Re: Why asynchronous Rust doesn't work

#301

Post by kobebrookskC3 » Mon, Nov 15, 2021, 3:20 PM UTC

dnautics wrote: post #266

pcwalton wrote: post #229

Earlier quoted context omitted.

Not possible for the same reasons why just adding a borrow checker to C++ isn't possible. Mostly this comes down to incompatibility with existing code. Zig is just not memory safe, and the only solution would be to add a GC.

This is a very bad take. By your argument there's no reason why sel3 should exist, which is written in C and safer than rust.

feel free to keep writing c, as long as you prove all your code memory safe. i'm gonna take a stab and say writing rust is easier.

Re: Why asynchronous Rust doesn't work

#302

Post by skohan » Mon, Nov 15, 2021, 5:00 PM UTC

surajrmal wrote: post #238

pcwalton wrote: post #229

Earlier quoted context omitted.

Not possible for the same reasons why just adding a borrow checker to C++ isn't possible. Mostly this comes down to incompatibility with existing code. Zig is just not memory safe, and the only solution would be to add a GC.

If you don't consider Swift style Automatic Reference Counting a GC, then there is another option.

The problem with ARC in swift is that it’s always atomic. This is fast enough on ARM, but on x86 it’s really slow

Re: Why asynchronous Rust doesn't work

#303

Post by karmakaze » Tue, Nov 16, 2021, 3:20 AM UTC

brabel wrote: post #205

karmakaze wrote: post #150

Earlier quoted context omitted.

I don't use Rust but was curious if this was a real or imagined problem--it seems to be the latter. Two points: 1. the example could have made a pure callback function that takes a mut& db param and pass thaf param to the 'do'er function. Why is this not required anyway? i.e. How does Rust know/decide who owns the mut& db if both the closure and the function that creates the closure can reference it? 2. as mentioned,…

> the example could have made a pure callback function that takes a mut& db param and pass thaf param to the 'do'er function. No. If you did that, you could only pass functions in that took the db as a closure argument, nothing else... you're thinking about this example only, and forgetting the problem is with the general case of capturing whatever is needed for the callback to work.

Ok, so then the problem statement is how to do dependency injection of lifecycle references into closures. This is specific and asking quite a lot of a single entrypoint function. The closure 'at some point' (either at the end, or coordinated give then get calls) would have to transfer ownership. At this point you'd likely be better off making an interface and not a single entry/exit closure.

Re: Why asynchronous Rust doesn't work

#304

Post by __s » Tue, Nov 16, 2021, 2:37 PM UTC

secondcoming wrote: post #270

__s wrote: post #187

Earlier quoted context omitted.

I've found async to be straight forward anytime I've used it. Promise#then is equivalent to callbacks async/await often requires very little changes compared to synchronous code, whereas reworking a program into callbacks is much more impactful. & the async/await compilation process tends to produce better performance in addition to this. My first async/await work was a few years ago to increase a data importer's per…

> the caller fires it off without a ticket to wait on the result Exactly! Making a thread block waiting for a result isn't true async in my book. It doesn't matter that the result is going to come from another thread. Futures/Promises make you block a thread.

That's why async/await is about having an event loop driving a state machine so that you aren't blocking a thread, you're having a state machine wait on a result

Performance numbers don't care what's in your book

Re: Why asynchronous Rust doesn't work

#305

Post by jffry » Wed, Nov 17, 2021, 2:49 PM UTC

gerbilly wrote: post #173

jffry wrote: post #166

Earlier quoted context omitted.

I can't speak authoritatively, but I can think of some good reasons you might not want to automatically and implicitly await every invocation of an async function. As designed, calling an async function just returns a Promise, and any Promise can be awaited. This means that I can pass that Promise around, and it also means I can use a Promise-based library (of which there are many) easily from within my async code. A…

All right more flexibility, good point. However what languages are you thinking of when talking about this? I've done a lot of Java programming where we commonly use threads and thread pools, although there are non blocking libraries out there too. Is it common these days to mix promises and threads (waiting on a promise in a thread), or is what I just said nonsense?

Ah. I was coming at this from the perspective of "why would it be implemented this way in JavaScript specifically", as you'd asked about JS land.

More generally, I don't have a good enough overview of programming language trends to speak to how that fits in with other languages' approaches to async.

> Is it common these days to mix promises and threads

I'm not sure. That probably depends a lot on the evolutionary history of a given language and its library ecosystem.

I could see it being done to mix those two things in a world where you are trying to glue together two libraries (or legacy internal modules) built in different ways, and the alternatives either don't exist or are more onerous.