I am one of the recipients of the recent Rust Foundation grants with a focus on Rust Playground maintenance and I want to share a bit about what is in store.
Rust Explorer has proven that using a longer-lived compilation session can unlock some much-desired playground capabilities, including (but not limited to) an increased number of crates available. My plan is to extend the official Rust Playground with similar support.
More importantly, I'm looking to mentor some new long-term contributors to the playground. If you are interested in contributing, read on!
The current playground implementation is a traditional HTTP request / response architecture: each execution sends an HTTP request that spawns a Docker container that starts
rustc, and the results are collected and sent back.
The plan is to add an additional mode where the playground opens a WebSocket connection to the backend which in turn starts a corresponding Docker container. This long-running container will allow the user to perform actions that take longer, such as compiling crates that are outside of the top 100 or with different features enabled. A rough diagram:
Web browser Playground backend Docker ┌───────────┐ ┌──────────────────┐ ┌──────────────┐ │ │ │ │ │ supervisor │ │ │ WebSocket │ │ stdin/stdout │ ┌──────────┐ │ │ │◄───────────►│ │◄───────────────┤►│ │ │ │ │ │ Axum │ │ │ Cargo │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ └──────────┘ │ │ │ │ │ │ │ └───────────┘ └──────────────────┘ └──────────────┘
I've noodled with a prototype for the connection between the backend and the Docker container that gives me some confidence that this plan should work.
This is a partial list of the technologies used by / relevant to the playground. You do not need to know all of these to be able to contribute, but the more you know the quicker you will be able to come up to speed.
- Web Frontend
- Async (Tokio)
- GitHub Actions
If you are interested in contributing to this feature, please reach out here or on Discord, Zulip, or Mastodon and we can work out further details. Let me know a bit about your experience and why working on this would be interesting.
In the unlikely case that...
- no one is interested, don't despair: I will implement the feature by myself.
- too many people are interested, I'll figure out some way of picking from the candidate pool.
Since we will be working together, it's only fair for you to know a bit about me as well! I've been working with Rust since before 1.0. I've contributed to some Rust-related posts on Stack Overflow and am a professional Rust programmer and trainer through our company Integer32.
I'm a pedantic code reviewer and care about things like small commit size and useful commit messages. I have strong opinions on the way that code should be organized but I am willing to have a reasoned discussion on occasion.
Maybe this feature isn't interesting to you, but contributing to the playground is? If so, and depending on the success of this first phase, there are a number of areas I'd like to investigate next:
- Codename: Jackrabbit. Experiment with using the work done for Marathon to increase the speed of traditional playground requests.
- Codename: Cabinet. Allow creating multiple modules and crates as distinct files.
- Codename: Micromanage. Allow modifying detailed compilation settings.
- Codename: Annals. Add historical versions of the compiler.
- Codename: Providence. Allow interactive sharing of the editing experience.
I'll post a similar message in the future when one of these projects is ready to start.
Because it runs for a long time, get it? ↩︎