Rust acolytes need to come to terms with the fact that if they want Rust to be the next C++, it's going to be the next C++. Heck, even C++ async is simpler. Anyway, who needs a package manager when you've got a package manager?
Local async executors and why they should be the default
61–70 of 327 posts
Re: Local async executors and why they should be the default
#62Rust acolytes need to come to terms with the fact that if they want Rust to be the next C++, it's going to be the next C++. Heck, even C++ async is simpler. Anyway, who needs a package manager when you've got a package manager?
>who needs a package manager when you've got a package manager
That flew over my head; could you explain?
Re: Local async executors and why they should be the default
#63Earlier quoted context omitted.
Anecdotal evidence, but many large rust async code bases perform significantly better if you are using a single threaded runtime vs. a multithreaded runtime. Here is an issue for the quinn crate that implements QUIC: https://github.com/quinn-rs/quinn/issues/1433 We have had very similar experiences when developing https://github.com/n0-computer/iroh And this is with quinn still carrying around the synchronization pri…
> Last but not least - often making futures Send requires you to box your futures. Send and lifetimes just does not play well together. Do something like this: You should ~never need to box your futures to make them Send. You do sometimes need to box them to make them Unpin, but most of the time this is a tradeoff where it's possible to find a way to avoid moving them instead. It seems like these screeds (both the OP…
Look at the extremely popular async_trait macro crate: https://crates.io/crates/async-trait .
What it does under the hood is to box everything. See https://github.com/dtolnay/async-trait#explanation
You would think that you should be able to desugar async traits to something that does not need to box. But this is not possible with stable rust.
There is an effort to make this possible. See for example this discussion here: https://blog.rust-lang.org/inside-rust/2022/11/17/async-fn-i...
Initially it was thought that Send bounds would not be needed, but community feedback strongly suggests that Send is indeed needed.
https://blog.rust-lang.org/inside-rust/2023/05/03/stabilizin...
All this is a real problem, and not just a "you are holding it wrong" problem.
Edit: here is the - still open - issue about higher-ranked lifetime errors: https://github.com/rust-lang/rust/issues/102211
Re: Local async executors and why they should be the default
#64Rust acolytes need to come to terms with the fact that if they want Rust to be the next C++, it's going to be the next C++. Heck, even C++ async is simpler. Anyway, who needs a package manager when you've got a package manager?
>who needs a package manager when you've got a package manager That flew over my head; could you explain?
I think the idea is that being the next C++ means being just as hard to write as C++, and then saying "why do we need the next C++ when we already have C++?", but I'm curious if my interpretation is right :)
Re: Local async executors and why they should be the default
#65Suggesting that single threaded concurrency is the right way to do it when building tooling is completely asinine.
Re: Local async executors and why they should be the default
#66Rust acolytes need to come to terms with the fact that if they want Rust to be the next C++, it's going to be the next C++. Heck, even C++ async is simpler. Anyway, who needs a package manager when you've got a package manager?
>who needs a package manager when you've got a package manager That flew over my head; could you explain?
Lots of languages have tools which reimplement package management specifically for their libraries, and this pattern has become fairly "normal", but the traditional norm is to access and provide libraries as system packages via the system's package manager. With that in mind, things like Cargo become less magical and more redundant with other tools like Make.
Re: Local async executors and why they should be the default
#67Earlier quoted context omitted.
>who needs a package manager when you've got a package manager That flew over my head; could you explain?
I think the idea is that being the next C++ means being just as hard to write as C++, and then saying "why do we need the next C++ when we already have C++?", but I'm curious if my interpretation is right :)
Yes, the first part is what I was going for. Actually it is even worse than that, because C++ has a more limited syntax. Rust's syntax and semantics must support more features. This fundamentally limits its accessibility.
Re: Local async executors and why they should be the default
#68Multithreading, why does everyone always do it wrong? One of life's big questions.
[flagged]
Re: Local async executors and why they should be the default
#69Earlier quoted context omitted.
the use of async and await is a design decision that requires knowledge of the program's logic and desired behavior. It's not just a matter of compiler optimization, and that's why the compiler can't automatically figure out where to use these keywords. Suppose we have a service where users place orders, and we need to: 1. Save the order. 2. Deduct items from inventory. 3. Send a confirmation email. If we perform the…
I was thinking more in terms of making good old 'blocking' calls and that the compiler can 'taskify' those old blocking calls to let the thread do some other task instead of waiting on the 'blocking'
Sometimes you want to spawn a [future/task/promise/...] and not immediately await it, but instead pass it around. Suppose something like:
should_be_future = async_function()
should_execute = async_function() # Re: Local async executors and why they should be the default
#70Suggesting that single threaded concurrency is the right way to do it when building tooling is completely asinine.
He isn't suggesting that. He's suggesting it is the right place to start, in the same way that we normally start writing sync code with a single thread.