@notriddle's Rust 2020 wishlist, or, Rust 2021: Integration

notriddle-rust-2020.md

@notriddle's Rust 2020 wishlist

or, Rust 2021: Integration

This is just a brain dump. Doing all of this is not going to happen, but all of it is stuff I know of that impacts Rust's integration with the rest of the world and eventually becoming Too Big To Fail like C++ is.

Better resources outside the Rust core team's reach

1. Improved support for vendored, external, and non-crates.io crates. Some of it is just a matter of documenting the workarounds to allow cargo to use local git repositories in place of networked ones. Some of it is providing official, documented registry software.
2. Improved support for third-party discussion and documentation platforms. I love Users and Internals, and I can deal with Discord, but these are platforms specifically for discussing Rust. What we need is greater presence on platforms that are dedicated to problem domains: database courses, operating system courses, and et al, that just happen to use Rust. By definition, this is not under the control of the Rust core team, so it's more of a call to the larger community than to the Rust teams themselves.
3. More meetups. More books.

Better FFI and build integration

4. Improved support for third-party build systems in rustc and cargo. Cargo should be able to dump its crate dependency tree, and should expose rustc's file-level dependency tree (namely, rustc --emit dep-info). Ideally, it would use an existing, stable format like Makefiles rather than a bespoke JSON schema.
5. Improved support for third-party build systems in the crates themselves. In some cases, it's just a matter of coming up with standards and making pull requests against existing crates to implement them. For example, adding hooks for crates to make their system dependencies available to Meson or Bazel instead of using build.rs.
6. Improved support for non-C-language FFI. There's solutions for doing FFI with lots of languages, but they're each different, and none of them are particularly well-integrated with Rust's normal system. An ideal setup, probably, would allow a cargo project to have a build artifact other than a crate. Some collaboration between different FFI bridge providers to make their stuff work as similarly to each other as possible would also help.

Better distribution support

7. Improved support for packaging. This, again, means having build artifacts other than a crate. ripgrep builds a deb, but it's far too complicated.
8. Improved support for the weird platform limitations of the iOS, Windows, and Mac app stores and their sandboxed run modes. UWP would ideally be tier 1 (I don't think that's actually possible, right now, since rustc is a CLI app). Rustc should also be able to produce iOS bitcode, like it currently can produce wasm.
9. Improved support, and best practices, for vulnerability response. It should be possible to tell whether a crate will promptly respond to vulnerability reports before anything breaks (even if it's just a self-report "We promise to fix vulnerabilities promptly" flag in the Cargo.toml). Distributions should never be expected to ship software that doesn't have a security report email in all of its crates. The ability to address vulns promptly is completely separate from API stability. CC https://www.rust-lang.org/governance/wgs/wg-security-response , though they seem focused entirely on the Rust SDK itself.
10. Add an "oldstable" release channel, pointing at 1.CURRENT_MINOR - 1.LATEST_PATCH to rustup, and encourage library crates to support it by having the documentation for consumer CI systems default to settings like rust: [ beta, stable, oldstable ]. This way, anybody who distributes rustc themselves can simply follow the schedule "we update our rustc every six weeks when it's convenient" instead of "we have to update our rustc immediately or we risk having crate updates blocked on rustc updates." It still requires them to update every six weeks, but at least this way they get to decide exactly when they do it.
11. Use grant money to pay someone to work on mrustc. That is, empower platform distributors that want to bootstrap rustc themselves to do so.
12. Reproducible builds, both for the Rust SDK itself and for projects that are built with it.

Finishing notes

None of these bullet points require language-level changes. This is an intentional choice. The only changes proposed here that even involve Rust's stability promise at all are: the oldstable release channel, the --print makefile option, and whatever Cargo.toml metadata we'd wind up with to do a truly good job of integrating with Meson and its cousins.

Some of these projects seem big enough that they'd involve whole working groups. In particular, I would imagine:

• Packaging and deployment working group: Focusing on the end-to-end experience of turning Rust projects into releasable artifacts beyond crates.io. (Since I'm maintaining the rust and rust-ms Chocolatey packages, I would be personally involved in this one.)
• Verified build working group: Empowering projects, including Rust itself, to manage their library supply chain and achieve reproducible builds.
• Build system integration working group: Developing integration tools between cargo, rustc, and third-party build tools.
• Third-language FFI working group: Developing ergonomic FFI bridges between Rust and languages other than C.

This note is available on txti.es at http://txti.es/notriddle-rust-2020 and as a GitHub Gist on https://gist.github.com/notriddle/fabf82109a30ef2da7ad4bdb63e7e6af

The discussion thread can be found on Rust Internals at https://internals.rust-lang.org/t/notriddles-rust-2020-wishlist-or-rust-2021-integration/11216