#Rust2018 : Don’t be the new Haskell

TLDR: Big companies adoption determine the success of the language, not the quality of the language. Let’s target big companies / projects by having official libraries, stable tooling and make cargo do the same as the gradle wrapper.

About me

My name is Tibo Delor, I am an independent contractor working in Australia. I have been part of relatively big projects in several industries (banking, gambling, ecommerce, …) on different languages (Scala, Java, Web, .Net, python, Haskell, Cobol, …) sometimes as a developer, sometimes as a tech leader. My comfort zone is web development with Scala and React.

I have been following Rust for two years now. Sadly, my life has been extremely busy the last 2 years and I have not dedicated as much time as I wished to Rust and I haven’t produced anything worth sharing. My plan is to go crazy with Rust in 2018, so hopefully you will start seeing my name popping a bit more in the future!

Please forgive me in advance for any approximation, outdated facts and misunderstandings that you could encounter in this article and please correct me if I am wrong!

Rust #2017

I remember reading through the roadmap and thinking “YES! That’s exactly it!!”. On top of that ,whatever was promised has been, or is about to be, delivered! Big big Kudos to the Rust team and all the contributors, truely awesome work.

What I liked, most important to me at the top**:**

• RLS and VS Code improving experience. Not yet stable but massive improvements.
• Macro 1.1 in stable. This was huge to me. Not only because I could write macros but because Serde and Diesel could finally be used in stable.
• Library stabilisation. Not the stabilisation itself but the fact that the rust “officials” come and put their stamp on some libraries. I think that could go even further (for more explanation, read further).
• Incremental compilation and cargo check. Reducing the developer feedback loop is always very satisfying.
• NLL.

What I didn’t like:

• The epoch RFC. My biggest frustration. I think putting an other versioning system on top of an other one doesn’t make sense and is just confusing people. Either you use epoch or you use rust version but please not both… I also believe backward compatibility is a problem that must be solved, but not this way (more on that later).

Rust #2018

To me right now Rust has a lot of similarity with Haskell : Smart people behind it, a truely great concept solving real word problem, an opinionated community, a very powerful languages which is not easy to grasp, an immature eco-system, not ready for big projects with mixed-bag developers.

Why I wrote “immature eco-system”:

• Most of libraries are github projects backed by a couple of individuals rather than a whole community / company.
• There’s not yet a big de-facto web framework which solves all your problems like Java/Spring, Ruby/Rails, Scala/Play.
• No good Database Abstraction Layer. One of my big concern when writing a real world app is to be able to plug any database to it, not only because I want to be portable, but because my in-memory database for my tests will be different from my prod database and I want to avoid nasty surprises. Diesel beside being an awesome framework going in the right direction, is far from being ready for me. In my current company I can choose database from either Oracle, SQL Server or Teradata (probably because of vendor support), no way I can use Rust in prod just because of that.
• Most of the basic tools are not yet considered stable. Rustfmt, rls, clippy, VS Code plugin, …
• Some conceptual problems are yet to be solved: Backward compatibility, security of crates, …

That said, that’s what I expect from a recent language like Rust, and contrary to Haskell, Rust is evolving really fast. I believe it has now reached a point where it’s already an awesome language, all it needs is to have big companies contributing to the eco-system to make it mature. All successful languages are successful because they managed to convince big companies, not because they had a community of smart individuals (Haskell, I am looking at you, …).

Hence, here is what I think should or should not be a priority in 2018.

Priorities of 2018:

• Official Crates : Big companies needs to rely on their dependencies. Crates.io seems to copy the very controversial NPM security model. On the other hand docker hub have the concept official repository were the most useful images are stamped and reviewed by an official entity. I believe that should be the direction taken, the next step from the lib blitz. Introduce a flag on crates.io (call it “official”, “reviewed”, “featured”, whatever…) for crates that have some criteria (reviewed by staff, no transitive dependencies to non-official crates, etc…). I am not implying that Mozilla’s staff should be responsible for that, it could be an elected board, hand picked member of the community, …
• Improve developer tooling. Focus on a single developer configuration and make sure all the tools needed are there and stable. A developer should have a good editor with auto-completion and refactoring utility, a debugger, a formatter and a linter.
• Improve project tooling. One of my main issue as a tech lead is to make sure everyone is running / building thing the same way, at the same version. To mitigate that, we should rely as less as possible on manual installation. Rust-up and cargo should be merged, we don’t need two tools. Cargo config should contain the version of everything (library, rustc, cargo, …) and be able to auto update itself. I believe that Gradle, and the gradle wrapper, should be what cargo looks like. With gradle wrapper, I don’t need anyone in my team installing gradle themselves and I can update everyone’s gradle and java versions just with a commit. Ideally we want nothing installed on a developer’s machine except the source code and executing something like ./cargow build would download the correct cargo version, rustc, the std library, all the libraries and build the whole thing.
• Better libraries for basic things. Rust is meant to be good for concurrency and yet doesn’t have an official stable library for it. We need tokio and future-rs to be stable! Same thing for error management (failure crate?) logging (log crate?). This is just the most obvious examples that made me go “Wait, what? there’s no default implementation for that?!?”.
• Backward compatibility. That’s the most blurry for me, I am not sure how it works now and I am not sure how it should work in the future… I believe though that each library should be able to declare its rustc version and cargo should be able, somehow, to compile several modules together using different rustc/lib versions.
• Keep the community contribution friendly. That’s my only point not directly related to “big companies adoption”. That has be mentioned several time and Rust is doing an amazing work at it. Make sure beginners are welcomed and contribution encouraged. That’s how you build a community of proud Rustaceans that will promote the language.

Not a priority in 2018(intentionally controversial):

• Wasm. I understand why people are happy about it but I don’t think that anyone will adopt Rust because of that. WASM doesn’t have threads yet while Rust is all about concurrency (Memory management is also about concurrency). Tools around Wasm are also evolving, let them mature. Wasm support will just make the Rust community more happy but won’t help the language getting traction.
• Languages features. The language is good enough.
• Non-essential libraries. Let the community work for you. If companies adopt Rust, they will contribute and fill the gaps. Focus on those libraries that 90% of the developers will need.
• Desktop GUI. That will come from the community too. Nowadays 90% of GUI are web or mobile. Desktop GUI is now a niche with plenty of solutions.

That’s it for me, thanks for reading and please leave some comments on Reddit!