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

181–190 of 499 posts

Re: Why asynchronous Rust doesn't work

#181

Post by ilammy »

zelly wrote: post #167
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…

Why did polling have to be baked into the language? Seems bizarre for a supposedly portable language to assume the functionality of an OS feature which could change in the future. Meanwhile C and C++ can easily adopt any async system call style because it made no assumptions in the standards about how that would be done. Rust also didn't solve the colored functions problem. Most people think that's an impossible prob…

> people also thought garbage collection was impossible in a systems language until Rust solved it

Only if you understand "garbage collection" in a narrow sense of memory safety, no explicit free() calls, a relatively readable syntax for passing objects around, and acceptable amount of unused memory. This comes with a non-negligible amount of small text for Rust when compared to garbage-collected languages.

Re: Why asynchronous Rust doesn't work

#182

Post by gpderetta »

varajelle wrote: post #176

Can we please stop using this "color" argument to Rust? The original colouring article was about JavaScript, a dynamically typed language. But rust is a statically typed language, and in a sense, the type is the colour. You can't return an error from a function that does not return a Result . And most people agree it is a great thing over dynamic/implicit exceptions. Declaring a function just changes the return type…

The color problem matters for static languages as much as for dynamic languages.

The essence of the problem is whether you can turn internal iterators into external ones without rewriting them. If you can't then your language has function colors.

Re: Why asynchronous Rust doesn't work

#183

Post by saurik »

newpavlov wrote: post #87
vlovich123 wrote: post #54

Earlier quoted context omitted.

Since you clearly have expertise, I'm curious if you might provide some insight into what would roughly be different in an async completion-based model & why that might be at a fundamental odds with the event-based one? Like is it an incompatibility with the runtime or does it change the actual semantics of async/await in a fundamental way to the point where you can't just swap out the runtime & reuse existing async…

It's certainly possible to pave over the difference between models to a certain extent, but the resulting solution will not be zero-cost. Yes, there is a fundamental difference between those models (otherwise we would not have two separate models). In a poll-based model interactions between task and runtime look roughly like this: - task to runtime: I want to read data on this file descriptor. - runtime: FD is ready,…

FWIW, I'd bet almost anything that this problem isn't solvable in any general way without linear types, at which point I bet it would be a somewhat easy modification to what Rust has already implemented. (Most of my development for a long time now has been in C++ using co_await with I/O completion and essentially all of the issues I run into--including the things analogous to "async Drop", which I would argue is actually the same problem as being able to drop a task itself--are solvable using linear types, and any other solutions feel like they would be one-off hacks.) Now, the problem is that the Rust people seem to be against linear types (and no one else is even considering them), so I'm pretty much resigned that I'm going to have to develop my own language at some point (and see no reason to go too deep into Rust in the mean time) :/.

Re: Why asynchronous Rust doesn't work

#184

Post by valand »

fulafel wrote: post #179
Cyph0n wrote: post #60

Earlier quoted context omitted.

Yes, there was: the function was calling the passed in closure from a different thread. It is just one thread that’s actually appending to the Vec, but it’s still a multi-threaded example.

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

Re: Why asynchronous Rust doesn't work

#185

Post by bullen »

I'll repeat this until my karma is zero: Erlang, Rust and Go have simple memory models and cannot do Joint (on the same memory) Parallelism efficiently.

They are only fragmenting development.

In my opinion there are only two programming languages worth mastering: C+ (C syntax compiled with cl/g++) on client and Java SE (8u181) on server. That said C++ (namespaces/string/stream) and JavaScript (HTML5) can be useful for client/web.

All other languages are completely garbage! Not only do they have huge opportunity cost, but they make it harder for this civilization to be useful long term!

We have linux/windows and C/Java, instead of making another language in C, make something useful that is open-source instead!

Edit: Most downvoters here will be technology naive; they think everything gets better for eternity, but in reality everything hits it's peak at some point and electron processors and their OS/languages have now explored all viable avenues. Accept that and stop wasting time!

Re: Why asynchronous Rust doesn't work

#186

Post by filleduchaos »

fulafel wrote: post #179
Cyph0n wrote: post #60

Earlier quoted context omitted.

Yes, there was: the function was calling the passed in closure from a different thread. It is just one thread that’s actually appending to the Vec, but it’s still a multi-threaded example.

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…

The `do_work_and_then` function does spawn a thread, it's one of the first things established in the article.

Re: Why asynchronous Rust doesn't work

#187

Post by gher-shyu3i »

bullen wrote: post #185

I'll repeat this until my karma is zero: Erlang, Rust and Go have simple memory models and cannot do Joint (on the same memory) Parallelism efficiently. They are only fragmenting development. In my opinion there are only two programming languages worth mastering: C+ (C syntax compiled with cl/g++) on client and Java SE (8u181) on server. That said C++ (namespaces/string/stream) and JavaScript (HTML5) can be useful fo…

Why Java 8 as opposed to the latest JDK?

And what about C#? It's in a similar boat as Java.

Also, how is the Java memory model different from Go for this use case? They both allow mutation by sharing.

Re: Why asynchronous Rust doesn't work

#188

Post by [deleted] »

fulafel wrote: post #179
Cyph0n wrote: post #60

Earlier quoted context omitted.

Yes, there was: the function was calling the passed in closure from a different thread. It is just one thread that’s actually appending to the Vec, but it’s still a multi-threaded example.

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…

[deleted]

Re: Why asynchronous Rust doesn't work

#189

Post by ash »

the_duke wrote: post #80
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…

I agree that Rust async is currently in a somewhat awkward state. Don't get me wrong, it's usable and many projects use it to great effect. But there are a few important features like async trait methods (blocked by HKT), async closures, async drop, and (potentially) existential types, that seem to linger. The unresolved problems around Pin are the most worrying aspect. The ecosystem is somewhat fractured, partially…

Is there a good explanation on the difference between polling model and completion model? (not Rust-specific)

Re: Why asynchronous Rust doesn't work

#190

Post by [deleted] »

blazzy wrote: post #160
ironmagma wrote: post #89

Earlier quoted context omitted.

In a systems context, where performance and memory ostensibly matter, why wouldn’t you want to be made aware of those inefficiencies? Sure, Go hides all that, but as a result it’s also possible to have memory leaks and spend extra time/memory on dynamic dispatch without being (fully) aware of it.

In this example rust doesn't just make me aware of the tradeoffs. It almost feels like the language is actively standing in the way of making the trade offs I want to make. At least as the language is today. I think a bunch of upcoming features like unsized rvalues and async fns in traits will help.

[deleted]
Post reply on HN