Building a shared vision for Async Rust
blog.rust-lang.org
Building a shared vision for Async Rust
1–10 of 139 posts
Re: Building a shared vision for Async Rust
#2> "the curse of knowledge: the folks working on Async Rust tend to be experts in Async Rust. We've gotten used to the workarounds required to be productive, and we know the little tips and tricks that can get you out of a jam"
I like the format of the github Rustlings repo for exposing common beginner pitfalls and pointing developers in the right direction. For the uninitiated, Rustlings is a repo containing a collection of broken code examples that the developer has to fix along their journey to enlightenment. I feel that it would be beneficial to have an "Advanced Rustlings", say Rusteenager ;), for more advanced topics like tricky borrow checker situations and async rust. These examples would be similar to the PR's mentioned in the blog post but may get better exposure imo.
Re: Building a shared vision for Async Rust
#3This is bullshit because of this article:[https://theta.eu.org/2021/03/08/async-rust-2.html]. Everyone is aware of the problems of async. What we need is solutions and not those stories to distract. We want profound changes.
Automatically translated.
Re: Building a shared vision for Async Rust
#4This is bullshit because of this article:[ https://theta.eu.org/2021/03/08/async-rust-2.html ]. Everyone is aware of the problems of async. What we need is solutions and not those stories to distract. We want profound changes. Automatically translated.
This was pretty heavily discussed on the reddit when it was posted: https://www.reddit.com/r/rust/comments/m1t1lk/why_asynchrono...
(And, as linked to in those comments, HN as well)
Re: Building a shared vision for Async Rust
#5This is bullshit because of this article:[ https://theta.eu.org/2021/03/08/async-rust-2.html ]. Everyone is aware of the problems of async. What we need is solutions and not those stories to distract. We want profound changes. Automatically translated.
Actually, the effort that started towards this blog post started weeks ago, easily several weeks before the blog post you're referencing.
Re: Building a shared vision for Async Rust
#6I like the approach that steps back and looks at usage scenarios. Not everything has to be solved by changing the language itself; it may be a matter of better tooling or teaching materials.
For example, the recent "async doesn't work" blog post was centered around confusion between `fn()` pointer and `Fn()` trait, and misuse of temporary `&mut` where `Arc` was required. If the compiler was smart enough to suggest these fixes, then the whole blog post could have been "async works fine, just needed a couple of lines changed as indicated".
Re: Building a shared vision for Async Rust
#7Is there any thought to including a default executor in the standard library? I think it's kind of an obstacle for beginners when the language/stdlib provide all the tools to write async code, but not to run it.
I saw discussed in this talk the intent in allowing developers to provide their own executor based on the specifics of their use case: https://youtu.be/NNwK5ZPAJCk?t=1107
This makes sense to me; however, I feel like the defacto at this point is that most people are using tokio. Is there a possibility that a default executor could be provided, and allow developers to override it with a custom library should they chose?
Re: Building a shared vision for Async Rust
#8I admire the passion, but I’m not sure why I would want Rust at all, not just async.
When I want memory safety, async-await, I/O performance, easy multithreading, I write C#. When I want performance of CPU bound code, or lots of integration with native libraries/APIs, I write C++. Sometimes I want both in the same software, compile C++ code into a DLL (or shared library on Linux), and consume it from C#.
I don’t have experience with Rust in production software, but based on what I know and my limited experience with the language, it’s worse than the above combo. At least for the projects I usually work on.
For pieces where performance doesn’t matter too much (often 70-80% of codebase), or for I/O heavy code, or for the stuff that’s in the standard library of .NET (serialization, compression, cryptography, xml, json, zip, etc.), C# is way easier to write and debug than Rust. Tooling is awesome. Even large projects build in seconds i.e. built/test cycle is really fast.
For CPU bound or native interop-heavy pieces, C++ is also way easier than Rust. Intel and ARM only support their SIMD intrinsics for C. OS vendors only support their GPU APIs for C (most of them) or C++ (Direct3D). Many libraries I use are only available for C and/or C++. Using C++ for these pieces is the path of least resistance by a large margin, i.e. saves lots of development costs.
The interop between the two adds some friction, but not too much, .NET was designed for easy native interop from the very first version. When I want to expose objects instead of [in addition to] just functions, there’re COM interfaces. At least in my experience, usability of C# brings way more profits compared to the losses from the interop across languages.
Re: Building a shared vision for Async Rust
#9I admire the passion, but I’m not sure why I would want Rust at all, not just async. When I want memory safety, async-await, I/O performance, easy multithreading, I write C#. When I want performance of CPU bound code, or lots of integration with native libraries/APIs, I write C++. Sometimes I want both in the same software, compile C++ code into a DLL (or shared library on Linux), and consume it from C#. I don’t have…
Do you have any good resources on writing dlls to consume via .net like you’re talking about ?
How do you deal with the managed memory when using the gc from .net
Re: Building a shared vision for Async Rust
#10Is there any thought to including a default executor in the standard library? I think it's kind of an obstacle for beginners when the language/stdlib provide all the tools to write async code, but not to run it. I saw discussed in this talk the intent in allowing developers to provide their own executor based on the specifics of their use case: https://youtu.be/NNwK5ZPAJCk?t=1107 This makes sense to me; however, I fe…
It was suggested in a PR, which was then punted into RFC territory. I’m not aware of anyone actively pursuing an RFC at this time.