Ranter
Join devRant
Do all the things like
++ or -- rants, post your own rants, comment on others' rants and build your customized dev avatar
Sign Up
Pipeless API

From the creators of devRant, Pipeless lets you power real-time personalized recommendations and activity feeds using a simple API
Learn More
Comments
-
@jestdotty me neither, we just upvote to pretend to be smart. I think I have an ex with the name rendezvous. He was Mexican.
-
Stuff like this is often for a good reason. Like "what if the thing gets dropped in this very specific scenario, then we couldn't do X anymore" or "if we don't take the thing then it has to be bound by lifetime Y if we await inside here"
There's quite some complexity sometimes
Or maybe the library is just designed badly :P -
@12bitfloat maybe, but then it becomes very interesting to make it yourself. Advantage of Rust is that there probably still is fun stuff to build for it technically. A library as this, is an awesome project.
-
@12bitfloat well, for one, you aren't obligated to directly await the Send future, you can put it inside a higher structure like a join or a select. High performance async code does this a lot, they do as much stuff synchronously as they possibly can and parallelize the rest aggressively. This leads to really weird incentives where you don't actually want to use async closures because you would miss the opportunity to execute synchronous code before returning the future that ultimately gets nested into a weird user-side scheduling primitive tree.
Nonetheless, both language design and convention dictates that you follow thee terminology of the physical stack and only mention details like this after the simpler concepts have been established.
Related Rants
So it turns out `futures` is a fucking liar and senders don't get an extra buffer slot in the sense that an additional message could be kept off-stack while the sender continues. The "extra buffer slot" they are talking about is the message resting inside the blocked Send future, which is to say, the fact that the sender can "block" is presented as a means of storage. Why does this community feel the need to complicate things? The analogy with the stack was perfectly fine. You wouldn't call a rendezvous channel a 1-item buffer just because the item actually has to be on the stack before it is sent and will stay there if the sender needs to wait.
rant
buffer math
futures
rust