Rust 2020: towards a 1.0 crate ecosystem

letsgobroncos.png

The Rust language itself went 1.0 in 2015. And yet, almost 5 years later, at least in my anecdotal assessment talking to and reading things written by current or potential users, there is still a sense that the language is still in some way unfinished and a bit rough around the edges.

I sympathize with these concerns.

There are various language-level issues which are partly to blame for this. The absence of a comprehensive story around asynchronous I/O and event-driven programs in general has been one of them, but that all changes… today… with the long awaited stabilization of async/await in the Rust 1.39 release along with the release of futures v0.3.0 earlier this week.

There are other core features which many desire. In my Rust in 2019 blog post I wrote about const generics as the #1 in my top 3, along with async/await and Pin, which both shipped this year.

Others long for even more advanced type system features, primarily those around the general vicinity of associated type constructors, generic associated types, and higher kinded types, which would elevate the corner Rust occupies on the Lambda cube.

But if you were to ask me what’s really holding Rust back, and the true source of the perception that Rust is “rough” or “unfinished”, I honestly don’t think it’s core language features, at least, as of today: my foremost concern there, async/await, is shipping right now.

To me the biggest “unfinished” part of Rust is the crate ecosystem.

This isn’t to say that people aren’t writing crates, and that they aren’t writing damn good crates! No, quite the opposite, the crate ecosystem is blossoming.

And yet looking at all these amazing crates, across many projects, there’s a recurring theme: the majority of crates I’m building my project on are versioned 0.x.

Why does 1.0 matter? Here are a couple of reasons why 0.x crates are bad:

With that prompt, I would like to ask everyone in the Rust community, including myself: why aren’t your crates versioned 1.x yet?

Whether or not a crate should be 1.0 or not is a judgment call only an author can make. But here’s a rubric I think can be used to test if you should label your crate 1.0 or not:

I think these are great candidates for 1.0 crates!

If your crate fits roughly into that mould, but you still have lingering items on your 1.0 milestone, here’s a simple thing I think you can do: move those lingering items to a new 2.0 milestone, and release 1.0.

That’s not to say this is a bar to which 1.0 crates should be held. Once upon a time 1.0 used to mean the “first version”. Now I would argue it means the “first stable semver guarantee”. I think that’s a bar which is attainable for many crates, and which all crates should aspire to.

Let’s make 2020 the year of 1.0.

 
179
Kudos
 
179
Kudos

Now read this

“DCI” in Ruby is completely broken

Rubyists are people who generally value elegance over performance. “CPU time is cheaper than developer time!” is a mantra Rubyists have repeated for years. Performance has almost always taken a second seat to producing beautiful code, to... Continue →