Rust in 2020

06 Nov 2019 . Rust . Comments #

Rust has become my favorite example of a community getting together to accomplish a goal with little incentive other than the betterment of their reach.

In terms of open source software, this has been my favorite place to go to convert some of my time into an aid for the community at large.

With so many goals, Rust has contention for how to invest the time to advance the language. I’ve seen priority to polishing libraries, improving the beginners experience, extending Rust’s reach into microcontrollers and WASM targets. Rust is even used in production in space. What more could we want?

I know the goals of the Rust programming language is to become a qualified option for as many projects as possible, and to have enough advantages over other languages to win out in valuation. Rust is not the fastest language to prototype, but project speed is improved by the compilier checking soundness and changing the way developers reason, forcing a pause in the design to figure out if a return type is an option or if cases are really unreachable or not.

There are a lot of tools whose maintainers have had to face a zealot rustacean asking them to rewrite it in rust. What if they were already trying to figure that out before they asked? What would it take to get Rust to the point where library authors in C/C++ no longer have an argument to RIIR? I imagine a world where Rust no longer has the same barriers for reimplementation (other than time!) of some core POSIX tools.

I imagine a world where we’ve made the platforms accessible to the compilier, and the library ABIs exist. I think 2020 is where we steer towards unlocking Rust’s potential and start resolving the external complaints from authors looking from the outside in.