Look at what it takes to ship a “modern” multi-language application today.
You want a desktop UI, some customizable Python or JavaScript business logic, a fast C or Fortran math routine and a 3D viewport. The industry consensus says: glue together an Electron shell, a local Node.js runtime, a bundled CPython interpreter, CFFI bindings, an external Vulkan SDK toolchain, and probably a Docker container to keep AI-generated scripts from nuking the host OS. You end up shipping 600MB of runtimes to execute 50KB of actual logic.
I got tired of it. So with the upcoming MIMERCode 1.40 and the next beta of the MIMER Polyglot Compiler (MPC) I asked a contrarian question:
What if 10 programming languages, a capability-sandboxed I/O system, a declarative GUI and a Vulkan 3D engine all compiled down to a single, dependency-free native executable? On Windows and Linux x64, on Linux ARM64, and all the way down to a bare-metal ESP32?
That is what I built: my own stack, top to bottom, where the mainstream answer is a pile of other people’s virtual machines. Building it convinced me of something uncomfortable. Our mainstream stacks are far more bloated than they need to be.
1. MimerCode: a language for the “LLM-as-author” era
Most teams using AI to generate code are bolting safety rails onto languages designed in the 1990s. Pydantic or Zod to validate inputs, LangGraph or Effect-TS for retries, and a prayer that the model doesn’t hallucinate an import subprocess or leak a credit card number into a stack trace.
My position: if LLMs are going to write half our business logic, and business analysts are going to read it, then validation, secret sealing and workflow orchestration belong in the language grammar, where node_modules can’t get at them.
Contracts instead of user-space validators. By default, Pydantic and Zod quietly drop unknown fields unless you remember to configure strict mode. In MimerCode a contract is a boundary the runtime enforces. Mark a field sensitive and it is sealed at creation: string interpolation, loggers and crash dumps see **** until an explicit, auditable unseal().
Pipelines instead of async spaghetti. Rather than watching a model produce broken asyncio.gather() loops and retry decorators, you get a native pipeline block with parallel fork branches, step piping (|>), automatic trace IDs and declarative per-step error policies: abort, skip, retry, fallback.
“But LLMs weren’t trained on it.” Correct, and I designed for that. The expression syntax deliberately mirrors Python and JavaScript (f-strings, slicing, lambdas) while replacing fragile whitespace rules with plain end blocks. Add a standard LLM system prompt, MIMERCodex knowledge packs, and an IDE whose fix-with-AI feature re-parses and validates candidate code before you ever see it, and the room for hallucinated code shrinks dramatically.
2. Channels: one door to everything
All I/O in MIMER goes through one URI pattern with two verbs: open("file://..."), open("https://..."), serve("gui://...").
Start with the one every application needs: the GUI. You describe a view once, declaratively, in MimerCode: its state, its widgets, its event handlers. Then you choose how it is served. renderer: "canvas" opens a native desktop window. renderer: "html" turns the same program into a web application: it serves the same views to any browser, every tab gets its own independent session with its own state, and it runs on a headless server where there is no desktop at all. One program can do both at once, a native window for the operator and a browser UI for everyone else. You never write a line of HTML, JavaScript or CSS, and there is no separate frontend project to keep in step with the backend, because there is no frontend project.
Around it sits everything else an application reaches for, each as a channel with the same open / call / close shape:
Data: SQLite, PostgreSQL, MySQL, SQL Server, Oracle, Firebird and InterBase through one db:// interface; Excel, Word and PowerPoint files read and written directly; ZIP archives; reports and printing.
Web and network: an HTTP client and server, SSH and SFTP on my own SSH2 implementation, FTP, raw TCP with optional TLS, encrypted peer-to-peer tunnels, and a self-routing mesh where every node is also a relay.
Messaging: IMAP, SMTP and POP3 mail, Microsoft Graph, Telegram, Matrix and MQTT.
Engineering: a parametric CAD kernel that exchanges STEP, STL, DXF, 3MF and IFC; Modbus, OPC UA and serial for the factory floor; camera, audio and MIDI devices.
Regulated work: authentication with roles, a secret vault, a tamper-evident hash-chained audit trail, an HL7 FHIR client, clinical calculators, unit conversion and translation.
Automation: a scheduler with cron, intervals and one-shot jobs.
That is more than forty channels. A handful of them are engines in their own right:
Scene3D. A Cook-Torrance PBR Vulkan engine with tiled-forward lighting, SSAO, SSGI, SSR, volumetric fog, glTF 2.0 with GPU-compute skinning and a GJK/EPA rigid-body solver. It includes its own GLSL-to-SPIR-V compiler and scriptable GPU compute kernels, so you write shaders and GPU simulations from script without installing the Vulkan SDK or shaderc.
GIS. Shapefiles, GeoTIFF, R-tree indexing, Delaunay/Voronoi triangulation, DEM terrain draped straight into the 3D scene, turn-restricted vehicle routing and marching-squares isochrones, on a scale-continuous frame graph that keeps millimeter precision from orbit down to a tabletop.
Synth. A 64-voice polyphonic modular synthesizer with wavetable, FM and virtual-analog oscillators.
A channel is also as fast as the engine behind it. Your code calls straight into compiled, fully optimized native code that is linked into the same executable as your program. Nothing gets interpreted or serialized on the way.
That matters most exactly where other scripting stacks fall over: 3D and GIS. A renderer has a frame budget of a few milliseconds, and it spends them on culling, skinning, physics and lighting for every object in the scene. A spatial engine walks R-trees, triangulates terrain and routes across road networks. In MIMER that work never passes through a script loop or a marshaling layer. The Vulkan renderer and the GIS engine run at the speed of the machine, and the language driving them, whichever of the ten it is, only says what should happen.
Some numbers, on my own workloads, so you know what “native speed” means here. A generated harbor city of 19,654 objects and 3.3 million triangles, with 256 walking characters, three shadow cascades, SSAO and TAA at 1080p, renders in 6.5 ms a frame on a Ryzen 9 9950X with an RTX 5090. Double the city to 42,664 objects and 7.3 million triangles and every frame still lands inside the 60 Hz budget. A million-agent ecosystem simulation, running entirely in a GPU compute kernel written from script, holds 62 frames a second.
How does that compare? Honestly: this is not Unreal. There is no Nanite and no Lumen. What Scene3D has is the modern core, with forward+ lighting, PBR materials, hardware ray-traced shadows, ambient occlusion and reflections, GPU skinning, rigid-body physics and fracture, in an engine you drive from ten languages and ship inside your own executable. Unity and Unreal are products you build your application inside. Scene3D is a channel your application opens.
The same goes for GIS. It is not PostGIS and it does not try to be. It is the spatial work an application actually needs: exact topological predicates, geodesic measurement, overlay, reprojection with datum shifts, topology cleaning, routing and geocoding, drawn straight into the 3D scene. A typical stack needs a database server, GDAL, PROJ and a routing service to cover that list. Here it is one open("gis://").
Call a model, run it locally, or train it from your app
I wanted to be able to put a GGUF next to my application, open it, and get an answer. Here’s what that looks like in MimerCode:
local Model := open("infer://")
Model.LoadModel("Qwen3.5-9B-UD-Q8_K_XL.gguf")
local Reply := Model.Generate("Explain this error in plain English.",
dict{ "max_tokens": 128 })
println(Reply["text"])
close(Model)
That’s my own tensor engine running the model on CPU or Vulkan, without Python or llama.cpp in the inference path. And Qwen is one example. The native engine is verified against llama.cpp on 132 GGUF architectures, including variants of Llama, Qwen, Gemma, Mistral, DeepSeek and GPT-OSS, plus encoders for embeddings and reranking. An architecture it has not been verified on is refused by name instead of answered wrong.
I use llama.cpp as a reference because I care whether the engine gets the answer right. In my tests, chat templates matched byte for byte across 40 model families, and all 300 schema-constrained responses validated across three models. On an RTX 5090, infer:// took Gemma 4 31B from 52.3 to 98.9 tokens per second with an EAGLE3 draft head, producing the same tokens as plain greedy decoding. On Qwen3.8 Flash Next, it hit 36 tokens per second on a 32 GB card, about 9% above the reported result from a llama.cpp fork tuned for that workload.
For hosted models I use ai://. I can switch from Anthropic to OpenAI, Gemini, Ollama or a configured OpenAI-compatible endpoint by changing the URL. The same client handles chat, tool calls, speech and image generation where the provider supports them. The channel can read a key from the vault without handing the key back to the script. And when I want to move an agent from a hosted model to a local GGUF, infer:// in chat mode speaks the same tool-calling protocol.
Then there’s train://, which is the part people usually ask me to demo. It can train classifiers, regressors and sequence models from scratch on CPU or GPU. It can also fine-tune GGUF language models whose training graph is supported. In one run, I fine-tuned Qwen2.5-Coder-7B on MimerCode source. Before training, it answered with C-style braces. After two epochs, it wrote end where it belonged, and perplexity on five held-out files fell from 4.197 to 3.367.
I can run that workflow from my application, evaluate the result, and export a GGUF I can ship. That’s the part I care about. The customer gets the app and the model file. They don’t get a Python setup guide.
Why you may not need Docker to sandbox AI-written code
MimerCode deliberately leaves out eval(), OS-level imports and raw pointers. Everything a script can reach, it reaches through a channel, and every channel is deny-by-default: governed by a security policy file beside the script, role-based access rules, a PBKDF2/AES-GCM secret vault and CPU/memory limits.
You can hand an AI agent, or an end customer, a scripting environment that drives 3D scenes, GIS maps or industrial PLCs, and it gets exactly the files, sockets and devices the policy grants. It is a different layer than a microVM, and for a lot of “let the model write the script” use cases it is the layer you actually wanted.
3. MPC: why I converged on structured Pascal
MPC takes 10 frontends (MimerCode, Object Pascal, C, Python, JavaScript, BASIC, Fortran, Java, C# and CLI/IL) and compiles them into one native binary for Windows x64 or Linux x64. It has its own Linux ARM64 backend. And it has its own Xtensa backend: -target=esp32 produces a bootable image that stands on its own, with neither ESP-IDF nor an Arduino core underneath. My own RTL, scheduler and network stack join WPA2 WiFi, serve TCP, fetch HTTPS and take over-the-air updates on a $5 board. RISC-V for the ESP32-C series is under way: the assembler is done and a C3 image already boots.
LLVM is nowhere in that chain. The code generators, assemblers and linkers are mine.
How that compares to the usual polyglot answers:
GraalVM: Truffle graphs on a large JVM, a heavyweight polyglot context API for cross-language calls, and a JVM or a big native image to ship.
LLVM / Clang / Rust: a low-level SSA IR that erases high-level types down to the C ABI. Cross-language means extern "C" and pointer marshaling by hand, and you bring your own application platform.
WebAssembly component model: linear memory plus WIT interface definitions, generated bindings, and a runtime host you must ship.
MPC: a structured Object Pascal representation that preserves types, strings, reference parameters and exceptions. Cross-language calling is a source import: import * as math from './shared.bas'. The result runs without an external VM, and the whole channel platform comes with it.
Why hasn’t LLVM given us effortless imports between Python, JavaScript and Fortran? Because LLVM IR is too low-level for that job. By the time a language reaches it, managed strings, dynamic arrays, by-reference parameters and structured error handling have been shredded into raw pointers.
Converging every frontend on structured Pascal keeps those semantics alive across the language boundary. A JavaScript file imports a BASIC or Fortran module by filename and calls its functions with ordinary JS syntax, as directly as it would call its own.
Four words that change what the compiler promises
The native frontends share a small set of annotations that I have missed in every mainstream compiler I have used. Today they work in Pascal, C, BASIC and Fortran. Python is next: the decorators are designed, and they will apply to the same typed functions that already make compiled Python fast.
parallel for says the iterations of a loop are independent, and the compiler checks that claim before it spreads them across worker threads. A shared accumulator or a jump out of the loop is refused at its line. You don’t get a data race to find in production.
[gpu] on a routine goes one step further. Its parallel loops are also compiled to SPIR-V, and when the machine has a Vulkan device the loop runs there. Without a driver, or with a range too small to be worth the trip, it runs on the worker threads and tells you so once. There is no shader to write and no second language. In BASIC:
[gpu]
Function Fill() As Long
Dim values(8191) As Long
Parallel For i As Long = 0 To 8191
values(i) = i + 1
Next i
Return values(8191)
End Function
The same thing in Fortran, where the annotations are comment directives, so the file is still ordinary Fortran to any other compiler:
!$mimer gpu
subroutine fill()
integer :: values(65536), i
!$mimer parallel
do i = 1, 65536
values(i) = i * 2
end do
end subroutine
[safe] turns on checked memory for one routine or one pointer. Subscripts are range-checked, and a read through a pointer to a freed block stops the program with the file and line of the access, whichever language allocated the block. This is how you put a guard around the one C function that parses untrusted input without paying for checks everywhere else.
[secure] asks for constant-time code. Every parameter and local is secret unless you mark it [public]. A branch, a memory index or a division that depends on a secret is refused at its line, secure locals are wiped when their scope ends, and the generated machine code is verified afterwards. A constant-time compare in C looks like this:
[[mimer::secure]] int same([[mimer::public]] const unsigned char *a,
[[mimer::public]] const unsigned char *b,
[[mimer::public]] int n)
{
unsigned diff = 0;
for ([[mimer::public]] int i = 0; i < n; i++)
diff |= (unsigned)(a[i] ^ b[i]);
return diff == 0;
}
Secure code compiles for x86-64, ARM64 and the ESP32. It cannot be combined with [gpu], and it does not certify the library calls you make from it. The ESP32 has no thread pool or GPU, so parallel for and [gpu] are refused by name there.
MimerCode itself does not need them. Its concurrency is fork and pipeline, and it has no raw pointers to guard. The managed frontends and JavaScript do not have them yet.
4. “Fine, but is it fast?”
Every frontend compiles ahead of time to native machine code, so a program starts at full speed. And I don’t ask you to take that on faith: every frontend is benchmarked against its own reference implementation. Same algorithm, same inputs, every answer checked, strict floating point on both sides.
Pascal: on my application benchmark suite MPC’s code is faster than Delphi’s overall, by more than a quarter on text and JSON processing, and close to three times faster than Free Pascal’s.
Python: the beta you can download today runs my 12-algorithm numeric corpus 2.5 times slower than CPython 3.13. The upcoming one runs it about 20 times faster than CPython, with CPython’s exact answers. String and dictionary workloads now beat CPython too; code built on closures and generators is still behind it. The compiler proves where a value is really an integer, a float or a string, and compiles that code as if you had written it in a typed language.
C: in the same class as GCC -O3. Some kernels faster, some slower.
Fortran: measured against GNU Fortran at -O3. Call-heavy code is ahead of it, n-body and Mandelbrot are close to level, and the rest of the numeric corpus is within reach rather than on par. The remaining distance is optimizer work that pays out for every frontend.
BASIC: measured against FreeBASIC. Scalar, integer and string code is level with it or ahead. Dense matrix kernels are where FreeBASIC still leads.
JavaScript: compiled ahead of time and measured against Node’s V8, one of the most heavily tuned JITs in existence. String scanning, recursion and branch-heavy code run close to it. V8 still leads on numeric array loops, and the type-proving approach that took Python past CPython applies here too.
The managed frontends (C#, Java, IL): call-heavy code already beats .NET and OpenJDK. Tight floating-point loops are where their JITs still lead, and that is what I am working on now.
Channels: the engines behind them are native code in your binary. For 3D and GIS that is the whole game: per-frame rendering, physics, spatial indexing and routing run at full native speed whichever language makes the call.
The Python figures are from the upcoming compiler. The others are from earlier betas, and I expect most of them to move the same way.
The bar I set is simple: every frontend at least as fast as the tool it replaces. I’m not there on every cell, and I’d rather show you the gaps than a cherry-picked chart.
And because every frontend lowers through the same structured Pascal path into the same optimizer, an improvement there pays out in ten languages at once.
5. The honest trade-off
MPC compiles defined language profiles. If your goal is to pull 1,500 packages from npm or pip install pytorch into a CPython environment, MPC is the wrong tool, on purpose.
Our industry is dangerously addicted to third-party supply chains. We pull in 400 transitive dependencies to render a chart, parse a CSV, validate a schema or talk to a serial port, and then spend half our careers patching CVEs and untangling version conflicts.
I took the opposite bet: one independent codebase, rooted in the Delphi and Object Pascal engineering tradition, that delivers
a 10-language native ahead-of-time compiler,
an AI-safe language with contracts and pipelines built in,
an IDE written in MimerCode itself, with two-way visual designers for GUI, reports and 3D that edit your actual source, and
an AI manual generator that boots your app, screenshots every screen with live data and writes the user documentation as PDF and Markdown.
