rust-playground

We already have a starting point: https://play.rust-lang.org https://github.com/rust-lang/rust-playground

> How many users does it serve? I don't really track users, but over the last 24 hours, there were 47.8k meaningful [1] requests taking a total of 28.2 hours. That ~0.5 requests per second number has been relatively consistent. > re-use already compiled binaries of all supported dependencies and only need to compile the user's code and link it, but is there other clever strategies? Yes, we pre-compile all the available dependencies [2] and that's about it. > I use it all the time with no performance issues That's good to hear! There's been a long-running bug where the playground binary loses track of the child Docker container (maybe?) and then the machine runs out of memory and the OOM killer often does more harm than good [3]. While trying to pin that down, I've recently caused the entire process to get into what appears to be a complet

(Rust playground maintainer here) Incidentally, I also updated the Rust playground today. My usual process is to update everything [0] that is SemVer compatible and then one-by-one update packages with SemVer incompatible version bumps. During the upgrade, I was thinking to myself how generally I’m fairly blasé about these updates — I don’t even attempt to build the code with the SemVer compatible updates because it’s so rare for a crate maintainer to stuff up such an update. The SemVer incompatible updates get a build just as a sanity check. Contrast this to the JS dependencies where an upgrade tends to instill more dread in me. Part of this is a lack of confidence in my test suite, part of it is that it’s the more UI heavy component which is hard to write tests for in the first place, but a non-zero part is my lack of trust in the JS li

I think that yes, it's technically possible with a good amount of work at all layers of the stack. The bigger worry I'd have is purely about time. The Docker images for the Rust playground clock in close to 2 GiB, and there's 3-6 of those. No one is going to wait to download that to run a small program. Now, because no one has put in all the work to make it happen, I don't know if this would be a real problem or not, but I haven't yet heard a comprehensive counter argument. Some related ideas: - Client-side interactive terminal for WASM https://github.com/rust-lang/rust-playground/issues/374 - Compile Rust Language Server into WASM https://github.com/rust-lang/rust-playground/issues/357

Ditto with my journey from Warp to Axum. The Rust Playground now uses[1] Axum as its backend and I’ve been pleased with working with the maintainers. [1]: https://github.com/integer32llc/rust-playground/pull/777

+1 for Axum. I recently moved [1] the Rust Playground's backend to Axum and have been very happy with it and the team producing it. [1]: https://github.com/integer32llc/rust-playground/pull/777

https://github.com/integer32llc/rust-playground is the code for play.rust-lang.org

Code is here: https://github.com/integer32llc/rust-playground > Does anybody know? Yes, there's no branching for gists, but there are saves. If you hit "Share", you get various options: * Permalink to the playground <- this creates a gist. URL is the gist hash. * Direct link to the gist <- this gives you a link to the gist * Embedded code in link <- this URLencodes the source and puts it in a parameter * Open a new thread in the Rust user forum & Open an issue on the Rust GitHub repository <- hopefully self-explanatory

Hm, seems like they both just use docker's sandboxing parameters (https://github.com/rust-lang/rust-playpen/blob/master/src/do... , https://github.com/integer32llc/rust-playground/blob/master/... ). The official one used to use libseccomp, but it doesn't anymore. They probably should use https://github.com/servo/gaol (should be drop-in) or seccomp , I'll file issues. IIRC they're on their own dedicated instances.

Interesting. Rust has two playgrounds (official: https://play.rust-lang.org/, unofficial: http://play.integer32.com/), and each is a completely different bit of open-source software (https://github.com/rust-lang/rust-playpen , https://github.com/integer32llc/rust-playground) They both use docker for isolation, with a bunch of things to make it work. IIRC we haven't had any issues with this. Furthermore, the official playground used to be a third completely different bit of software until it was rewritten in Rust. It also used to use https://github.com/thestinger/playpen. I'm skeptical that the problem will take that much effort since Rust has solved it (to some degree) twice. At the same time, it's likely that Go's playpen does a lot more mitigation, e.g. the time.Now() probably futzes timing attacks. Though in that case they would need t