Skip to content

Instantly share code, notes, and snippets.

@mark-i-m
Last active May 23, 2020 03:56
Show Gist options
  • Star 2 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save mark-i-m/a39320449a1311515ac62e43ddd9dee0 to your computer and use it in GitHub Desktop.
Save mark-i-m/a39320449a1311515ac62e43ddd9dee0 to your computer and use it in GitHub Desktop.

Rust 2020 reflections

This is my third roadmap post... you can find the first two here:

This year, I am quite divided due to a bunch of competing desires:

  • I still want all of the things that I wanted last year. In particular, it would be great if OS developement could finally be done on stable rust. Things like inline asm are blocking this.

  • I think there is still a great deal of technical debt left over. I'll talk more about this later.

  • It's not clear what the right balance of new features and working on technical debt is.

So without further ado...

Operating systems in rust

I will keep this brief, because I have mentioned it in the past. I think rust is the ideal language for OS kernel developement. However, kernel developement still requires nightly rust. There are two blockers left: some sort of inline asm functionality, alloc_error_handler.

alloc_error_handler is required to use liballoc (TODO: verify this). I don't think there is a lot here, except that we need to make sure this is the API we want. I personally, don't really care too much about this. I am more interested in being able to use liballoc on stable.

Exotic calling conventions (e.g. x86-interrupt) and naked functions can be implemented with inline asm. The blocker here is design work. There was a Pre-RFC about inline asm a while back, but there was still some discussion to be had and somebody needs to champion and implement the ideas.

Technical Debt and Measurable Progress

In 2019, the roadmap specified that we would focus on finishing things we started. I think this was exactly right, but looking back, I'm unsure what was actually accomplished. It seems clear that a lot of good work was done by a lot of people. In addition, it seems that a lot of this work was not focused or directed. That is, I am not aware of any specific goals or milestones that were targeted.

Moreover, there has been almost complete silence from the rust teams on where they believe the project is and where they are trying to go (with the notable exception of finishing async/await). I specifically asked for input, but I ended up collecting the information myself after a long wait. This is despite participation from other community members and projects, like rust-analyzer.

I say this not to lay any blame, but rather to suggest that going forward, we should explicitly agree on and layout goals and measure progress towards them.

We should pick a few milestones and put active focus on achieving them. This applies even to technical debt work: we should explicitly choose certain technical debt items, make a big list, and actively work through it in a measurable way.

I think this can help give the community a direction and also give a sense of progress made, which can help with planning, allocation of resources, etc.

Rust 2021... perhaps not?

I don't see the need for a Rust 2021. In 2018, we had a list of changes we wanted to make that were backwards-incompatible, and we batched a bunch of changes together in one edition. I am not aware of any such list of desired changes for 2021. Making a new edition just because it has been 3 years doesn't make sense to me. Indeed, I think we should make a new edition only when needed to reduce churn and overhead on the users.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment