Create a gist now

Instantly share code, notes, and snippets.

Embed
What would you like to do?

This is for the Rust2018 initiative. I will try to keep this brief, since I'm sure you have read a bunch of these.

Technical Debt

I have to 100% agree with @nrc's post. I feel like Rust has a lot of great things in the pipeline, but it worries me that there are so many open tracking issues and open issues in general (over 3100 at time of writing).

A lot has been written already about this, so instead I will focus on a few areas of technical debt that I see as particularly high-impact.

libsyntax2.0

Recently, @matklad proposed to refactor parsing into its own free-standing library, which can then be reused across tooling. You might be surprised that I see this as technical debt.

The problem is that Rust currently has neither an official grammar nor an official stable parser. This relegates important tooling like rustdoc, RLS, and rustfmt to either live in the rust repo OR implement their own parsing. The result is that these tools are hard to contribute to. Moreover, writing other tooling such as ctags for Rust is extremely hard because things keep breaking. IMHO, this is holding back (or slowing down, at least) tooling significantly, and that's why I list it among items of technical debt.

Stable rustdoc rewrite

I am super excited about this rewrite of rustdoc. rustdoc is one of my favorite tools in the Rust ecosystem. The fact that so many crates have fantastic documentation differentiates Rust from many other systems languages (most notably C and C++).

I think improving documentation is extremely important to developer velocity and productivity. Unfortunately, the current rustdoc implementation depends heavily on rustc internals, which makes it hard to hack on. The rewrite should fix that.

Procedural Macros/Macros 2.0

Procedural macros are the backstage hero of many fantastic crates. It never really occurred to me how often I use procedural macros silently until I sat down and thought about this post. The fact is that procedural macros are important to some very high-profile crates, such as Serde and Failure, especially for custom-derive. Unfortunately, I get the sense that Macros 2.0 and procedural macros don't get that much attention.

I think this area has a great deal of potential to improve crates and move a lot of projects to purely stable Rust, which I think it is very important for the perception of Rust as a stable language (and the reliability of software).

Stabilize or Remove

There are a lot of proposed features and RFCs that have not been implemented, have been partially implemented, or have been fully implemented but not stabilized. It would be nice to clean these up systematically. Issues that have not been worked on in a while should either get a task force to push them to completion or should be nominated for removal.

RFC starvation

EDIT: I decided to add this after writing the original post.

Rust has a great RFC process for designing new features. Unfortunately, features get proposed faster than they are discussed. As a result, there are almost 80 open RFCs, some of which have not been discuss for half a year and some of which are a couple of years old now. I would like to see a systematic effort to either close or discuss RFCs at a steady rate, starting from the oldest RFCs.

Bare metal/embedded code

I would really like to see more focus on making Rust easier to use in bare-metal environments, such as OS kernels and embedded systems. Currently, it's a bit of a pain to work in such environments in Rust. I think a lot of this also falls under the category of technical debt, too.

Cargo

@japaric has done a phenomenal job leading in the space of embedded Rust! Their tool xargo allows cross-compiling rust crates to many different platforms. I would like to see this support in Cargo itself. As @est31 puts it, I would like xargo to be "unforked".

Stable asm!

Currently, one of the biggest pain points for me is not having stable assembly support. I enjoy hacking together little OS kernels, and assembly is mission critical. I consider it an important part of any credible systems language.

There seem to be two options for using assembly from Rust:

  1. Using asm! (the unstable inline-asm mechanism) requires nightly Rust and isn't super well-documented or user friendly.

  2. Writing a separate .S file, compiling it to .o, compiling my Rust code to a .a ELF archive file, and linking it all together. This is a huge pain and is not easy to do with Cargo, making it necessary to layer Make with Cargo. Ugh.

Needless to say, neither option is very ideal. I would love to see a better solution in this space.

Along the same vein, I would love to see naked functions stabilized and cleaned up, as it complements inline assembly nicely.

Refactored libstd/PAL

The basic problem is that making Rust's libstd work on new platforms is hard. As a consequence, the only supported platforms seem to be Linux, macOS, Windows, and Redox. If you are writing your own OS or you have an embedded system or you are using some new experimental platform like WebAssembly, you are out of luck :/

@brson (we miss you!) put a huge amount of effort into this in the past. I think this will become a bottleneck for adoption of Rust on new platforms. My ideal would be that libstd itself contains no platform-specific code. Rather, new platforms would implement a series of traits at the interface between the platform and libstd. This would make libstd highly portable.

Crates

Everything before this is technical debt to some extent. These last few are not...

There are not a lot of no_std crates out there. This means that if I am writing an embedded system or custom OS kernel, I need to rewrite a lot of stuff myself. That's really unfortunate because cargo and crates.io are very useful for other projects I have worked on. It would be nice to get that power when working on no_std projects.

As part of this, it would be nice if parts of libstd, libcollections, etc. could be curated for use by no_std projects. There are a lot of useful things in those libraries that would work if they only had an allocator.

Auditing

When writing an OS kernel, one tends to be a bit paranoid. Specifically, if I was to include a third-party crate, I would want to make sure said third-party does not use unsafe frivolously, does not include superfluous code, does not have a billion dependencies themselves, does not do shady things in their build scripts, etc. All of this falls under what I would call "auditing". I don't know of any good solutions to this yet. There is a discussion started here, though.


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