How we run 26 languages when we only wrote two runtimes

SyncodeLive runs 26 languages. I wrote real runtimes for two of them. This post explains what happens for the other 24, because the answer is stranger than I expected when I started.

The two real runtimes

JavaScript is easy. The browser already has a JavaScript engine, so running JavaScript means handing it to the engine and capturing what it prints. No server involved.

Python is harder but solved. There is a WebAssembly build of Python that runs entirely in the browser. When you run a Python file, we load that runtime, execute your code in it, and show the output. The common scientific libraries like numpy and pandas come along for the ride. Still no server.

Those two cover most of what people paste in. But I wanted Go, Rust, Java, C, and the rest to work too, and writing or hosting a sandbox for every language is a large amount of infrastructure for a free tool.

The trick for the other 24

When you run a Go program, the code does not go to a Go compiler. It goes to a language model with a specific instruction: act as the compiler, and return exactly what the program would print, including any error messages.

That is it. The model reads the source and predicts the output the way a compiler would produce it.

I assumed this would be a toy. A fun demo that falls apart on anything real. Then I tested it properly.

How well it actually works

For ordinary programs, it is uncannily good. A Go loop with fmt.Println returns the exact lines a real run would print. A Rust program with a borrow-checker error returns the error message rustc would give you, with the right line numbers and the "consider borrowing" hint.

Here is the kind of thing it gets right:

for i := 1; i <= 3; i++ {
    fmt.Printf("request #%d handled\n", i)
}

It returns the three lines, formatted exactly, every time. Deterministic enough to trust for the job it has.

Where it breaks

I am not going to pretend it is a real toolchain. It is not. Here is where it falls down:

• Long-running or stateful programs. It predicts output, it does not actually execute over time. Anything that depends on real timing or real I/O is guesswork.
• Programs that depend on exact floating-point behaviour or large computed tables. The model approximates, and approximation is wrong here.
• Anything that reads files, hits the network, or uses the system clock. There is no system. There is a model imagining what the system would do.

So this is not where you run your production batch job. It is where you show a friend what a snippet does in a language you do not have installed.

Why this is the right tradeoff for the tool

SyncodeLive exists to make sharing code instant. The whole promise is that you do not set anything up. If running Rust required me to host a Rust sandbox per session, the tool would be slower, more expensive, and harder to keep free.

The model-as-compiler approach keeps every language a click away with no setup, and it is good enough for the sharing-and-explaining job that the tool is for. The two languages people run most often, JavaScript and Python, use real execution. The long tail uses the model. That split matches how people actually use it.

I still find it slightly strange that this works at all. But it does, and it lets one person keep a 26-language editor running for free, so I will take strange.