Why asynchronous Rust doesn't work
1–10 of 305 posts
Re: Why asynchronous Rust doesn't work
#2Re: Why asynchronous Rust doesn't work
#3Re: Why asynchronous Rust doesn't work
#4Re: Why asynchronous Rust doesn't work
#5I guess I’ll have to become an expert to find my disappointment.
Re: Why asynchronous Rust doesn't work
#6Re: Why asynchronous Rust doesn't work
#7Most 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
#8offtopic, but i've had yet to see a website with dedicated "Name & pronoun information" page
Re: Why asynchronous Rust doesn't work
#9Then the last paragraph just say "Oh and asynchronous Rust is even worse."
Re: Why asynchronous Rust doesn't work
#10I’m not an expert by async rust seems to work pretty well to me. I guess I’ll have to become an expert to find my disappointment.