This is my answer to call for blogs 2020 and somewhat an update to my post from last year. You don’t need to read the old post though, since this post is written in way that it incorporates that content as well.
For every topic, I will present my personal favorite parts, split into Completed (compared to the post from last year or was not on the list but is nice anyway), Open (existed last year and is still relevant), and New (got relevant or new idea).
I will skip over the call for ideas for the Rust 2021 edition, since I currently cannot think of any breaking change that would require a new Rust edition. I would however not mind a new edition, since the last transition (2015 to 2018) went really smoothly and the tooling support was great.
Cargo & Crates.io
The package management and build system made good progress and just work, but if used regularly, some service features are missing. Implementing these could enhance the overall experience.
- Ability to host your own registry: You can now use your own registry and there are already server-side implementation out there (meuse, alexandrie).
- Auditing: It is now required that every crates.io user has a valid email address which provides traceability of packages.
- Security model / integrity: We are still missing a nice security model and end-to-end integrity of crates.
- License issues: I am still convinced that tools like cargo-lichking must be part of cargo, because users often get licenses wrong or create incompatible combinations.
- Dependency resolution: People often wonder why crates are compiled twice in slightly different versions or why a simple CLI tool out of the sudden uses 200 dependencies. I think cargo could do a better job explaining these things or even try to prevent certain cases (e.g. by pointing out upgrade blockers or by downgrading some crates).
- Automatic cleanup: While using cargo, there are a lot of intermediate built results and cache entries created, that are currently not cleaned up (see cargo#6229). There are tools like cargo-sweep, cargo-cache, and cargo-trim, but I think this should be a builtin feature.
- RustSec by default: cargo-audit, the tool to consume the RustSec database, should be a builtin feature. Security by default.
- Debugging: It would be nice if cargo would just set
RUST_BACKTRACE=1when running software in non-release mode and would offer an integration with a debugger (a la
cargo run --debugand
cargo test --debug, similar to
pytest --pdb) by default. I know this is covered by cargo-with, but I think it would be friendlier to newcomers if this is integrated into cargo directly (also see cargo#3670).
- Incomplete features: See cargo-hack.
I am a bit disappointed with the rustdoc process lately (although I did not contribute anything, so this complain is not really fair). While the user-facing design is simple, I think it is lacking some features that are somewhat expected from a documentation tool.
- Include external markdown files: Sadly, the external doc attribute still is unstable, which makes it quite hard to have a nice README, a changelog, and docs in-sync.
- Images: Image support is missing from rustdoc forcing users to use ASCII-diagrams, base64-encoded images, inline SVGs, or links to GitHub pages as a workaround.
- Intra-Doc links: Intra-rustdoc links are still unstable but are getting close to stabilization.
IDE & Dev Tooling
There was a solid amount of progress this year on that side!
- rustup improvements: I was already quite happy about rustup, but it got some new features lately.
- rust-analyzer foundations: rust-analyzer is in a good shape now and on the way to be the goto solution for IDEs.
- rust-analyzer improvements: There are some important things to solve for rust-analyzer, mostly associated types and proc macros, but I am sure that this can be done.
Language & Stdlib
The number of big new features in the language and stdlib is small and I think that’s good. The language is getting more mature. Also see the section on foundation work for some background why there was a huge amount of work done even though not all of it is visible to the end users.
- Basic async/await: It’s finally happening. Although I personally don’t really need that feature at the moment, I think it is an important addition to the language and the ecosystem and will have many powerful application even beyond IO.
- Better algorithms: It is nice to see that it is possible to use better algorithms like hashbrown for the standard library and that all users just magically get an performance upgrade.
- Never type: We are getting close is finally solving rust#35121.
- Inline assembler: Recently this popped up again on internals.rust-lang.org and I think it is important for low-level interfaces, kernels, and embedded.
- Const generics: rust#44580 was not really on the list last year, but I think this could be important for many abstractions.
- FFI unwinding: This story has been open for way to long and also was not the nicest community endeavor. I hope this gets settled soon and we can finally close this soundness hole.
- Empty loop soundness: Another soundness issue are empty loops and LLVM (rust#28728) and I think these problems should be tackled with higher priority than new features.
Docs, Community, Ecosystem
This is kinda a “Misc” section, but contains important notes as well.
- Rustlings, quickstart: I am usually referring to rustlings as a good introduction for newcomers and when I was looking into it again recently, I was massively surprized to see how much it had changed over the last year. 🙂 The same goes for the riscv quickstart guide which is a pleasure to work with.
- Insides: The Inside Rust Blog is now available with nice information about the ongoing work and the different teams.
None (section did not exist last year).
- 1.0 crates: Many important crates currently have a
0.xversion number and per Semantic Versioning are therefore be considered to be somewhat unstable. I think many developers fear that once
1.0is released, they cannot make any fundamental changes anymore and they do not yet want to commit the current design. There is no harm in releasing a
2.0though and I think proper major versions would make it easier for crate consumers.
- Dependency reduction: It would be nice if developers would choose their dependencies in a slightly more restrictive way. Small algorithms do not need to be imported (e.g. leftpad) and some default features are not always required. This can lead to massive reductions in binary size and compilation times.
Foundation Work, Compiler
Some work is not really visible as a feature, but nevertheless important.
- Library extraction: Libraries like polonius, chalk and rustc_lexer are important crates to the compiler (although polonius and chalk are currently not used on stable). They can be used by non-compiler crates like rust-analyzer now which is just a massive gift to the ecosystem. Also, these crates have seen massive work and will make the compiler even better.
- Miri: Although still experimental, miri has seen a number of changes and is now available via rustup, so everyone can use it to find nasty bugs in their unsafe code. It is surprising to me that unsafe code can now be checked at least somewhat and it is nice to know that “unsafe” does not mean “you are on your own now!”.
- Speed: The Rust compiler gets faster and the buildsystem (Cargo together with rustc) is smarter.
- Cranelift: It would be nice if cranelift could be used for faster debug builds. There is work ongoing to do that and I think we will see work on that front over the next year.
- Compiler internals: MIR-only RLIBs (rust#38913) and parallel queries (rust#48685, rust#59667) are a real long-term effort but will probably advance the compiler massively.
I am very happy about the state of Rust and I think 2020 will bring a solid number of improvements. 🎉