We made a fork of the Rust Playground | Hacker News Reader

We made a fork of the Rust Playground

java-playground.com

99 pointsemccue37 comments

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.

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.

> 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.

> 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.

All the traffic from today was handled pretty soundly by a t2.medium, but noting that for later.

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) 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?

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.

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

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

Wow I've been out of the Java game too long it seems. This barely looks like Java.

yeah. The snapshot of Java in my head still needs main() to be defined in a class.

Some of these are preview features (main outside a class, string interpolation) and need a command line switch to enable, and can change. But they should be in Java by the next LTS release.

That's good to know; thank you! I had exactly the same reaction as junon!

Looks quite nice.

If we are already by feature requests,

- JVM bytecode view

- JIT machine code view

- Select between OpenJDK, OpenJ9, Azul, GraalVM,...

- Enable code generation specific features per selected JVM implementation

Anyway only brainstorming some ideas, it is already quite nice as it is.

Set a timer for a few days for me to clean up the documentation and whatnot then I am down.

Thanks for working on this. I'd love to see those new features and if I can I'd like to help.

[Shameless plug]

We have just renewed our fully-client side take on the "Java playground" concept, powered by CheerpJ

https://javafiddle.leaningtech.com/

AWT and Swing apps work as well, which I believe to be quite unique.

That is still Java 8, right?

(I do really like CheerpJ if only because it enables software preservation.)

Correct, but the new CheerpJ 3 archicture will let us move quite quickly to modern Java versions.

3.0 will still be focused on Java 8, with a fully new JIT architecture that does not require any AOT compilation steps or preprocessing.

With 3.1+ will begin catching up with modern Java.

A big mistake about all these Playgrounds is that it forces the "Source Code Pro" monospace font (or any specific font) rather than respecting user's monospace font choice in the browser. Programmers tend to be picky about the font choice, which you can easily judging by just how many these fonts are out there competing. There is really no aesthetic reason to do such a forcing, and even you do have political or financial reason to do so, it's extremely easy to block remote font anyway. So stop doing it please, or at least provide a checkbox to disable it.

Sorry, this is a field I have not thought about maybe ever.

What is the thing you want me to do?

github link here: https://github.com/McCue-Software-Solutions/java-playground

huh, Java can just do "void main" now? or is the playground omitting some boilerplate? that was one of my main reason for never touching Java/C#, too much ceremony just to write a basic program.

C# allowed to write main-less applications for quite some time: https://dotnetfiddle.net/oGnV4m

I wouldn't say two years is "quite some time", but yeah that's cool

It is a preview feature right now, so the playground is adding --enable-preview. (there is a toggle for that.)

java --enable-preview Main.java

Things generally exit preview after ~2 releases.

so the example is misleading regarding the current non-preview release, got it.

Yeah, though it’ll probably be non-preview in six months, so if that’s what’s holding you back you don’t have long to wait.

My corpo firewall is blocking because of what seems to be a TLS issue.

Issued by Let's Encrypt on Saturday.

Oof. Hopefully its just because the cert was issued recently?

I'm guessing this is the fork https://github.com/bowbahdoe/java-playground

Actually the one on McCue-Software-Solutions is the right one. I might move it there soon-ish though.

This was done as a senior project @ University of Central Florida. Using the github org made things simpler for the students to work on it. (Everyone has to learn git at some point.)

So for people (like me) who were surprised by how modern the Java code looked like… here are the following features/JEPs involved in the Java code:

Finalized features:

- JEP 395: Records, finalized in Java 16: https://openjdk.org/jeps/395

- JEP 409: Sealed Classes, finalized in Java 17: https://openjdk.org/jeps/409

- JEP 441: Pattern Matching for switch, finalized in Java 21: https://openjdk.org/jeps/441

Preview Language Features:

- JEP 430: String Templates, preview language feature since Java 21: https://openjdk.org/jeps/430

- JEP 445: Unnamed Classes and Instance Main Methods, preview language feature since Java 21: https://openjdk.org/jeps/445

I'm happy that JEP 441 was added to Java.

    // As of Java 21
    Integer i = ...
    switch (i) {
        case -1, 1 -> ...                   // Special cases
        case Integer j when j > 0 -> ...    // Positive integer cases
        case Integer j -> ...               // All the remaining integers
    }

I should stop to talk badly of Java based on my old memories of Java 6... Maybe they should do like C++ and call it modern Java.

wait, is it actually called a JEP (like the Java version of a Python PEP)?

YEP

Reply on news.ycombinator.com