Live data from Hacker News

Why asynchronous Rust doesn't work

eta.st

1–10 of 305 posts

Re: Why asynchronous Rust doesn't work

#7
The article glosses over async Rust and is mostly a rant about how closures are difficult in Rust.

Most of the difficulty comes from Rust not having a GC yet wishing to keep track of object lifetimes precisely: a GC'ed language needs no distinction between an ordinary function pointer and a closure that captures the environment. But Rust being a low-level systems language chose not to have a GC.

Another popular language also doesn't have GC, makes distinctions between ordinary function pointers and closures, and its closures are unnameable types; that language is C++. But instead of using template for closures everywhere (like the STL), you can optionally use std::function, a type-erased closure type, which would in principle be similar to Box R> in Rust. But such a type doesn't really mention the lifetimes of whatever it captures, so in practice it doesn't work well in Rust (though std::function works well in C++ because the C++ doesn't care about lifetimes).

With that in mind, I see this article as not understanding the goals and tradeoffs of Rust. The author would be happier writing in a higher-level language than Rust.

Re: Why asynchronous Rust doesn't work

#9
The author spends the majority of the post saying how synchronous Rust doesn't work. The main problem? Closures have to be passed as traits. And they either don't know about the `f: impl Fn(i32)` syntax or refuse to use it for some reason.

Then the last paragraph just say "Oh and asynchronous Rust is even worse."

Post reply on HN