rust2019.md

rust2019.md

Rust 2019: Technical Debt, Continued Productivity, and Stability

A response to the call for Rust 2019 posts

I hope this post doesn't come across as a laundry list of stuff to do. Mainly, I consider a lot of this to be technical debt, and I would like to see it paid down a bit. Most of them also happen to be pain points that I have come across in my own usage of Rust, so perhaps I'm biased! Feel free to let me know...

Some of these are also just ideas intended to get people thinking. At the end, I discuss the hypothetical Rust 2021.

(EDIT: feel free to discuss here: https://internals.rust-lang.org/t/rust-2019-technical-debt-continued-productivity-and-stability/9004)

Finish and stabilize features

Rust gets a pretty steady stream of new features through its RFC process. This is great, IMHO. However, a lot of them have been slow to make it to stable Rust, which I think is unfortunate. Some of them are quite old, while some are more recent. I would like to see a short impl period time set aside where no RFCs are merged and the focus is on visiting every accepted-but-not-stable RFC and evaluating it. For each one, either it should be stabilized or work items should be identified. If the feature is just not getting usage, it should be un-RFC-ed.

Some features that I would particularly like to see pushed over the finish line are:

• asm, interrupts ABIs, and other low-level stuff (since I do a lot of kernel-related stuff): much needed for serious low-level code, including benchmarking, which is currently tied to nightly.
• GATs
• const generics
• async/await
• box or placement-new of some form (currently, you either have to use the box syntax on nightly or use raw malloc, TMK)
• panic_info_message
• drain_filter

Cross-compilation on Stable

The embedded working group has done a lot of great work over the past year to get embedded working for Cortex-M devices. However, any other cross-compiled platforms, such as custom kernels or other embedded platforms are still tied to nightly and often face some breakage. Here are some work items that I have run into:

• std/core-aware cargo: there has been discussion of this on and off for several years now. This would be a major step towards getting cross-compilation on stable Rust. If nothing else happens, I would like this to happen in 2019.
• There was also some discussion previously of creating a HAL-like layer under the standard library so that libstd could be ported to un-supported platforms by just implementing the HAL layer. This would make Rust more widely usable. Currently, platforms like Redox and Fushcia have to get changes into libstd for Rust to work on their platforms. This is not scalable or maintainable in the long run.
• Unusual calling conventions/ABIs. Currently, if you want to write an interrupt handler, you need to use the unstable x86-interrupt ABI. If you are not on x86... well, that's too bad. I argue that instead we should have a general and stable way of writing interrupt handlers in safe Rust (perhaps it could even be a crate!). For example, we could stabilize #[naked] functions plus a way to define a function prologue and epilogue.

Push on Education

As a student, one of the things I find deeply frustrating is the following vicious cycle:

• companies want to use Rust, but nobody knows it, so use C/C++
• universities teach people C/C++
• companies want to use Rust, but nobody knows it, so use C/C++
• universities teach people C/C++
• ...

Ugh! Really? We have better languages for high-performance, reliable software (especially OS kernels). Even Go, which has been around for 3x longer than Rust is not really gaining traction at schools. I would like to see this cycle broken. In particular, I would like to see the Rust community team work with universities to push on getting Rust into course cirricula, especially as a first or second programming language.

Compiler Documentation

I hold the admittedly strong and controversial opinion that there is no such thing as self-documenting code. All code should come with excellent comments. Alas, the reality is not so!

The compiler's documentation is steadily improving. I would like to see it improve further. I want rustc to be the most well-documented compiler in history. An (arguably controversial) goal would be that every contribution is gated on being well-commented. Major changes should be gated on the appropriate rustc-guide chapters being written/updated.

Some more short-term and less controversial milestones might be:

• Finish the rustc-guide, get it into toolstate
• Thoroughly comment the entire compiler to lower the barrier for entry (perhaps this is more of a 2021 goal?)

Tooling and IDE support

Rust probably has some of the best tooling of any programming language I have used. I want to see that trend continue. For me, that includes addressing a few particular pain-points:

• Rustdocs: the UI is still not very key-board friendly. One idea I had was a terminal-based rustdocs. Oooo! That would be cool!
• RLS: lots of great work has happened here, but RLS is still not reliable IMHO. For me, the inconsistency of when it works is the worst part. Sometimes I type :: and immediately get suggestions; sometimes I get nothing. Sometimes I :GoToDefinition and it goes; sometimes nothing happens...
• cargo-src: this has potential to be one of the most useful tools of the ecosystem. I would like to see it pushed over the finish line and maybe adopted as an official Rust tool.
• vim: vim support is still kind of lagging, which is kind of weird given that the survey shows that vim is still widely used for Rust. In particular, the lack of a useful ctags replacement for Rust is a bit of a pain-point. Also, integration with YouCompleteMe would be wonderful!

Rust 2021: Stability (actually)

Rust has made incredible progress over the past few years. It has distinguished itself from the crowd of new programming languages (there seems to be a new one on Hacker News every month...) and even started to gain industry adoption.

Yet a surprisingly large portion of Rust users still use nightly Rust, according to the survey. I hypothesize that this is because there are so many nightly-only features. Personally, I'm stuck on nightly because I do a lot of cross-compilation for kernel development. I believe many others are stuck on nightly so they can use async/await.

For Rust 2021, I would like to see the community get to a place where nightly Rust is only used for experiments and (EDIT: fix typo) kernel compiler hacking rather than being the standard mode of operations for a large portion of the community. This will decrease breakage and significantly increase the usefulness of the crates.io ecosystem, I think.

Good post! On teaching, bring in a new language into an degree level curriculum is a slow process and a long-term commitment. In it's current state, I would hesitate to do this with Rust, for the simple reason that it is fairly hard to learn; even before it reaches students, I would have to train academics and demonstrators to be able to use it.

For Rust, though it would be worth the effort of encouraging this, because the Rust team would get lots of feedback from the process.

@phillord Yes, those are fair points. I think that one of the main blockers for getting Rust into universities is probably that (1) professors don't want/don't have time to learn it, and (2) they would need new curriculum. For example, most schools teach OS classes in C because their are a lot of pedagogical tools (e.g. xv6, minix, pintos) written in C. A lot of professors (in my experience) are also cynical about the value of teaching new languages; many don't even write code any more.

So I would say that having a concerted community push to lower the bar for profs to teach Rust would be helpful step. For example, creating slides, exercises, or other teaching aids might be a good start.

I would hesitate to do this with Rust, for the simple reason that it is fairly hard to learn

I have heard this view a lot, and I understand it, but am skeptical: all of us that found Rust difficult to learn were coming from non-Rust backgrounds, but if you learned to use the borrow checker as your first language, would it be easier?