Two builds of the same app, “identical” in every code review, that quietly disagree about one number. The C++ version rounds down; the JavaScript version rounds to nearest. Both pass their tests. One user finds it six weeks later.
That gap is why Haxe exists. Whether anyone still buys the guarantee a compiler gives you is 2026’s question, now that AI made writing code cheap.
Haxe was released in 2005 by Nicolas Cannasse and still ships (4.3.7 on 9 May 2025; a 5.0 preview on 4 July 2025). Its promise: write once; a compiler turns it into JavaScript, C++, Java, PHP, HashLink and more. Haxe is alive. The question: does its problem still exist now that a model writes five languages from one paragraph?
The promise was labour, not correctness #
Haxe’s documentation reaches for time: the language exists so you can “maintain a single code-base which compiles to multiple targets,” and the benefit is that this “ultimately [saves] time and resources.” That is the product — saved effort, because maintaining the same logic in five languages is expensive. Its type system also “can detect errors at compile-time which would only be noticeable at run-time in the target language,” but that was second-order; the headline was always write it once.
Haxe leads a family defined by translation: Kotlin Multiplatform (Kotlin to JVM, native, JavaScript, Wasm), Fable (F# to JavaScript, and since version 4 to TypeScript, Rust and Python), Scala.js, Nim — different syntaxes, one idea: the abstraction lives in a compiler.
One source, or two that merely agree? #
One Haxe file, several runtimes:
#if js
return js.Syntax.code("Date.now() / 1000");
#elseif sys
return Sys.time();
#end
The #if is not a copy. It is a compile-time branch inside one type-checked program: same signature, callers and tests on every target. Ask a model for “the current time in JavaScript” and “the current time in Java” and you get two files that never mention each other — both correct, nothing proving they stay correct together. One verified source versus a pile of plausible partners — that is the seam this argument runs on.
The abstraction is moving up a level #
Typed compilers demand that you supply the source. A model removes that requirement too: supply intent in plain language, get code in any target. Surveys treat “generate new implementations from natural-language requirements in one or more target languages” as a standard task, and agent frameworks are built for cross-language generation. Once the model is the abstraction layer, the compiler’s monopoly on “write once, target many” is gone: you no longer need a single source language when you have a single source description.
The evidence: SWE-PolyBench evaluates repository-level tasks across Java, JavaScript, TypeScript and Python — 2,110 instances, 21 repositories. Orchestrators plan, build, test and cache across monorepos that “mix any combination of ecosystems — Go, Rust, Python, Ruby, PHP, JVM (Maven and Gradle), .NET, and the whole TypeScript/JavaScript family.” That makes one language to target many platforms a workaround for a constraint that stopped binding.
What the model cannot do #
That argument fails in a checkable place: translation is a semantics exercise, not a syntax one, and semantics don’t survive translation for free — compilers themselves have bugs here.
Take the JVM. Kotlin, Java, Scala and Groovy interoperate there, yet differ in type systems, nullability, generics, variance rules and method dispatch. CrossLangFuzzer attacks that boundary: 24 cross-language compiler bugs in its 2025 paper, 32 in its 2026 report, and it says compilation “must reconcile semantic discrepancies among languages.”
Or WebAssembly. Research across 115 open-source codebases found compilers cross-compiling C/C++ to Wasm “do not necessarily preserve code semantics when cross-compiling high-level language code into WebAssembly” — different standard libraries, unsupported system calls and compiler bugs, some silently changing a binary’s meaning. Silent divergence, not a crash.
Hand that to a model. A study of LLM code translation — 6,164 programs, five languages, three models including GPT-4o — is quoted for “fully automated code translation remains unreliable in practice.” Many reported failures are false, from broken evaluation harnesses; but its conclusion stands: the rest are “genuine translation limitations that reflect the inherent difficulty of cross-language semantics.” You can get labour from a model; you cannot yet get assurance.
The guarantee is the product now #
Yes, AI made the writing cheap. It did not make the proof cheap. A compiler only ever sold the second: write a program in Haxe, compile it to C++ and JavaScript, and you get two binaries provably the same program, because one source was transformed under defined semantics. Ask a model for “the same app” in both and you get two programs that look the same and might not be — the quiet kind that passes tests until a user finds it.
When AI generates a lot of code, a compiler-verified single source of truth becomes infrastructure: the more a model writes, the more you need something that can verify equivalence. The labour got cheap; the guarantee did not. Write-once languages aren’t selling “you type less”; they’re selling “your three platforms cannot silently disagree.” Kotlin Multiplatform’s marketing follows this logic — its reasons to adopt lead with reliability, and adoption more than doubled in a year, from 7% to 18% of surveyed developers. Haxe’s strongest ground is the same shape: games and engines, where one logic must run identically on console, phone and browser.
The double squeeze #
The models that make polyglot writing cheap are biased toward the languages they have seen most. A 2025 study calls this the “Matthew effect” of AI programming assistants: Python gets disproportionately strong support, while for low-resource languages “failures are dominated by compile errors.” Its conclusion: AI support “may accelerate [popular languages’] dominance while marginalizing niche languages, regardless of their technical merits.”
The skew is large: in Stack V2, ten of 619 programming languages account for over 90% of the code; Haxe lives in the long tail. MultiPL-T and Agnostics, a language-agnostic post-training pipeline presented at ICLR 2026, exist because OCaml, Racket, Lua, Julia and Fortran need manufactured training data to be usable by code models at all. No comparable effort targets Haxe.
Steel-man the other side: models keep improving at cross-language semantics, and equivalence can be checked without a shared source — generate both implementations and differential-test the pair. If that closes the gap, the guarantee is worth far less than this essay claims. It has not closed yet: the fuzzing and Wasm results above are 2025–2026 work, and differential testing still needs a harness someone maintains. But the trend runs against Haxe — and that is the strongest case against it, stronger than the labour one.
So Haxe’s labour-saving half is competed away by models that write five languages from one prompt, and those models are worst at Haxe. The honest case against Haxe isn’t that it’s bad; it’s that the market it was built for is served by something that barely notices it.
A language built to solve human problems still makes sense — but not the problems Haxe was hired for. The half that dies is the typing you save; the half that survives is the guarantee you own, moving from productivity multiplier to verification layer. Haxe makes sense where the guarantee beats the labour: engines that must behave identically across native targets, libraries with one implementation and many runtimes. It stops making sense where the labour was the point. Twenty years ago Haxe asked: why write it five times? In 2026 you might not write it even once — but you’ll still need to prove the five versions agree. That is the job the compiler never lost, and the job Haxe is now applying for.
So the practical test is narrow. Keep one verified source where a wrong-but-passing build is expensive — engines, cross-target libraries, anything with a console or a phone in its matrix — and let the model write each target separately where the labour was the point. Then do the thing neither a compiler nor a model does for you: run the versions against each other and check they agree.
References #
- Haxe — What is Haxe? (single codebase, multiple targets)
- Haxe — downloads and release notes (4.3.7; 5.0 preview)
- Wikipedia — Haxe (Nicolas Cannasse, 2005)
- HaxeFlixel andflixel on Haxelib
- Kotlin Multiplatform — Ten reasons to adopt KMP (7% → 18%)
- Fable documentation (F# → JS, TypeScript, Rust, Python)
- Rashid et al. — SWE-PolyBench (2,110 instances, 21 repos)
- bento — monorepo orchestrator
- CrossLangFuzzer and an earliercross-language study
- Reusing Legacy Code in WebAssembly (115 codebases)
- False Failures in LLM-Based Code Translation (6,164 translations)
- The Matthew Effect of AI Programming Assistants (low-resource compile errors)
- Cassano et al. — MultiPL-T
- Boruch-Gruszecki et al. — Agnostics , ICLR 2026 (Stack V2: 10 of 619 languages >90%)