Rust in 2018

2 minute read 14 January 2018

This is my contribution to the #Rust2018 blog posts.

Why I started with Rust

My daily job is to implement scalable backends in Scala.

I very like Functional Programming and async IO.

But I have some pain point in Scala/JVM and I was very interested to see how Rust could fit here:

FP in Scala is not GC-friendly

FP in Scala tends to create a lot of small living objects, putting pressure on the Garbage Collector.

For very hot code, I have to re-implement some FP scala code into imperative style for better performances, and I very dislike that.

Rust on the other hand provide abstractions without overhead (or very little).

Java programs tend to be very "fat"

A Rust program can be statically compiled and directly packaged as a from scratch docker container, very lightweight compared to java applications that needs a distribution and a JVM.

Rust in 2017

In 2017, I tried different programs in Rust, from a minimal SDK that I tried to move to async IO, to a GUI program. I tried a lot of different HTTP servers.

And I contributed to an HTTP proxy based on Tokio and Futures.

Rust in 2018

My wishes for Rust in 2018 are mostly based on the pain I had with Rust in 2017:

Easier Futures

My experience with Futures was... very painful.

I had a lot of strange compiler errors, especially with lifetimes.

Sometimes, to fix then, I just had to move one variable from one closure to the upper one, something that makes no sense from the implement logic point of view.

I have a lot of difficulties with the static lifetime of Futures.

I hope that this will improve. Maybe non lexical lifetimes will help here.

  • impl Trait feature

And I'll also follow the async/await coroutines.

a "standard" HTTP server for backends

I'd need a good asynchronous http server ready for production usage, with a good community. There should exist good libraries that can integrate easily with this "standard" HTTP server, like for logs and metrics.