<story><title>Rust and the Future of Systems Programming [video]</title><url>https://hacks.mozilla.org/2016/11/rust-and-the-future-of-systems-programming/</url></story><parent_chain><item><author>Animats</author><text>Not sure what to think of that.  Does everything have to be async I&amp;#x2F;O now? How often do you need massive numbers of client connections?</text></item><item><author>kibwen</author><text>Speaking of HTTP clients, just yesterday the person behind Hyper announced their new high-level HTTP client crate: &lt;a href=&quot;http:&amp;#x2F;&amp;#x2F;seanmonstar.com&amp;#x2F;post&amp;#x2F;153221119046&amp;#x2F;introducing-reqwest&quot; rel=&quot;nofollow&quot;&gt;http:&amp;#x2F;&amp;#x2F;seanmonstar.com&amp;#x2F;post&amp;#x2F;153221119046&amp;#x2F;introducing-reqwest&lt;/a&gt;</text></item><item><author>pimeys</author><text>Now I have four services running on production, all written with Rust. If it compiles, it usually works. Of course you have these late night sessions where you write that one unwrap() because, hey, this will never return an error, right? And bam...&lt;p&gt;I&amp;#x27;m seriously waiting that tokio train to be stable and a unified way of writing async services without needing to use some tricks with the channels or writing lots of ugly callback code. Also the native tls support is coming and the dependency hell with openssl would be gone forever.&lt;p&gt;If you need http server&amp;#x2F;client, I&amp;#x27;d wait for a moment for Hyper to get their tokio branch stable and maybe having support for http2 by migrating the Solicit library.</text></item></parent_chain><comment><author>jcrites</author><text>Asynchronous nonblocking interfaces are more general-purpose than synchronous blocking interfaces. I can&amp;#x27;t speak for this library or Rust specifically, but in my experience well-designed asynchronous libraries allow you to interact with them in a synchronous style as well, if you wish.&lt;p&gt;Netty is an asynchronous, event-driven network framework for Java, and it&amp;#x27;s perfectly possible to expose synchronous blocking abstractions on top of it. The mechanism is pretty simple: the asynchronous framework exposes a future representing the result of an operation, and to provide a synchronous interface you simply block on the completion of that future before returning. Client libraries can handle this for you, providing the interface of e.g. a regular blocking HTTP client on top of Netty async IO.&lt;p&gt;This approach can be convenient, since it&amp;#x27;s possible for both synchronous and asynchronous style code to coexist easily in the same application. The application designer can incrementally change parts of the application into asynchronous style as performance needs dictate. For example, you might choose to serve typical small RPC requests using blocking workers in a thread pool, but when you need to stream the content of a large file across the network you could use a separate nonblocking worker pool that interacts with both the file system and network asynchronously.&lt;p&gt;The ability to interact in a blocking way via futures means that asynchronous facilities can serve both synchronous and asynchronous needs, making them the better choice for most frameworks today. While it used to be the case that async IO frameworks took a performance penalty compared to well-implemented sync IO ones, from what I understand that gap has been closed, and the highest performance frameworks are now all async IO. For example, check out the TechEmpower Web Framework Benchmarks. Most or all of the top performers use asynchronous approaches: &lt;a href=&quot;https:&amp;#x2F;&amp;#x2F;www.techempower.com&amp;#x2F;benchmarks&amp;#x2F;#section=data-r13&amp;amp;hw=ph&amp;amp;test=plaintext&quot; rel=&quot;nofollow&quot;&gt;https:&amp;#x2F;&amp;#x2F;www.techempower.com&amp;#x2F;benchmarks&amp;#x2F;#section=data-r13&amp;amp;hw=...&lt;/a&gt;</text></comment>
<story><title>Rust and the Future of Systems Programming [video]</title><url>https://hacks.mozilla.org/2016/11/rust-and-the-future-of-systems-programming/</url></story><parent_chain><item><author>Animats</author><text>Not sure what to think of that.  Does everything have to be async I&amp;#x2F;O now? How often do you need massive numbers of client connections?</text></item><item><author>kibwen</author><text>Speaking of HTTP clients, just yesterday the person behind Hyper announced their new high-level HTTP client crate: &lt;a href=&quot;http:&amp;#x2F;&amp;#x2F;seanmonstar.com&amp;#x2F;post&amp;#x2F;153221119046&amp;#x2F;introducing-reqwest&quot; rel=&quot;nofollow&quot;&gt;http:&amp;#x2F;&amp;#x2F;seanmonstar.com&amp;#x2F;post&amp;#x2F;153221119046&amp;#x2F;introducing-reqwest&lt;/a&gt;</text></item><item><author>pimeys</author><text>Now I have four services running on production, all written with Rust. If it compiles, it usually works. Of course you have these late night sessions where you write that one unwrap() because, hey, this will never return an error, right? And bam...&lt;p&gt;I&amp;#x27;m seriously waiting that tokio train to be stable and a unified way of writing async services without needing to use some tricks with the channels or writing lots of ugly callback code. Also the native tls support is coming and the dependency hell with openssl would be gone forever.&lt;p&gt;If you need http server&amp;#x2F;client, I&amp;#x27;d wait for a moment for Hyper to get their tokio branch stable and maybe having support for http2 by migrating the Solicit library.</text></item></parent_chain><comment><author>steveklabnik</author><text>1. This introduces a primarily synchronous API for now. Async will come later. All those code samples are synchronous.&lt;p&gt;2. Async I&amp;#x2F;O is an extremely hot topic in Rust right now, so it&amp;#x27;s likely that Rust people do care about it.</text></comment>