withoutboats3

11 ms·

91.
by withoutboats3 3y ago
The definition of !Move was always the (rather baroque) "cannot be moved once its address has been taken;" this allowed you to construct them, allocate them, etc until you start manipulating them. Pin just took that contract and i
92.
by withoutboats3 3y ago
All great points. Re async not being there from day one, this is indeed a big problem. it resulted in certain painful technical compromises (eg Pin) & probably at least ans importantly resulted in cultural / educational issues. The
93.
by withoutboats3 3y ago
I don’t really understand what you mean about side effects but async functions do indeed just return futures just like JavaScript async functions return promises - rust futures just are compiled into state machines in a way JavaScript promi
94.
by withoutboats3 3y ago
This is what I describe as "stackful coroutines" in the final section of the post.
95.
by withoutboats3 3y ago
That’s absolutely not a summary of my blog post, since I completely disagree with it. I think async/await is great and avoiding it for some reason would do nothing to mitigate the function coloring problem.
96.
by withoutboats3 3y ago
Thanks I shouldn’t get so angry but I’ve spent most of the past year reading essays & interviews from the 70s to try to get my head around how to respond that specific blog post (which I think makes both good and bad points). Was very o
97.
by withoutboats3 3y ago
The bigger problem is growable stacks. It’s true you can suspend a stack and then continue as long as your implementation doesn’t ever move it. I didn’t really dwell on this because I wrote more about it in “Why async Rust?” And you’re righ
98.
by withoutboats3 3y ago
You’re right, state isn’t really what I meant. I meant exactly the sort of concurrent collating you allude to.
99.
by withoutboats3 3y ago
This is the subject of the final section of this post, effect systems specifically are referenced in the margin note.
100.
by withoutboats3 3y ago
Sorry my blog post depressed you, but I wonder if it did so nearly as much as your arrogant & rude comment did me. I am deeply aware of njs’s notes on structured concurrency & have been working on a post engaging with it. This post
101.
by withoutboats3 3y ago
"Dwarf"? "Dwarf"?! I may be biased (because I am very effective at Rust and terrible at C++) but I can't believe this seems probable. std::optional, move semantics, boost, template templates, SFINAE(!!) C++ has all
102.
by withoutboats3 3y ago
Obviously, it'd be better for someone who wants to talk to postgres and doesn't need non-blocking IO if a version based on blocking IO existed. But what is your grand point? It's not some conspiracy that libraries for network
103.
by withoutboats3 3y ago
A big difference between Rust and other languages like Dart is that our async/await is based on the same sort of coroutine transform as generators would be, rather than continuations, so its a lot less additional complexity to add gene
104.
by withoutboats3 3y ago
This was the subject of my previous post: https://without.boats/blog/why-async-rust/
105.
by withoutboats3 3y ago
The feature is shipping before the end of the year.
106.
by withoutboats3 3y ago
I think the comment this person was responding to is completely off topic for my blog post, and extremely shallow. I share the person you're responding to's frustration with how async Rust is talked about on Hacker News.
107.
by withoutboats3 3y ago
As a user who has maintained network services that communicate with Postgres, I'm very glad that sfackler's postgres library doesn't perform blocking IO calls, as that would make it unfit for purpose for me.
108.
by withoutboats3 3y ago
What Rust libraries use non-blocking IO without using async syntax? I don't know of any. This interpretation of the request is new to me: I've exclusively heard complaints about libraries using async from people who want to use bl
109.
by withoutboats3 3y ago
What Rust libraries use async that you think should not? I can think of one, but otherwise every library I've encountered uses async because its intended for the kind of networking service that benefits from using non-blocking IO.
110.
by withoutboats3 3y ago
The only thing constrained by backward compatibility was using Pin instead of Move. Async/await itself is the natural progression for Rust for the reasons I outlined at length regarding how Rust represents zero-cost coroutines.
111.
by withoutboats3 3y ago
You are commenting on a very long post in which I explained in detail how green threading wasn't compatible with Rust's lack of garbage collection. Your response is to just insist that you wish that wasn't the case - that you
112.
by withoutboats3 3y ago
This is a completely ridiculous mischaracterization of what I wrote, John, and you of all people should understand that sometimes systems programming and network programming are the same goddamn thing. I can tell you that there are plenty o
113.
Why Async Rust?(without.boats)
212 points by withoutboats3 3y ago|133 comments
114.
by withoutboats3 3y ago
Thanks for this response, it's really interesting. > For workloads where dynamic load skew across cores is common, which is the more interesting problem, work-stealing becomes a performance bottleneck due to coordination overhead. N
115.
by withoutboats3 3y ago
Just last month .NET ended a green threading experiment, mainly because the overhead it adds to FFI was too high: https://github.com/dotnet/runtimelab/issues/2398 Rust had green threads until late 2014, and t
116.
by withoutboats3 3y ago
In this context, we're talking about things for which the throughput is IO-bound. You're talking about the latency of an individual request. Throughput being IO-bound is indeed about the hardware, and the truth is that at the hi
117.
by withoutboats3 3y ago
I'm just referring back to my earlier point: people say not doing work stealing would be both easier and faster. My claim is that its one or the other, because to get share-nothing to be faster you need to architect your code in a way
118.
by withoutboats3 3y ago
> A big problem with software dev is the lack of rigor, imo. It's amazing to me how much more informed you can seem than everyone else if you just read the thing everyone is quoting.
119.
by withoutboats3 3y ago
No it wasn't. Anyone can follow the link and see that it was about preferring non-work-stealing executors, none of the things you complained about.
120.
by withoutboats3 3y ago
> True, I think it happened because Rust community quite aggressively sought out those developers to gain market and mindshare. Guilty as charged, honestly. But we were really target high performance web services where Rust really makes

More ›