Technical introduction
A plain answer, then the engineering underneath it -- what Quaryn actually is, and why each piece of its design exists.
One idea runs through all of it: a program must declare what it is allowed to touch before it can touch it.
That principle is central to Quaryn, and it becomes especially important as more code is generated, modified, or assembled by automated tools. AI coding assistants and automated pipelines can produce changes faster than any developer can realistically inspect line by line. In that environment, being able to look at the top of a file and immediately see whether the program can access the network, read local files, or spawn background work is more than a convenience. It becomes part of the language's safety model.
Overview
Quaryn takes the parts people love from Rust, Go, Python, and JavaScript and folds them into one clean design. Every line below is one of those parts.
Ownership is where Quaryn's whole safety model
starts -- kept, while its hardest part (lifetimes) was
deliberately dropped. Exhaustive match means a
match over an enum must handle every variant, so the
compiler catches a forgotten case instead of a crash finding it
later. Result & ? makes error handling an
ordinary return value threaded with one operator, not a separate
exception channel.
Explicit, up-front types and structural interfaces (a type satisfies an interface by shape, not by declaring it) -- Go's bet that readable, boring code beats clever code, applied the same way here. Concurrency arrives the same way: spawn a task, pass values through channels. Quaryn adds one safety property of its own -- a closure cannot capture a reference, so background tasks cannot race through shared borrowed memory.
Low-ceremony syntax: no semicolons, and
f-strings (f"hi {name}") instead of
manual string concatenation. Python's readability without changing
what the language is allowed to do underneath. The
REPL (quaryn repl) is the same idea
applied to the whole workflow: type an expression, see its value,
no compile-run cycle to try something small.
Arrow closures (x => x * 2) for
short inline functions, and
JSON as a language type that participates
directly in pattern matching, not a library bolted on afterward.
Destructuring (let { name, age } = p) pulls fields out of a value by shape, the same way it reads in
modern JavaScript.
None of these languages was imported wholesale. Each contributes one specific, deliberate idea, and the second-class-reference rule described later is what allows all four to coexist as parts of one coherent language rather than four different languages awkwardly stitched together.
Classification
In the usual taxonomy of programming languages -- scripting languages, logic languages, functional languages, systems languages, and so on -- Quaryn belongs most naturally alongside Rust, Go, and C++ as a systems programming language. The term does not have one rigid definition, but it generally describes languages designed for building software where performance, predictable behavior, explicit types, and close control over system resources matter.
That puts Quaryn firmly in the systems-language category. Where it differs is in the choices it makes within that category: how the same program can be executed through multiple engines, and how Quaryn provides direct memory control without making safety depend entirely on programmer discipline. Those are the parts that make Quaryn distinctly Quaryn, and both are covered below.
Execution
Most languages pick a lane: either you write code that gets translated once into a fast native program (C, Rust, Go), or you write code that gets read and executed on the fly by another program (Python, Ruby, JavaScript in a browser). Quaryn refuses to pick. The exact same source file can run on three different engines, and Quaryn's own test suite requires all three to produce byte-for-byte identical output for the same deterministic test programs before anything ships.
Reads your program's structure directly and executes it step by step, the most literal and easiest-to-verify way to run code.
This is the reference engine -- the one whose behavior is trusted first, and everything else is checked against it.
Compiles your program into a compact set of low-level instructions first, then runs those. It carries every part of a program the native tier cannot take, so it is running in some form on almost every execution.
Faster than the interpreter, and portable: the same bytecode runs
unmodified anywhere Quaryn is installed. Run it on its own with
--no-native.
Compiles eligible functions straight into real machine code using Cranelift (a compiler backend also used by other production language projects), for maximum speed. This is the default: it is what runs unless you ask for another engine.
The fastest of the three on compute-heavy code. It is a tiered backend rather than a whole-program compiler -- functions it can take are compiled, and everything else stays on the VM, so the two work together on a normal run.
Why go to the trouble of building three engines instead of one? Because it turns "we tested this" into something checkable, not just claimed. Every time a change is made to Quaryn, an automated test runs the entire test suite through all three engines and refuses to accept the change unless every expected output matches exactly. If the fast, machine-code version of a program ever disagreed with the slow, easy-to-read interpreter version, that would be treated as a serious bug, not a rounding difference -- and the tests are built to catch it immediately.
Measured
Four workloads, run on Quaryn's three engines and on the four languages Quaryn draws from. Every implementation is a direct translation of the same algorithm, and on the first three workloads all seven produce byte-identical results, so this is a comparison of implementations rather than of different programs.
| Workload | Run | Quaryn native | Quaryn VM | Quaryn interp | Rust | Go | Python | JavaScript |
|---|---|---|---|---|---|---|---|---|
|
Number crunching a tight math loop |
Claude | 2 | 317 | 771 | 2.0 | 2.4 | 382.9 | 57.2 |
| Codex | 2 | 326 | 766 | 2.1 | 2.4 | 384.2 | 53.7 | |
|
Working through a list build it, then read it back |
Claude | 7 | 169 | 372 | 2.4 | 5.4 | 213.3 | 34.7 |
| Codex | 7 | 164 | 359 | 2.4 | 5.5 | 209.2 | 34.4 | |
|
Hammering a lookup table 150,000 key lookups |
Claude | 64 | 80 | 143 | 3.3 | 4.2 | 66.1 | 21.8 |
| Codex | 68 | 80 | 139 | 3.3 | 7.0 | 65.0 | 26.9 | |
|
Chewing through JSON 0.49MB, decoded and re-encoded |
Claude | 58 | 58 | 57 | 17 | 43 | 60 | 30 |
| Codex | 58 | 58 | 57 | 16 | 42 | 62 | 31 |
Milliseconds, lower is better. Quaryn native is the default engine -- it is what runs unless you ask for another. Every workload is listed twice because it was measured in two separate runs; see below.
What kind of benchmark this is. Each program times itself from the inside and reports the median of 20 runs after three warm-up passes, so process startup and JIT compilation are excluded rather than averaged in. These are single-threaded compute and data-structure workloads, not a web-server or concurrency benchmark.
Every implementation computes the same answer. The
first three workloads each print a checksum, and all seven
implementations agree exactly: 748681584,
301738075200, and 450191. That check is
what makes the row comparable; without it, a faster time can simply
mean less work was done.
Everything runs on signed 64-bit integers. Quaryn's
Int is signed and has no unsigned counterpart, so the
Rust, Go, Python, and JavaScript versions were written to match:
signed 64-bit arithmetic that wraps on overflow, with the same
normalization applied afterward. An earlier version of these
fixtures let the other four use unsigned arithmetic, which needs one
fewer operation per step and produced different checksums; that
comparison was not valid and the numbers here replace it.
There is no checksum for the JSON row. Unlike the first three workloads, those programs do not print one, so we cannot prove every implementation produced identical output the way we can above. Treat that row as less rigorously verified than the others.
Where Quaryn loses. Rust is faster on every workload except the tight math loop, where it and Quaryn's native tier are level. Lookup tables are the weak row: Quaryn is far behind Rust, Go, and JavaScript there, and only about level with Python -- a known cost of how map access allocates, and the reason the native tier barely helps it. On JSON, Quaryn is slower than Rust, Go, and JavaScript, and again about level with Python.
Two separate AI-assisted runs. The benchmarks were run twice: once by Anthropic's Claude, which wrote the fixtures, and then again from scratch by OpenAI's Codex, which was given the programs but not the results. Codex rebuilt the Rust and Go binaries itself, reran every row, and audited all five implementations against each other line by line looking for any algorithmic difference that would make the comparison unfair. It found none, confirmed all three checksums, and reproduced the same ordering. Rather than ask you to take that agreement on faith, the table shows both runs on every row. The differences between them are the ordinary spread of repeated measurement, and they are the best guide to how precisely any single figure here should be read.
The machine. An AMD Ryzen 9 7950X3D running Debian 12 on Linux 6.1, on bare metal rather than in a virtual machine -- worth stating because virtualization adds timing noise that would widen every figure here. No GPU is involved: these are CPU-only, single-threaded workloads.
Versions. Every language was measured on its
current stable or LTS release, not on whatever the operating system
happened to ship: Rust 1.98.0 (built -O), Go 1.27.0,
Python 3.14.7, Node 24.19.0 LTS, and Quaryn release builds at
commits d51eb26 and 00e9441, which differ
only in command-line help text. Python was built from source because
no official binary exists for Linux; it uses the same plain
-O2 and computed-goto configuration Debian uses for its
own Python, and no profile-guided optimization, so the build is not
tuned in either direction. Measured 2026-08-23.
Memory safety
Every program that runs constantly creates data in memory: strings, lists, numbers, structures. Something has to decide when each piece of that data is no longer needed and can be freed, and getting that wrong in either direction is a real problem. Free memory too late, or never, and a long-running program slowly consumes more and more memory until it crashes -- a leak. Free it too early, while something else still expects to read it, and you get crashes or, worse, security holes that attackers specifically look for (this class of bug, "use-after-free," is one of the most exploited categories in real-world software).
Most popular languages solve this with a garbage collector: a background process that periodically scans memory, finds data nothing is using anymore, and frees it for you. It's why Python, Go, and JavaScript feel easy to write -- you rarely have to think about manual memory management. The cost is that the collector has to run while your program is doing real work, which can introduce brief pauses and extra memory overhead that are hard to fully predict or control, which matters for anything latency sensitive: a server handling thousands of live connections, for example.
Rust solves it the opposite way: no tracing garbage collector. Instead, ownership and borrowing rules are checked at compile time, and values are dropped deterministically when their owner leaves scope. The rule underneath it is that every value has exactly one owner. The catch is that real programs also need to lend data around without handing over ownership, and proving that a loan never outlives what it's borrowed from is what lifetimes are for -- and lifetimes are widely regarded as the single hardest thing to learn in Rust, often taking months to become fluent with.
Quaryn keeps Rust's no-garbage-collector approach and its deterministic, provable safety, but removes lifetimes from the language entirely, by making one restriction: a reference (a temporary loan of some data) can only ever be a function's parameter or an immutable local variable inside a function body. It can never be stored inside a data structure, returned from a function, or captured inside a closure. In practice, this means a loan can never leave the block of code it was created in -- so the compiler never has to reason about how long a loan is allowed to live across different parts of a program, because it structurally cannot escape in the first place. That single rule preserves the core safety benefit Quaryn is after -- preventing borrowed data from outliving what it refers to -- while removing the need for general-purpose lifetime annotations.
A function cannot return a reference into data it was only lent (with one narrow, checked exception for the common "give me a piece of what you were handed" pattern). A data structure cannot hold a reference as a field. A closure cannot capture a reference from its surrounding code, which is also why background tasks cannot race through shared live references: those references are structurally prevented from being captured in the first place.
This is enforced by the compiler before your program ever runs, not by a runtime check, a warning, or a convention that a programmer could accidentally violate.
Readability
A language's safety model matters most when a person is actually reading and writing the code, so Quaryn borrows its surface appearance from languages people already know rather than inventing new symbols to memorize.
| Trait | Borrowed from | What it means for a reader |
|---|---|---|
| Curly-brace blocks | C, Java, Go, Rust | Function and block boundaries look the way they do in almost every mainstream language already. |
| Explicit, up-front types | Go | A function's signature tells you exactly what it accepts and returns without having to read its body. |
| Low-ceremony statements | Python |
No semicolons to remember, and
f"text {value}"-style string formatting instead of
manual concatenation.
|
| Arrow closures | JavaScript |
Short, inline functions like x => x * 2 read the
same way they do in web code.
|
The goal is that a working programmer coming from any one of those four languages can read a Quaryn function on first sight and correctly guess what most of it does, before ever opening a manual.
Security architecture
Most languages let any piece of code reach the network, read files, or read environment variables the instant it calls the right function, with no way to know in advance what a program is capable of without reading every line of it. Quaryn takes a different approach, borrowed from the idea of "capabilities" in security engineering: a Quaryn file has to declare, at the very top, which categories of outside access it intends to use.
uses [net]
fn fetch_price(url: String) -> Result<String, String> {
http_get(url)
}
The categories are net (talking to the network),
fs (reading or writing files), env
(reading command-line arguments or environment variables), and
threads (running background work). If a file calls a
function that needs one of these and hasn't declared it, the program
simply fails to compile -- it never gets the chance to run. This is
checked at compile time, the same moment types and syntax are checked,
not something verified while the program is already running.
Quaryn is also designed to be embedded inside other applications -- run constrained, or semi-trusted, code as a small scripted piece of a larger program. In that setting, the host application can grant a Quaryn program zero capabilities before it ever runs: no network, no filesystem, no environment access, no background threads. A program compiled under those conditions cannot reach any of those things, full stop, because the functions that would let it are unreachable at compile time -- there's no runtime toggle to defeat and no code path that quietly bypasses the check.
This is also what makes the design useful for automation. When code is generated by a pipeline or an AI assistant, far more of it gets written than gets read closely. A capability header turns "what can this actually do?" into a question answered by the first line of the file rather than by auditing every line of it -- and the compiler, not a reviewer's attention span, is what enforces the answer. A generated script that quietly reaches for the network does not slip through; it fails to build.
Worth being precise about the boundary: this is authority isolation, not resource isolation. A program with zero capabilities still has ordinary CPU and memory available to it, so it can still be slow or resource-hungry. What it cannot do is reach outside itself.
Add-on libraries
Quaryn ships a small set of cryptography functions directly in the language, the same way it ships JSON handling and an HTTP client. The design rule behind all of them is deliberately narrow: Quaryn never invents its own cryptography. Every function is a thin wrapper around established open-source cryptographic implementations of widely scrutinized, industry-standard primitives -- the same category of code that underpins a large amount of production software already running today.
| Function | What it does | Built on |
|---|---|---|
sha256(text) |
Produces a fixed-length fingerprint of any text -- the same input always produces the same fingerprint, and changing even one character changes it completely. | RustCrypto's sha2 |
hmac_sha256(key, text) |
Like a fingerprint, but one only someone holding the matching key could have produced -- used to prove a message wasn't tampered with. | RustCrypto's hmac |
crypto_keygen() / encrypt /
decrypt
|
Locks and unlocks a piece of text with a secret key, so it can be safely stored or sent and only read by someone with that key. |
RustCrypto's chacha20poly1305 (XChaCha20-Poly1305)
|
sign_keygen() / sign /
verify
|
Lets someone prove a message genuinely came from them, without revealing their private key -- the same idea behind a signature on a document. | ed25519-dalek (Ed25519) |
A few choices here are worth stating explicitly, because this is exactly where a little flexibility can make it surprisingly easy for a well-intentioned programmer to introduce a security weakness.
There is exactly one way to encrypt, one way to sign, and one way to hash in Quaryn. You cannot select a weaker or outdated algorithm, choose an insecure mode, or misconfigure a parameter, because none of those knobs exist in the language at all. The safe default is the only option.
Locking data with encrypt doesn't just hide it, it also
stamps it with a seal that decrypt checks
automatically. If a single byte of the locked data is altered by
anyone, anywhere, decryption fails outright rather than silently
returning corrupted or tampered data.
Ordinary signature verification, in some implementations, can be
tricked into accepting an unusual kind of key under which a single
signature would validate many different messages at once -- a subtle
flaw most programmers would never think to check for. Quaryn's
verify uses the stricter form of Ed25519 verification
specifically to close that door, so a forged "master key" cannot be
constructed against it.
This was not just a theoretical concern. It was a real issue uncovered and corrected during Quaryn's internal security review -- the kind of subtle cryptographic edge case the language is designed to handle so programmers do not have to think about it themselves.
One caveat is worth stating plainly: Quaryn's cryptographic functions are built on established, industry-standard primitives and widely scrutinized implementations. The Quaryn layer that exposes them has been carefully reviewed internally, but it has not yet undergone an independent professional cryptographic audit.
Where things stand
Quaryn is currently pre-1.0, single-author, and not yet publicly released or distributed. Everything described on this page exists and runs today: the compiler works, all three engines are implemented and continuously tested against one another, and the capability system and cryptographic functions described above are already in place, not roadmap items.
What Quaryn does not yet have is the kind of validation that only broader exposure can provide: independent external security review, a mature package ecosystem, and sustained real-world use.
Future plans include bringing selected Quaryn automation features into PATANYX Browser, extending the same capability-first approach to browser automation and embedded workflows.
The project's brand line is "Four foundations, one language."
Hosted by PATANYX, created by Faye, Founder of EdgeXene LLC. See the Quaryn Intro or the Tic Tac Toe demo.