kern v1.0.0-rc1, and what the label means honestly

What "1.0.0-rc1" means, exactly

Two things are true at the same time, and the version number has to carry both of them honestly.

• The implementation is 1.0-grade. Kern compiles itself, the full conformance and negative suites are green, the runtime's concurrency model is race-free under ThreadSanitizer, and the build is reproducible byte-for-byte on the same machine. As a language and a toolchain, this is what a 1.0 looks like.
• The trust program is mid-roadmap. Kern's headline promise is not "it has a nice type system." It is that a binary built with Kern can be trusted not to hide a backdoor, and that anyone can verify that independently. That is a 12-step program, and it is partway done.

The implementation is 1.0-grade

The claim is concrete and each half of it is checkable.

• It self-hosts. The Kern compiler is written in Kern (around 33,000 lines across the src tree) and compiles itself to LLVM IR. The seed binary that bootstraps it is reproducible from public artifacts.
• The full suite is green. 1,009 tests at 100% pass: 768 conformance tests that assert the language does the right thing, and 241 negative tests that assert the compiler rejects the wrong thing. Both gates are CI-blocking. A negative test that passes because compilation merely failed for the wrong reason is itself caught by a dedicated check.
• The concurrency model is race-free. The garbage collector was the last place a data race could hide; that is now closed and ThreadSanitizer-verified (more below).
• The build is locally reproducible. SOURCE_DATE_EPOCH plus a deterministic compiler output stage produce a byte-for-byte identical binary across rebuilds on the same toolchain.

SQL checked against your schema at compile time

Injection prevention already stops a query built from user input from type-checking. 1.0.0-rc1 takes the next step and validates the SQL itself against your declared schema, before the program runs. The whole "typo in a column name" and "migration drifted from the code" class of bug moves from a 500 at 2am to a failed kern build.

• E0310: a statement referencing a table that is not in your schema is a compile error.
• E0311: a SELECT or INSERT naming a column that is not on that table is a compile error.
• E0312: an INSERT whose column list and VALUES tuple differ in length is a compile error.

The checker is conservative by construction: where it cannot see the full column list, it stays silent rather than raise a false positive. Combined with the @sql_literal rule from the injection-prevention work, a Kern SQL statement is checked for both injection safety and schema correctness in the same compile step.

A thread-safe garbage collector

Concurrency is where memory-managed runtimes quietly go wrong. The fix that mattered most for 1.0.0-rc1 was moving the GC's value-root stack to be per-thread, so two threads collecting or allocating at once can no longer corrupt each other's view of the live set. ThreadSanitizer confirmed the race before the fix and confirmed its absence after, and a follow-up pass resolved the environment-config flags once in a constructor to clear the last three residual TSan reports. The result is the "0 data races" number above: not "we could not find one," but "the tool that finds them reports none."

Go-parity foundations in the standard library

A backend language is judged on the boring middle layer as much as the headline features. 1.0.0-rc1 lands the first tier of a deliberate Go-parity effort: the byte and stream spine that everything else composes on.

• std.bytes: a canonical []byte type, the lingua franca for IO that is not text.
• std.buf: a growable read/write byte buffer.
• std.iostream: the Reader / Writer spine, so stdlib code can take "anything you can read from" instead of a concrete file or socket.

Those land alongside the database work that closes a long-standing backend pain point: db.postgres now has parameterised queries, atomic transaction batches, and a connection pool that publishes its own Prometheus gauges (size, in-use, idle, waiting) with a per-query timeout. The standard library is now 110 modules and 1,270 public functions.

Where verifiable trust stands: Steps 2 to 7 of 12

The trust program is a 12-step roadmap, and being honest about a release means being honest about which steps are done. The first seven are, on the machine that built the release:

• Step 1: the Trusted Computing Base is written down. Exhaustively, in TRUST.md: every component a Kern binary must trust, and which step verifies it.
• Step 2: the C runtime TCB is shrunk to an auditable core. The trusted part is named and minimal by construction; new functionality defaults to capability-bounded Kern, outside the TCB.
• Step 3: deterministic compiler output.
• Step 4: reproducible end-to-end binary.
• Step 5: an independent bootstrap path.
• Step 6: a diverse double-compilation gate.
• Step 7: a capability-secure core. All authority-bearing entry points require an explicit Cap<T>; ambient authority is a compile error (E0404).

What stands between rc1 and 1.0.0 final

The remaining five steps are exactly the difference between "trust we can evidence here" and "trust a third party can re-derive." None are aspirational; each has a Done-when clause on the roadmap.

• Step 8: capability provenance and audit tooling. Make a binary's actual grants inspectable and checkable.
• Step 9: sound, whole-program flow analysis. The soundness backing for the privacy and capability claims.
• Step 10: a verifiable supply chain.
• Step 11: formal verification of the trust-critical path. Coq was chosen as the proof assistant (INRIA, EU-native, the CompCert track record); the lexer track is scaffolded.
• Step 12: an independent audit and the verification dossier. Plus turning CI on, so every claim above is re-checked on a machine that is not the author's.

Every item is on the ROADMAP with a checkbox and a Done-when clause. A trust claim with no check is not done.

By the numbers

• 1,009 tests at 100% pass, 768 conformance and 241 negative; both gates CI-blocking
• Steps 2 to 7 of 12 trust-roadmap steps done (locally evidenced); Steps 8 to 12 remain
• 0 data races: the GC is thread-safe, ThreadSanitizer-verified
• SQL schema-checked at compile time (E0310 table, E0311 column, E0312 INSERT arity)
• 110 stdlib modules, 1,270 public functions, across std, data, net, db, sys
• 33,292 lines of Kern in the self-hosted compiler
• 42,191 lines in the C runtime, around 300 FFI bridge functions
• Reproducible byte-for-byte on the same toolchain via SOURCE_DATE_EPOCH
• EUPL-1.2, hosted on Codeberg, governed from the Netherlands

curl -fsSL https://kern-lang.eu/install.sh | bash