Fast, Safe, and Complete(ish) Web Service in Rust

Really nice introductory article, though some of the more… axiomatic assertions, are iffy.<p>&gt; If it’s possible to build more reliable systems with programming languages with stricter constraints, what about languages with the strongest constraints? I’ve skewed all the way to the far end of the spectrum and have been building a web service in Rust<p>Bit overselling it, that introduction would work better for something like ATS or possibly Idris. Rust has its strictness, but it&#x27;s not exactly &quot;you must <i>prove</i> this recursion terminates&quot;-strict<p>&gt; Synchronous operations aren’t as fast as a purely asynchronous approach<p>This is misleading. Synchronous sequences are generally <i>faster</i> than asynchronous ones because yielding and getting scheduled back has a non-zero overhead (this is regularly re-discovered, most recently by the developers of &quot;better-sqlite&quot;: <a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=16616374" rel="nofollow">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=16616374</a>).<p>Async operations are a way to increase concurrency when your synchronous sequence would just be waiting with its thumb up its ass (e.g. on a network buffer filling or on a file read completing), so you can provide more service over the same wallclock time by (hopefully) always using CPU time.

Why would you want to do that in Rust instead of Go &#x2F; Java &#x2F; C# since the performance is the same. When I look at code example in the article the syntax is just awful seriously, who want to write web services with that kind of syntax:<p>time_helpers::log_timed(&amp;log.new(o!(&quot;step&quot; =&gt; &quot;upsert_episodes&quot;)), |_log| { }<p>It&#x27;s just non-sense:<p>impl&lt;S: server::State&gt; actix_web::middleware::Middleware&lt;S&gt; for Middleware {<p><pre><code> fn start(&amp;self, req: &amp;mut HttpRequest&lt;S&gt;) -&gt; actix_web::Result&lt;Started&gt; { let log = req.state().log().clone(); req.extensions().insert(Extension(log)); Ok(Started::Done) } </code></pre> Rust is a good language but I don&#x27;t see it any time soon in the web space with that syntax and the lack of mature libraries, plus the time it takes to get anything done. Where I see it is more for super optimized things like serialization and the like as libraries but not as a main program.

I&#x27;ve been using &#x27;actix-web&#x27; in anger for the last month or so and I just want to echo that it is an amazingly fast and fully-featured project.<p>I smiled when reading this post because I absolutely recognize the euphoria of carrying out a world-changing refactor and having it work first time. If this is what the future of backend development feels like, sign me up!

Really nice article.<p>I’ve been using rust moderately for the last 6 months and at least my experince was that once you get used to playing along with the compiler and understand the fundamental features of the language, it almost feels too good to be true.<p>Perfect mix of high performance, safety and modern features. Slightly challenging at first, but it really is worth the initial pain.

The author briefly mentions Haskell but I wonder whether they&#x27;ve build web services with it, or with another (loosely) ML-family language (e.g. OCaml, F#, or my personal favourite Scala). An ML-style type system is a huge advantage over Ruby&#x2F;JavaScript&#x2F;..., but for a web service I struggle to see a real case for going to all the effort of memory ownership tracking rather than using a GCed language with the same kind of strong type system; it would be good to see a comparison from someone who&#x27;s done both.

&gt; It’d be fair to say that I could’ve written an equivalent service in Ruby in a tenth of the time it took me to write this one in Rust.<p>Ha, I had the same feeling when I needed to create a simple REST service that&#x27;d just process a request using command line tools. Seems easy but Rust&#x27;s tooling is full of rough edges. Code completion sometimes works sometimes doesn&#x27;t, cargo cannot install dependencies only (without building source) so it&#x27;s not good for Dockerfile layers, etc. etc. Borrow checker is not bad at all for people that worked with languages with explicit memory management (where you do ownership tracking in your head anyway).<p>Long story short I spent 2 days working on the service and had 80% done but figured out the rest would take twice as much if I want this to be production quality. I scraped the project and rewritten it in node, using one or two dependencies in 2 hours.<p>I&#x27;ll be trying Rust again surely and I&#x27;m glad that articles like this one exist!

Very exciting to see Rust gaining support lately.<p>That said, one of the only remaining things keeping me from using it is production ready gRPC library.

Thank you for writing&#x2F;posting this!<p>Specifically the custom bindings using Diesel. I was unaware that generic sql could be bound so easily. That’s closer to how I end up when needing to create higher performance queries. I need to take another look at Diesel now.<p>Very nice article.

Thanks for writing this. Actix is really cool but I haven&#x27;t really spent the time looking into it - I was unaware of the SyncArbiter abstraction.<p>This is a very helpful post for me.

I <i>love</i> rust, but to be honest, until the nightmare that is tokio&#x2F;futures is fixed with native async&#x2F;await and better compiler error messages, a strongly typed language like C# with those features natively present is my choice for web services. It addresses all the author’s issues with Ruby and JS, and is still orders of magnitude faster than those options (though admittedly not as fast as a C or rust option).

Just wanted to mention that your usage of `sql_query` is exactly how it&#x27;s meant to be used, and exactly where I would reach for it. Great article!

tldr; - it was hard for me to determine which rust web framework I should be using, since I want something light like flask. best resource was <a href="https:&#x2F;&#x2F;github.com&#x2F;flosse&#x2F;rust-web-framework-comparison" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;flosse&#x2F;rust-web-framework-comparison</a><p>Very recently I&#x27;ve taken a tour around the Rust web server ecosystem, and I think it&#x27;s way too hard to find one to pick.<p>The author mentions actix-web[0], and mentions how fast it is, but it&#x27;s actually right <i>below</i> hyper[1], which I find to be simpler, because it doesn&#x27;t bring in the whole actor frame work thing. Hyper builds on Tokio[2] which introduces the usual event loop paradigm that we&#x27;re used to in other languages (which AFAIK is the fastest way to write web servers to date). There&#x27;s also great talk[3] that introduces the choices that tokio makes that are somewhat unique.<p>Here&#x27;s what I want out of a web framework:<p>- express like-interface (func(req,resp,next) pattern provies just the right amount of freedom&#x2F;structure IMO)<p>- good routing (plus: decorators&#x2F;a fairly ergonomic way to specify routes)<p>- reasonable higher-level interfaces to implement (I want to implement an interface, and be able to receive things like logging, tracing, grpc&#x2F;thrift&#x2F;whatever transports for free, good interfaces are what make writing reusable stuff like that possible)<p>Here&#x27;s what I found about the various frameworks that exist out there:<p>- Rocket.rs[4]: Seems to do too much (I tend towards building APIs), rocket is closer to django&#x2F;rails than it is to flask&#x2F;sinatra.<p>- Gotham.rs[5]: Seems perfect, but falls flat on the feature front, half the stuff on the landing page are features of rust, not the library. Doesn&#x27;t seem to have enough batteries included, for example there&#x27;s currently work being done on streaming request bodies (<a href="https:&#x2F;&#x2F;github.com&#x2F;gotham-rs&#x2F;gotham&#x2F;issues&#x2F;189" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;gotham-rs&#x2F;gotham&#x2F;issues&#x2F;189</a>), that&#x27;s not a issue I want to run into.<p>- Iron.rs[6]: The oldest of the bunch, but also very very fast (which I discovered actually browsing rocket&#x27;s issues[7]), not based on hyper, and also not actively maintained.<p>I had no idea which of these to use, or how to find ones I&#x27;ve missed, then I stumbled upon this amazing resource: <a href="https:&#x2F;&#x2F;github.com&#x2F;flosse&#x2F;rust-web-framework-comparison" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;flosse&#x2F;rust-web-framework-comparison</a>.<p>However, when you look at that comparison, it&#x27;s really suspicious how much of actix-web has filled out, which is often indicative of something written from one point of view (like when people have comparison pages, and one option seems to just have &quot;everything&quot;). And again, like I said actix seems to be doing too much, I don&#x27;t really want to utilize the actor model, I just want a relatively fast, ergonomic simple library with the most basic batteries included.<p>BTW, everyone keeps raving about type safety and I wonder why people don&#x27;t give Haskell more of a go. If Rust gives you the type safety equivalent to a shield, haskell is a phalanx. I&#x27;ve never felt more safe and protected by my types than when I write Haskell -- it&#x27;s relatively fast, memory safe, has fantastic concurrency primitives, and though it can be tough to optimize (which comes to down to optimizing for lower amounts of GCs like most other memory managed languages), it&#x27;s pretty fast out of the gate. I use servant (<a href="https:&#x2F;&#x2F;haskell-servant.readthedocs.io&#x2F;" rel="nofollow">https:&#x2F;&#x2F;haskell-servant.readthedocs.io&#x2F;</a>) and love it.<p>[0]: <a href="https:&#x2F;&#x2F;github.com&#x2F;actix&#x2F;actix-web" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;actix&#x2F;actix-web</a><p>[1]: <a href="https:&#x2F;&#x2F;hyper.rs&#x2F;" rel="nofollow">https:&#x2F;&#x2F;hyper.rs&#x2F;</a><p>[2]: <a href="https:&#x2F;&#x2F;tokio.rs&#x2F;" rel="nofollow">https:&#x2F;&#x2F;tokio.rs&#x2F;</a><p>[3]: <a href="https:&#x2F;&#x2F;www.youtube.com&#x2F;watch?v=4QZ0-vIIFug" rel="nofollow">https:&#x2F;&#x2F;www.youtube.com&#x2F;watch?v=4QZ0-vIIFug</a><p>[4]: <a href="https:&#x2F;&#x2F;rocket.rs&#x2F;" rel="nofollow">https:&#x2F;&#x2F;rocket.rs&#x2F;</a><p>[5]: <a href="https:&#x2F;&#x2F;gotham.rs&#x2F;" rel="nofollow">https:&#x2F;&#x2F;gotham.rs&#x2F;</a><p>[6]: <a href="http:&#x2F;&#x2F;ironframework.io&#x2F;" rel="nofollow">http:&#x2F;&#x2F;ironframework.io&#x2F;</a><p>[7]: <a href="https:&#x2F;&#x2F;github.com&#x2F;SergioBenitez&#x2F;Rocket&#x2F;issues&#x2F;552" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;SergioBenitez&#x2F;Rocket&#x2F;issues&#x2F;552</a>