<story><title>Tokio internals: Understanding Rust&apos;s async I/O framework</title><url>https://cafbit.com/post/tokio_internals/</url></story><parent_chain><item><author>lurr</author><text>Yeah, but I actually have a reasonable chance of accomplishing what I want in C++.&lt;p&gt;vs Rust where I bash my head against it for 2 days then give up. I&amp;#x27;m not smart enough for Rust, oh well.</text></item><item><author>jcrites</author><text>&amp;gt; Aren’t abstractions supposed to make things easier to learn?&lt;p&gt;Not always. Some abstractions are designed to make it easier to solve hard problems correctly (than without the abstraction).&lt;p&gt;For example, consider Rust&amp;#x27;s memory model. Many people criticize that model as difficult to learn. By comparison, you might argue that C&amp;#x27;s memory model is simpler to learn. Yet, the C approach to allocating, using, and freeing memory is highly error-prone. C programs historically have frequently had mistakes such as use-after-free errors, or buffer under&amp;#x2F;overflow&amp;#x2F;reuse errors. The high-profile OpenSSL Heartbleed vulnerability was an example of a weakness in C&amp;#x27;s memory model and memory handling abstractions [1].&lt;p&gt;Rust&amp;#x27;s memory model may be more difficult to learn than C&amp;#x27;s, but once learned, they are abstractions that provide an advantage in building correct software, by ruling out certain classes of mistakes. (GC in languages like C# and Java and Go can also prevent these mistakes, but comes with a runtime cost. Rust aims to provide zero-cost abstractions.)&lt;p&gt;Building correct async IO programs using kernel abstractions is difficult for similar reasons as it&amp;#x27;s difficult to write correct programs with C&amp;#x27;s memory model. It&amp;#x27;s especially difficult if you want the async IO program to be portable across multiple OS&amp;#x2F;kernels. I have not used Tokio, but I would guess that its Rust-powered abstractions will make it difficult or impossible to leak memory or sockets, or to fail to handle error cases that might arise handling async IO.&lt;p&gt;[1] &lt;a href=&quot;https:&amp;#x2F;&amp;#x2F;www.seancassidy.me&amp;#x2F;diagnosis-of-the-openssl-heartbleed-bug.html&quot; rel=&quot;nofollow&quot;&gt;https:&amp;#x2F;&amp;#x2F;www.seancassidy.me&amp;#x2F;diagnosis-of-the-openssl-heartble...&lt;/a&gt;</text></item><item><author>kindfellow92</author><text>&amp;gt; Unfortunately, Tokio is notoriously difficult to learn due to its sophisticated abstractions.&lt;p&gt;Aren’t abstractions supposed to make things easier to learn? Something about the idea of “complex abstractions” seems wrong.&lt;p&gt;(Edit: this is not a criticism of Tokio, it’s a criticism of the OP’s characterization of “sophisticated abstractions” which IMO should reduce complexity)</text></item></parent_chain><comment><author>Matthias247</author><text>I can totally understand that opinion, but let me give a further view on that:&lt;p&gt;I implemented in the last years dozens of async&amp;#x2F;event-driven networking libraries, and wanted to do the same in Rust about 4 years ago. I guess I even started to work on the first async IO libraries for it (&lt;a href=&quot;https:&amp;#x2F;&amp;#x2F;github.com&amp;#x2F;Matthias247&amp;#x2F;revbio&quot; rel=&quot;nofollow&quot;&gt;https:&amp;#x2F;&amp;#x2F;github.com&amp;#x2F;Matthias247&amp;#x2F;revbio&lt;/a&gt;). However I also got frustrated quite quickly with it, since the ownership model makes the typical solutions for asynchronous programming super hard (e.g. callbacks or callback interfaces). Therefore I also gave up on that (and also temporarily on the language).&lt;p&gt;However some years and evolution of Rust later my viewpoint on this changed a bit:&lt;p&gt;- Asynchronous I&amp;#x2F;O is generally messy and leaves a lot of room for errors. E.g. each callback that is involved might cause reentrancy problems or invalidations, object lifetimes might not be well-defined or matching expectations, etc. While most languages still allow it, it&amp;#x27;s hard to get fully right. Especially when manual memory management is involved. Async I&amp;#x2F;O plus multithreading is mostly a recipe for disaster.&lt;p&gt;- Rust just puts these facts directly in our face, and wants to you to go the extra route to provide that things are working directly. It&amp;#x27;s far from easy to figure out how to do this in a sane way. I think the tokio authors did an awesome job on finding some primitive abstractions with the poll model that allows for async I&amp;#x2F;O and uses Rusts type system for safety guarantees. It&amp;#x27;s a little bit akward to use without syntactic sugar like async&amp;#x2F;await or coroutines, but I think that is in the nature of the problem.&lt;p&gt;- Trying to do async IO probably shows off the domain which is the most inconvenient in Rust (besides similar problems like object-oriented and callback-driven UI frameworks). Therefore it shouldn&amp;#x27;t be used as a general point of measurement how easy or complex Rust is to use.</text></comment>
<story><title>Tokio internals: Understanding Rust&apos;s async I/O framework</title><url>https://cafbit.com/post/tokio_internals/</url></story><parent_chain><item><author>lurr</author><text>Yeah, but I actually have a reasonable chance of accomplishing what I want in C++.&lt;p&gt;vs Rust where I bash my head against it for 2 days then give up. I&amp;#x27;m not smart enough for Rust, oh well.</text></item><item><author>jcrites</author><text>&amp;gt; Aren’t abstractions supposed to make things easier to learn?&lt;p&gt;Not always. Some abstractions are designed to make it easier to solve hard problems correctly (than without the abstraction).&lt;p&gt;For example, consider Rust&amp;#x27;s memory model. Many people criticize that model as difficult to learn. By comparison, you might argue that C&amp;#x27;s memory model is simpler to learn. Yet, the C approach to allocating, using, and freeing memory is highly error-prone. C programs historically have frequently had mistakes such as use-after-free errors, or buffer under&amp;#x2F;overflow&amp;#x2F;reuse errors. The high-profile OpenSSL Heartbleed vulnerability was an example of a weakness in C&amp;#x27;s memory model and memory handling abstractions [1].&lt;p&gt;Rust&amp;#x27;s memory model may be more difficult to learn than C&amp;#x27;s, but once learned, they are abstractions that provide an advantage in building correct software, by ruling out certain classes of mistakes. (GC in languages like C# and Java and Go can also prevent these mistakes, but comes with a runtime cost. Rust aims to provide zero-cost abstractions.)&lt;p&gt;Building correct async IO programs using kernel abstractions is difficult for similar reasons as it&amp;#x27;s difficult to write correct programs with C&amp;#x27;s memory model. It&amp;#x27;s especially difficult if you want the async IO program to be portable across multiple OS&amp;#x2F;kernels. I have not used Tokio, but I would guess that its Rust-powered abstractions will make it difficult or impossible to leak memory or sockets, or to fail to handle error cases that might arise handling async IO.&lt;p&gt;[1] &lt;a href=&quot;https:&amp;#x2F;&amp;#x2F;www.seancassidy.me&amp;#x2F;diagnosis-of-the-openssl-heartbleed-bug.html&quot; rel=&quot;nofollow&quot;&gt;https:&amp;#x2F;&amp;#x2F;www.seancassidy.me&amp;#x2F;diagnosis-of-the-openssl-heartble...&lt;/a&gt;</text></item><item><author>kindfellow92</author><text>&amp;gt; Unfortunately, Tokio is notoriously difficult to learn due to its sophisticated abstractions.&lt;p&gt;Aren’t abstractions supposed to make things easier to learn? Something about the idea of “complex abstractions” seems wrong.&lt;p&gt;(Edit: this is not a criticism of Tokio, it’s a criticism of the OP’s characterization of “sophisticated abstractions” which IMO should reduce complexity)</text></item></parent_chain><comment><author>hobofan</author><text>I am not trying to personally attack you here, but most times when people say something like this, what they are actually saying is: &amp;quot;I think I am accomplishing the same thing in C++, but by not facing (and solving) the problems, I am actually creating a program with nasty hidden bugs, that might or might not blow up in my face later&amp;quot;.</text></comment>