I'll try to answer any questions from the Rust point of view, and it will be good to hear of any large differences between the two implementations.
- Its not using the whole orchestrator...thing. That was some complex code and we made a Practical Choice.
- No equivalents for a lot of the rust tools. Choices aren't as straightforward as for the cargo/rust world. I do intend to at least add JUnit testing as an option though.
- Its not building things from source, which means I need to manually update download urls every now and then.
- Might not be running on a big enough machine. Lets see if HN hugs it to death.
For further context, the "orchestrator" is a reimplementation of some of the backend.
The original version of the playground basically took the user input, dumped it into a file, then mounted that file into a Docker container and waited for it to be complete — a traditional batch process. This works great, but doesn't allow fun things like streaming input / output from the process, or having temporary files that persist over a short time period.
The new code has a shim program that lives inside the container and we can communicate with it via messages passed on stdin/stdout. Things are a lot more asynchronous and a bit more complicated.
I think it's a reasonable thing to avoid for now, but note that my plan is to eventually remove the current synchronous code eventually.
> I need to manually update download urls every now and then
I do much the same, roughly every 6 weeks or so.
> a big enough machine
The primary instance is a single c5a.large in EC2. I also run my own instance on a single t2.micro.
Wow, I would have assumed it would have required more than that.
It looks like this playground requires a server connection instead of being purely front-end, which makes sense being Java.
But I'm familiar with SWC's playground (https://swc.rs/playground) and I believe it uses WASM and therefore doesn't require a back-end component.
Is it possible to do something similar with the Rust playground and Java playground?
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