{"slug": "polyglot-is-the-new-compiler", "title": "Polyglot Is the New Compiler", "summary": "Haxe, the cross-platform language released by Nicolas Cannasse in 2005 and still shipping with version 4.3.7 on 9 May 2025 and a 5.0 preview on 4 July 2025, faces a challenge to its core \"write once, target many\" promise now that AI models generate code in multiple languages from a single natural-language description. Research cited in the piece shows the compiler's guarantee remains hard to replicate: CrossLangFuzzer found 24 cross-language compiler bugs in its 2025 paper and 32 in its 2026 report, while a study of 115 open-source codebases found C/C++ to WebAssembly cross-compilers \"do not necessarily preserve code semantics when cross-compiling high-level language code into WebAssembly.\" SWE-PolyBench, spanning 2,110 instances across 21 repositories in Java, JavaScript, TypeScript and Python, illustrates the repository-level, multi-ecosystem tasks AI agents now target.", "body_md": "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.\n\nThat 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.\n\nHaxe 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?\n\n## The promise was labour, not correctness\n\nHaxe’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.*\n\nHaxe 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.\n\n## One source, or two that merely agree?\n\nOne Haxe file, several runtimes:\n\n```\n#if js\nreturn js.Syntax.code(\"Date.now() / 1000\");\n#elseif sys\nreturn Sys.time();\n#end\n```\n\nThe `#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.\n\n## The abstraction is moving up a level\n\nTyped 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*.\n\nThe 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.\n\n## What the model cannot do\n\nThat 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.\n\nTake 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.”\n\nOr 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.\n\nHand 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*.\n\n## The guarantee is the product now\n\nYes, 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.\n\nWhen 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.\n\n## The double squeeze\n\nThe 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.”\n\nThe 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.\n\nSteel-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.\n\nSo 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.\n\nA 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.\n\nSo 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.\n\n## References\n\n- Haxe — [What is Haxe?](https://haxe.org/manual/introduction-what-is-haxe.html) (single codebase, multiple targets)\n- Haxe — [downloads and release notes](https://haxe.org/download/) (4.3.7; 5.0 preview)\n- Wikipedia — [Haxe](https://en.wikipedia.org/wiki/Haxe) (Nicolas Cannasse, 2005)\n- [HaxeFlixel](https://haxeflixel.com/) and[flixel on Haxelib](https://lib.haxe.org/p/flixel/)\n- Kotlin Multiplatform — [Ten reasons to adopt KMP](https://kotlinlang.org/docs/multiplatform/multiplatform-reasons-to-try.html) (7% → 18%)\n- [Fable documentation](https://fable.io/docs/index.html) (F# → JS, TypeScript, Rust, Python)\n- Rashid et al. — [SWE-PolyBench](https://arxiv.org/abs/2504.08703) (2,110 instances, 21 repos)\n- [bento](https://github.com/bento-sh/bento) — monorepo orchestrator\n- [CrossLangFuzzer](https://arxiv.org/abs/2606.28132) and an earlier[cross-language study](https://arxiv.org/abs/2507.06584)\n- [Reusing Legacy Code in WebAssembly](https://arxiv.org/abs/2412.20258) (115 codebases)\n- [False Failures in LLM-Based Code Translation](https://arxiv.org/abs/2605.02195) (6,164 translations)\n- [The Matthew Effect of AI Programming Assistants](https://arxiv.org/abs/2509.23261) (low-resource compile errors)\n- Cassano et al. — [MultiPL-T](https://arxiv.org/abs/2308.09895)\n- Boruch-Gruszecki et al. — [Agnostics](https://arxiv.org/abs/2508.04865) , ICLR 2026 (Stack V2: 10 of 619 languages >90%)", "url": "https://wpnews.pro/news/polyglot-is-the-new-compiler", "canonical_source": "https://mielony.com/blog/polyglot-is-the-new-compiler", "published_at": "2026-09-13 00:00:00+00:00", "updated_at": "2026-09-16 18:41:02.836537+00:00", "lang": "en", "topics": ["developer-tools", "ai-agents", "ai-tools"], "entities": ["Haxe", "Nicolas Cannasse", "Kotlin Multiplatform", "Fable", "Scala.js", "Nim", "WebAssembly", "SWE-PolyBench"], "also_reported_by": [], "alternates": {"html": "https://wpnews.pro/news/polyglot-is-the-new-compiler", "markdown": "https://wpnews.pro/news/polyglot-is-the-new-compiler.md", "text": "https://wpnews.pro/news/polyglot-is-the-new-compiler.txt", "jsonld": "https://wpnews.pro/news/polyglot-is-the-new-compiler.jsonld"}}