answering the Rust programming language call for blog posts as input to the 2020 roadmap

Caveat: I am new to Rust. There’s probably stuff I don’t even know about that is more important than anything here. This is just me doing my part to give back to the awesome Rust community.

Overview themes

2020 roadmap: finish what’s started, fulfill the promise

2021 edition: scalability – Can newcomers to Rust create a real-world, complex system without recreating basic components or contributing to the language itself?

  • more scalable systems written in Rust
  • experienced C/C++ engineers can easily transition to Rust
  • more scalable ecosystem
    • commonly needed libraries are available
    • new engineers can easily become contributors

Keep doing

  • Tooling is great! rustup toolchain, feature flags, online/offline docs make it easy to experiment with new Rust/crate features, even as a relatively new Rust programmer.
  • Transparency (like this call for blog posts, RFC process including roadmap)
  • Focus on good docs & good error reporting is incredibly helpful. Keep iterating on this!

Feature requests

  • safety beyond memory safety and concurrency. For example: URL parsing should be in std — it’s risky for Internet apps to not have a stable, well vetted URL parser, why are there three? (That’s a rhetorical question. I know why, but don’t think there need to be. See twitter discussion
  • async all the things! I think this is already the plan. I look forward to async I/O (network and files) to be supported in the std library. I appreciate the thoughtfulness about safety, factoring out useful core concepts (like Pin/Task), and ensuring compatibility with Futures and Tokio crates. Consider other async use cases: GPU, OpenGL
  • lifetimes visualization would accelerate learning curve on resolving compiler errors, good ideas in this thread

Slow down to speed up

In my experience writing documentation often uncovers design issues and bugs. RFC template has a guide-level explanation section, which is great, and taking that one step further to writing baseline docs before declaring a feature “stable” would create positive pressure for community focus. Some ideas for process improvements…

  • A crisp “definition of done” could help focus the community. Consider adding requirements to releasing ‘stable’
    • RFC updated to reflect what was completed and is still open
    • stable reference docs are complete or include link to RFC
  • Consider WIP limits: how limiting work-in-progress increases speed

It seems in keep with Rust values to create a strong incentive to support contributing writers who are working to take the feature over-the-line and encourage new engineers to contribute. It is easier for new contributors to work with APIs that are documented or clearly dive into a work-in-progress, aware that they are contributing to finishing something.

Other Improvements

  • Documentation shouldn’t require deep knowledge of Rust (example: https://stackoverflow.com/questions/56402818/how-do-i-interpret-the-signature-of-read-until-and-what-is-asyncread-bufread-i/56403568#56403568)

Background

The reason I’m learning Rust is that I am experienced engineer with a need to write performant, low-profile client/server code. I’m excited about the idea of writing one body of code that can (potentially) work across native desktop, mobile, servers… and with cross-compilation to WebAssembly (Wasm), also browsers and edge servers.

Arguably, C works for all my needs, it even cross-compiles to Wasm. I want to like Rust better. I do in theory, but in practice, it’s got a lot of sharp edges (which is saying a lot when comparing it to C).