In part two, the author explains trait objects in a way that is, I think, a little misleading.<p>They're right that trait objects are dynamically sized types, which means they can't be passed by value to functions, but wrong that they need to be boxed; they can instead be put behind a reference. Both of the following are valid types.<p><pre><code> type DynFutureBox = Pin<Box<dyn Future<Output = ()>>>;
type DynFutureRef<'f> = Pin<&'f dyn Future<Output = ()>>;
</code></pre>
You can see this in the Rust Playground here: <a href="https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=6c61667f75dfc2435e6a342f897d1c30" rel="nofollow">https://play.rust-lang.org/?version=stable&mode=debug&editio...</a>
My only experience with Rust has been synchronous mostly with little to show for in terms of async. And I liked Rust. When it ran, I was damn sure it was going to run. There is comfort in that: "Tell me what to fix". The clippy stuff etc. was great too.<p>I read the 3 parts of this website and 'Wowsa'... I'm definitely not going in that direction with Rust. I'll stick to dumb Go code, Swift or Python if I do async heavy stuff.<p>It's hard enough to write good code, I don't see the point of finding walls to smash my head into.<p>Think about it, if you write a lot of async code, chances are you have a ton of latency, waiting on I/O, disk, network etc. Using Rust for this in the first place isn't the wisest since performance isn't as important, most of your performance is wasted 'waiting' on things. Besides Rust wants purity and I/O is gritty little dirt.<p>Sorry my comment turned into a bit of a hot take, feel free to disagree. This async stuff, doesn't look fun at all.
It's amusing that the Rust Playground lets you run a hundred threads. That's generous of them. There's a ceiling below 1000, though. The author points out, "On my Linux laptop I can spawn almost 19k threads before I hit this crash, but the Playground has tighter resource limits." Large servers can go higher than that.<p>The thread-based I/O example with the compute bound poll loop is kind of strange.<p>"Join" isn't really that useful when you have unrelated threads running finite tasks. Usually, you let the thread do its thing,finish, put results on a queue, and let the thread exit. Then it doesn't matter who finishes first.
Rust join is actually optional. You don't have to join to close out a thread and reap the thread resources. It's not like zombies in Unix/Linux, where some resources are tied up until the parent process calls wait().<p>Loops where you join all the threads that are supposedly finished are usually troublesome. If somebody gets stuck, the joiner stalls. Clean exits from programs with lots of channels are troublesome. Channels with multiple senders don't close until all senders exit, which can be hard to arrange when something detects an error.<p>In Rust, the main thread is special. (I consider this unfortunate, but web people like it, because inside browsers, the main thread is very special.) If the main thread exits, all the other threads are silently killed.
I really liked the footnote implementation so I checked out his GitHub to see what kind of static site generator he was using, and it looks like he wrote his own? What a baller.