This is for the Rust2018 initiative. I will try to keep this brief, since I'm sure you have read a bunch of these.
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.
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.
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).
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.
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.
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.
@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".
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:
-
Using
asm!(the unstable inline-asm mechanism) requires nightly Rust and isn't super well-documented or user friendly. -
Writing a separate
.Sfile, compiling it to.o, compiling my Rust code to a.aELF 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.
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.
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.
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.