3 ms·

Primary maintainer of the Rust Playground here. I'm glad to see open source doing the open source thing! I'll try to answer any questions from the Rust point o

Primary maintainer of the Rust Playground here. I'm glad to see open source doing the open source thing! 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.

emccue 3y ago
The biggest differences that I can think of right now are - 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.
- shepmaster 3y ago
  > Its not using the whole orchestrator...thing 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.
  - Macha 3y ago
    > 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.
  - emccue 3y ago
    All the traffic from today was handled pretty soundly by a t2.medium, but noting that for later.
silenced_trope 3y ago
Noob-ish here: 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 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?
- pitaj 3y ago
  For Rust, the issue is that LLVM is very difficult to compile for wasm, but cranelift can't generate wasm. I'm not sure if codegen-gcc can help here.
- shepmaster 3y ago
  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 https://github.com/rust-lang/rust-playground/issues/374 - Compile Rust Language Server into WASM https://github.com/rust-lang/rust-playground/issues/357 https://github.com/rust-lang/rust-playground/issues/357
da39a3ee 3y ago
Off-topic, but I'd like to thank you for your numerous amazing stackoverflow answers about Rust.

emccue 3y ago

The biggest differences that I can think of right now are - 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.

shepmaster 3y ago
> Its not using the whole orchestrator...thing 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.
- Macha 3y ago
  > 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.
- emccue 3y ago
  All the traffic from today was handled pretty soundly by a t2.medium, but noting that for later.

silenced_trope 3y ago

Noob-ish here: 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 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?

pitaj 3y ago
For Rust, the issue is that LLVM is very difficult to compile for wasm, but cranelift can't generate wasm. I'm not sure if codegen-gcc can help here.
shepmaster 3y ago
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 https://github.com/rust-lang/rust-playground/issues/374 - Compile Rust Language Server into WASM https://github.com/rust-lang/rust-playground/issues/357 https://github.com/rust-lang/rust-playground/issues/357

da39a3ee 3y ago

Off-topic, but I'd like to thank you for your numerous amazing stackoverflow answers about Rust.