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...
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.
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.
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.