Rust 2021: Lower the barriers

6 min read

People who end up using the Rust programming language are overwhelmingly satisfied with their choice, as indicated by Stack Overflow's annual survey (2020, 2019, 2018, 2017, 2016) where Rust was voted "most loved language/technology" for 5 years running. The % of Rust users who love the language has actually increased in the last 3 years - from 78.9% to 83.5% to 86.1%.

Clearly the teams working on Rust are doing a good job. Maintaing a stable toolchain with few bugs, frequent releases filled with features, improving compiler performance, improving documentation are a few of the reasons that could explain the growing love. An ecosystem filled with more mature libraries, tutorials and a welcoming community probably helps too. Big thanks to everyone who's contributed here.

More than any one thing, at it's core Rust provides a lot of value to it's users. Programs written in Rust are free of entire classes of bugs thanks to rustc having your back. The core idea of borrowing and lifetimes providing memory safety without a GC is so powerful that it will eventually become mainstream. After a point, all new programs will be written in a language that is memory safe, whether that safety is provided by a GC, or by Rust, or a language that copies Rust's features. It may take 10, 20 or 50 years, but we will get there. As an end user, that makes me happy.

Since the success of Rust or a Rust clone/copycat is guaranteed on a long enough timescale, the question becomes - how can we accelerate that?

Acceleration

It helps to think of programming languages as platforms.

  • Only platforms with a unique value proposition can succeed. (See Your Language Sucks, It Doesn’t Matter)
  • Low barriers to entry help platforms thrive. High barriers starve the platform of new blood, leading to a slow death.
  • The platform's value is proportional to it's popularity. More people joining improves the ecosystem. For programming languages it means more jobs, more libraries, better tools, more/better/quicker answers to common questions.
  • They benefit from network effects. People evangelize languages they love, further strengthening it.

As I mentioned, Rust's core value proposition is fine. In my opinion - lowering the barrier to entry by making it easier to learn is the most important thing. Right now most people new to Rust are told - "keep at it! In 3-4 weeks, it'll click and you'll start being productive." This is true, FWIW. The new concepts introduced by Rust are different enough from other languages that it does take people time to grasp though people eventually get it.

But 3-4 weeks is a luxury not everyone can afford. Most developers who would benefit from learning it or teams that would benefit from adopting it don't have 3-4 weeks to spare. The Stackoverflow surveys indicate that 5% of respondents said they used Rust. This 5% is almost entirely made up of people who had that time to spare. Sure, many people were able to carve out time when none existed, but the vast majority out there couldn't, and therefore didn't pick it up. They are currently being excluded.

This metric - the time it takes for a median developer to become productive in the language - is what will make the difference to adoption rate. The lower it is, the quicker adoption will be. We may never get it down to say, 2-3 days, but every day we reduce it by - we open up the language to developers and teams who can spare exactly that amount of time.

Once we get them on board, the love that Rust is famous for engendering could power future growth.

How do we do it?

By paying more attention to the people who try the language and fail to pick it up. We need to ask them what they found difficult and fix that.

Meanwhile, everything that Rust does well, we need to double down on it.

  1. Install experience is good - could it be better?
  2. Documentation is good - could it be better? More easily discoverable? For example, is the excellent Rust cookbook widely known? Could it be updated with the latest recommendations for error handling? Translated into more languages?
  3. Tutorials and learning materials are good - could they be better? Could there be more video tutorials or tutorials specific to a certain area like embedded programming?
  4. Compiler errors are good - could they be better, like this recent PR shows?
  5. Compile times and IDE experience have improved - could they continue to improve? Could we get a fast debug backend to improve productivity further?

Every improvement might only move the needle by a fraction, but it's well worth it. Judging by the rate at which all of these have improved in the last 5 years, I'm confident it's possible. The links I've shared in these suggestions show that that various members of the community have already realised the importance of these and are working hard at improving the state here. Kudos to them!

I'm hoping that in a year or two, we'll be telling newbies - "just stick it out for 2 weeks and it'll click".

Language wars

As an aside, thinking of languages as platforms also explains language flame wars.

Your productivity in any language is directly proportional to your time and effort investment in it. It's in your best interests to pick the language that's likely to thrive and spend time learning it's ins and outs. On the flip side, betting on a horse that doesn't win could mean the loss of months or years of effort. This is why people evangelize the platforms they're invested in - convincing other people to join improves the health of the platform, increasing their return on investment.

This evangelizing can sometimes become contentious if others perceive it as an attack on their platform. People defend their language mostly because they don't want to see it lose popularity. If it did, their language's viability is threatened and their investment is in jeopardy. It's also partly because they've spent so long on it that it's become a part of their identity.

That's something for us to keep in mind as we advocate for a language we like.

← Home