It is again the time of year when the Rust team is calling for blog post as input to the next annual roadmap. This is my contribution.

The Foundation

I wish either the Rust Foundation itself or at least a sibling organization formed at the same time was domiciled in the EU. Within the EU, Germany looks like the appropriate member state.

Instead of simply treating the United States as the default jurisdiction for the Rust Foundation, I wish a look is taken at the relative benefits of other jurisdictions. The Document Foundation appears to be precedent of Germany recognizing Free Software development as having a public benefit purpose.

Even if the main Foundation ends up in the United States, I still think a sibling organization in the EU would be worthwhile. A substantial part of the Rust community is in Europe and in Germany specifically. Things can get problematic when the person doing the work resides in Europe but entity with the money is in the United States. It would be good to have a Rust Foundation-ish entity that can act as an European Economic Area-based employer.

Also, being domiciled in the European Union has the benefit of access to EU money. Notably, Eclipse Foundation is in the process of relocating from Canada to Belgium.

Technical Stuff

My technical wishes are a re-run of 2018, 2019, and 2020. Most of the text below is actual copypaste.

Promote packed_simd to std::simd

Rust has had awesome portable (i.e. cross-ISA) SIMD since 2015—first in the form of the simd crate and now in the form of the packed_simd crate. Yet, it’s still a nightly-only feature. As a developer working on a product that treats x86_64, aarch64, ARMv7+NEON, and x86 as tier-1, I wish packed_simd gets promoted to std::simd (on stable) in 2021. There now appears to be forward motion on this.

At this point, people tend to say: “SIMD is already stable.” No, not portable SIMD. What got promoted was vendor intrinsics for x86 and x86_64. This is the same non-portable feature that is available in C. Especially with Apple Silicon coming up, it’s bad if the most performant Rust code is built for x86_64 while aarch64 is left as a mere TODO item (not to mention less popular architectures). The longer Rust has vendor intrinsics on stable without portable SIMD on stable, the more the crate ecosystem becomes dependent on x86_64 intrinsics and the harder it becomes to restructure the crates to use portable SIMD where portable SIMD works and to confine vendor intrinsics only to specific operations.

Non-Nightly Benchmarking

The library support for the cargo bench feature has been in the state “basically, the design is problematic, but we haven’t had anyone work through those issues yet” since 2015. It’s a useful feature nonetheless. Like I said a year ago, the year before, and the year before that, it’s time to let go of the possibility of tweaking it for elegance and just let users use it on non-nighly Rust.

Better Integer Range Analysis for Bound Check Elision

As a developer writing performance-sensitive inner loops, I wish rustc/LLVM did better integer range analysis for bound check elision. See my Rust 2019 post.

likely() and unlikely() for Plain if Branch Prediction Hints

Also, as a developer writing performance-sensitive inner loops, I wish likely() and unlikely() were available on stable Rust. Like benchmarking, likely() and unlikely() are a simple feature that works but has stalled due to concerns about lack of perfection. Let’s have it for plain if and address match and if let once there actually is a workable design for those.

No LTS

Rust has successfully delivered on “stability without stagnation” to the point that Red Hat delivers Rust updates for RHEL on a 3-month frequency instead of Rust getting stuck for the duration of the lifecycle of a RHEL version. That is, contrary to popular belief, the “stability” part works without an LTS. At this point, doing an LTS would be a stategic blunder that would jeopardize the “without stagnation” part.