Think Twice Before Using Async Rust | Prime Reacts 

This was the main thing I was wondering about. That's a very cool idea, thank you. :)

but how can i do work stealing on thousands of blocking tasks? i can see building a threadpool that handles a queue of tasks or something of that sort in sync, but how do you tell the threads to switch tasks when they are waiting for something

@@eddierandom6074 This is not the most widely applicable architecture you can use. If you want to do something fully integrated like what you mentioned you simply need a async runtime everywhere for that. The thing this architecture was originally suggested for was something like a discord clone where the sync side handles the user input and UI stuff while the async side handles the IO. I would definitely *not* suggest people consider this option unless they are making something like a single user application (and even then this isn't the ultimate solution a lot of the times). This is just one way to capture the async beast if you were curious on how to do so.

​@@eddierandom6074that's how Tokio multithreaded runtime works

Where did you read this? I haven't heard anything about this at all. To my knowledge they don't have any intention of doing this..

​@@jonkoenig2478chatgpt said it

​@@jonkoenig2478Async traits are now available

Not quite. Adding more options can have more good sides than downsides.

Threads exist if you need them in the standard library. Just because it's not as convenient doesn't mean it doesn't exist.

Async is default feature of Rust. The async runtime (the scheduler) is not. Including runtime is a no no for embedded or RTOS. It's violate the zero-cost abstraction.

@@ardfard101 Which makes sense, because async will never be zero cost. It's simply impossible. People got up in arms about C++ async including a runtime and allocations but there's truly no way around it. If you wanna context switch in a userland perspective that's what has to happen. The truth is that if such a runtime is a no-no for embedded, I doubt there exists any suitable async runtime for embedded. Surely, including a runtime and then simply turning it off via the compiler would make more sense. Rust should've taken a more opinionated approach to this IMO. They can always take a page from C++ and just include Tokio in the standard library.

​@@lucass8119I think you're right about needing to be opinionated here. We already use core/no_std anyways to target embedded and turn off features. Adding async to that really wouldn't change the landscape for embedded. My opinion is, we could probably just make tokio the included option and clean up the repo in the process for things we don't need in std.

To be fair to prime, and I do the same; his technique is just jump in the code to figure out the problem space, delete and do it again a xecond time but with the foresight of knowing what problems will crop up. He uses jumping into the code as his way of mapping the problems rather than theoretically in a whitevoard session, so its not quite as thoughtless as it sounds

​@@TurtleKwitty My personal issue there is that it leads to mistakes that could have been prevented early but by the time you realize them it takes 10-100x more work to fix them. That evolutionary/iterative approach has the same issues as actual evolution; at first a nerve from the brain to the throat passing through the heart wasn't an issue at all; it was even the shortest route! But, then, as time passed that distance got greater, and greater, and greater, and now giraffes have a nerve 4.6 meters longer than it needs to be. Pure iteration works only insofar as the problems are implementational, but as the problems become architectural and go deeper and deeper you're less and less likely to stop them and they rapidly become high-interest technical debt. Projaculating is fine for implementation or concept tools, but when writing something you know will be important on a lower level you really need to define the problem carefully. I have, genuinely, written code that worked exactly as expected first time despite never implementing it before, with only stupid syntax errors preventing it from compiling first time as well. (in C++, not Rust, added just because the "when it compiles it will do what you expect" thing is the elevator pitch for Rust) This is literally just because I had a full conceptualization of what I wanted to solve, so as I wrote it I was just following that internal-spec. When you're doing extensions to existing code bases, refactoring parts of existing codebases, etc. you aren't dealing with those architectural issues so it's much easier to projaculate and only reap rewards, but a lot of lower level early-design decisions will only cause you to experience problems down the line. I think it was from the video "the cult of done" by no-boilerplate where he said something along the lines of "MVPs are production, your first draft is the final draft, and there will never be a mark II". (heavily paraphrased but it's a similar concept) That's sort of the issue I think the projaculating methodology has, because you only ever identify the problems you go far-enough ahead to experience yourself while writing those early scratch-drafts. If it's a problem you'd only need to deal with a year from now, you're just not gonna find it with those scratch drafts. Projaculating isn't a useless strategy, it is faster, it gets good-enough results extremely quickly, and it doesn't have the issue of precisely, but incorrectly, defining the problem. (which is often far worse than just not defining it at all) However, it also does have issues. If you only ever projaculated code, you'd never need to care about the stack or the heap, you'd never need to care about memory safety, you'd never need to care about threading, etc. because those are almost never immediate problems. Those are things which only become problems when you need effecient memory access, when someone hacks your code, or when your code suddenly needs to be 10x faster 6 months down the line.

Dynamic dispatch has a performance impact. Though, realistically, it's not going to be major. To my knowledge, Anyhow uses Box in the backend.

@@lowellthoerner1209 Right that makes sense. Though I think it's also fair to say that for most applications, the "happy path" doesn't actually result in an error so most of the time it does not even do vtable look up with Box

I'm guessing threads might also be faster in practice if you use thread pools for example

The biggest valid complaint is that this should be baked into the language.

They don't really have a overhead. It just allows you to use non-static references in the scope because all created threads in the scope are guaranteed to finish when the scope ends. So instead of adding overhead it just restricts what you can do.

@@cocacodes But it does create new threads every time right? I want to parallelize my custom ECS, scoped threads would be perfect for that (I could just borrow a slice of my component arrays per thread), but if that means creating new threads every frame I would be better of using rayon's scoped thread no?

@@stysner4580 Yeah, scoped threads aren't really all that different from normal threads and so they don't have any thread pooling. I don't know much about rayon's internals though so you'd have to take a look at it yourselves (edit: I've taken a look at some stuff in rayon and it does seem like the ThreadPool struct has a scope method so using that could be ideal for you)

@CocaBot Yeah rayon uses pools. Thank you!

Me too 🎉

He's made negative comments about helix in so many of his videos already. Basically, his argument is that 1) it's not vim motions, and 2) you should use vim motions, and 3) vim motions have already won, everywhere, and you can use them everywhere

Rust currently provides the language constructs for async, e.g., the async/await syntax, and Futures, but not much else. Any asynchronous I/O is done using a library such as tokio, which provides synchronization primitives made to synchronize async tasks rather than threads, and I/O such as traits for asynchronously reading and writing files, and sockets that can be awaited instead of blocked on.

>My understanding of Rust’s async model is that the language should provide async variants of I/O methods that return Futures. This is not an ideal thing to add into std because those implementation are changing constantly.

Let's look at Paul Allen's async

I am

Well it wasn't as obvious when Rust started. JS added async in 2017. TS in 2015. I wouldn't say async was obvious as a feature then. Rust started in 2010, first stable release 2015. It's a very new language. Not the best comparison of course. Rust has changed a lot in these short years I'm sure. But assuming JS drove the "obviousness" of async/await that's not a lot of time for a language to adapt. Especially considering the core of Rust is low level programming where async/await as a feature is more unusual and the large burden they've taken on with the borrowchecker.

​@@0xCAFEF00D C# added async in 2012 and it based on... thread pool! And even in Rust-Book they teach how to create basic web server based on your own thread pool with channels lol. So they could just add default async std runtime implementation based on thread pool as good enough for a default one.

What a lot of these comments, like yours, don't seem to understand, is that people who work on Rust, and the people who work on the Rust ecosystem, are the same community of people. If there is ever a distinction, it's that those who work on Rust specifically are the ones who showed an interest in working on the language, showed up, and did the work. This is a truly open source project, not something shepherded by a company: I'm not making any value judgments by saying that, but the point is that it's not a "We" and "They", it's a "We" and "We".

@@nisonatic I think you and I actually agree on this. I was addressing OP's belief that there is a clear distinction between the Rust project, and the Rust library authors. I think it's a Venn diagram where the part that's exclusively the Rust project is a tiny sliver. In fact, it's because the Rust project wanted people to experiment with different async runtimes that we ended up in the situation we're in today. It was a conscious and deliberate decision, and one taken after a lot of thought and discussion, not some BDFL from the Rust Project that simply said "the users can go and build this core piece of our language", as OP characterises it. Not shipping an async runtime might be surprising to people, but it's actually unsurprising when you consider things like serde (serialisation and deserialisation), regex (regular expressions) and rand (random number generation) aren't part of the standard library. Granted it's slightly different, i.e. you can write programs that don't make use of any of those behaviours while you can't write async programs without an async runtime, but I see it as being not too different a situation as a crate that only ships a trait (see tower-service for an example).

Yes. Try Axum.

@@Tigregalis I'm on it. Axum + sqlx seem fairly trivial to use. After that i am making my web app logic in wasm with rust to practice some regular rust.

what are you talking about man its all zero cost abstraction. Of course this doesn't include the 75% abstraction 'sin' tax. That isn't a cost. Its your duty an abstraction junkie.

@@homelessrobot "its all zero cost abstraction" C++ devs said this once upon a time.

Ill agree with you depending on your answer to "do you use a memory safe language" (you better say yes 😛)

This is specifically an async Rust issue. There are 2 main issues that I see: 1. the async-await feature was released half-baked, and they are implementing changes to the language that hopefully address the papercuts: it's basically code that people intuitively write that doesn't work (e.g. aliasing traits), should work in the future. 2. As a systems language, it doesn't ship its own async runtime (a conscious choice, for maximum flexibility), and it's academically a problem, but it's not practically a problem because you just pick Tokio and you move on. Sync Rust on the other hand is mature in many domains and an absolute joy to use. If you're building *applications* in many different domains, Rust is a joy to use. In some domains (front end web, gui applications, AAA games), Rust is still in its infancy. If you're building *libraries*, well then, that's when you actually really need to dig into the language, so that you can provide a nice API to your users. Just like in other languages, the library author feels the pain so the application developer can have a nice experience. If you aren't shipping maximally-flexible, maximally-performant, maximally-ergonomic libraries, then just use those libraries to build the applications.

I'd definitely give yourself more time to play with it, and spend less time listening to language nerds argue over idiosyncrasies that may or may not ever apply to you. We use Rust in production services and the fact that once it compiles you can have high confidence it's going to work is an amazingly freeing place to be. Well-architected async environments in Rust will not abuse you as this article might imply. YMMV.

The caller of await is suspended until await returns.

@@minciNashu same as sync blocking with the only difference being is that the scheduler reuse the cpu while the async operation blocks. Async await is just automatic compile and runtime time refactoring. It's theoretically possible to write the same code in a sync style. But it would be a nightmare to write and read.

i think its precisely NOT making comprises why people hate async rust. rust elects to give the programmer so much more control of futures than any other language, what other languages would even attempt to offer zero allocation async/await

Anyone that looked at Rust as "Magically doing things" was just wrong, the whole point of the language is to not be magical about things. I don't think anyone that read the actual documentation would come up with that perspective, but overhyped and shallow youtuber takes might indeed give that impression.

Less rhetorically, more technically, what are you referring to, exactly?

where you getting those figures from? for most non trivial applications this is not even close

If I want to hire a bunch of developers to quickly develop a web service (whose code I'll never touch), I would choose Go. If I have to touch the code, I would choose Rust.

Yet another person who thinks the main reason to use Rust is performance. Better performance is just gravy, not the point for almost anyone.

The main reason I love it is because it forces me to write good code. You can even force the compiler to prove that your program could literally never panic. It's a byproduct of good code that it is fast, not necessarily the draw. Sure, sometimes I end up in a 30minute battle with the borrow checker, but it's usually because I've had some misunderstanding about the data structure, and the moment I get my code to compile is the moment I fixed that misunderstanding. I can't really get away with not understanding, so the process of coding in rust always makes me better

Curious about worst syntax and semantics of the currently popular language set. I assume you don't consider C++ a currently popular language as I think that is objectively (not subjectively: objectively), worse. I can understand how the syntax might feel daunting for a beginner (I was there), but there's nothing inherently more complex about it (except in so much as there are a larger set semantics that need to be expressed through syntax), it's just a lack of familiarity, and it's something you get used to. The syntax is very concise for the number of things you're actually declaring/doing, and maybe the issue for beginners is that it's too concise. Where in the world do you get the idea that the community is as toxic as a nuclear wasteland, though?

All the credit of js goes to Zig and C++ and the geniouses who write genious code with thosr to make JS into what it is.

@@Tigregalisexactly. I actually think rust has one of the best syntax out of all languages. It’s so much easier to grasp and makes sense. The problems everyone has with rust usually isn’t the language itself but how they chose to handle stuff like async runtimes and also how the borrow checker still has major causes of false positives (code that SHOULD compile because it is 100% safe but the borrow checker does not perform a deep enough analysis )

​@@axisaligned9799 Curious about this. Just a beginner here but it seems like if the borrow checker did a deeper analysis you'd end up in a situation where you'd have a whole bunch of exceptions to a rule. The code and the compiler's behaviour would be harder to reason about and reverse engineer (my 2nd favourite way of learning).

this talks about async, not threading? rust has fine threading as far as i know lol

@Architector_4 the fact that parallelism is a runtime at all is the problem. If u compare this to c++ gpu programing (something u would think would be a runtime) u can move move device ptrs around between cuda openmp etc and that means u r not stuck with the choice ur library designer made. Essentially rust needs to get its act together around parallelism so we can start seeing it in hpc enviorments

​@@nevokrien95Again, rust doesn't have any problems with parallelism. Threads are good, better than C++'s. What isn't all that nice is Async/Await, which requires a runtime regardless of language.

@vladlu6362 I don't understand why you need a separate runtime for async. Can't u achive this with a few macros? Also why the need for more than 1 of these

@@vladlu6362 ...Now you're saying that rust doesn't have any problems with parallelism? that was my initial point and i guess i'm glad that you agree; i argue nothing about async lol

Why not provide these features in a library instead of a new runtime?

​@@paherbst524they are literally libraries though

I'm on embedded. You couldn't have a standard Rust async runtime that would suit me as well, at least not before another decade of Rust evolution.

To be clear: 1. Rust the language has no async runtime. 2. The runtimes are provided by the ecosystem. 3. These runtimes are libraries.

@@Tigregalis, but these runtime libraries aren't additional libraries, but replacement runtimes. there should be a standard runtime, and feature add's should be libraries based on the standard runtime.

Hard disagree. They optimize imagining that rust code will be running on embedded systems while frameworks are being written to make frontend web development possible. It’s going the way of an object falling into a black hole: spaghettification

Oh i have no doubt personally. Its' kind of a dubious honor though.

@@Sam-cp6so What are you even saying? WASM is just a compilation target, one that brings the low level control of a systems language to a web browser. And the job of the language it to do a good job at that, regardless of the target you set LLVM to. People writing libraries and frameworks for one or the other changes nothing about that. Web frontends won't affect you if you are writing code for a microcontroller and highly performance conscious, byte counting, no-std libraries won't affect you if you are using a web framework.

did you write this article?

How so? I've seen no sign of that. (Writing embedded Rust with >50 simultaneous tasks and lots of interaction. No races seen yet, nor apparently the chance of any.)

Data races are prevented by the type system

🙃

Let's break it down. Hard? Yes, when applied for inherently difficult domains. However, Rust has very little incidental complexity. For simple use-cases, Rust is just as easy. Esoteric? The only "esoteric" thing about Rust itself is lifetimes. And it's better than hidden complexity related to lifetimes that comes in C++. Go has GC to deal with memory but no amount of tuning can fix it at scale. Useless? Rust is anything but useless. It can be used for nearly anything and is especially good in backend and cross-platform development. Go is nice and simple but it doesn't scale well due to GC. And you know what? Rust can be used from Go to solve some of its problems.

Just don't use rust for everything it's that simple Choose language according to your project requirements not the other way around

Its getting used, and to good effect. The downsides, to me, seem like they are mostly just the culture of people trying to stake out new architectural territory. We need those people to do that stuff, we just don't want to deal with the negative consequences of breaking new ground. So don't. Haskell and rust are at least useful as places to put new programming language concepts through their paces. Fortunately, they can do this just fine without you giving any shits or investing any time in them. Other people are more than willing to take on the risk for you. That is another good part about 'architectural gold rushes', they attract risk tolerant test pilots. Veterans don't need to kneel on a pire for progress.

For anything performance critical where you don't want to shoot yourself in the foot with dangling pointers and data races Rust is about as useful as a language can get...