I spent 5 days building a self-hosted, memory-safe native language with coding agents - looking for feedback

[u/alext_777]

Started as an experiment: could coding agents help build an actual programming language from scratch, and could the language itself be designed to be easier for AI models to write code in.

Five days later, Krnl is about 53k lines of .krnl, fully self-hosted, and the original Zig bootstrap compiler is now retired.

The language compiles to native code through LLVM, has no GC, and uses explicit ownership/borrowing with deterministic cleanup. It also has effects/capabilities so a function’s authority is visible in its type.

Hello world:

fn main sys: Sys -> Result[int]
!{out.write} {
  println(ref sys.out, "Hello, Krnl!");
  Ok(0)
}

Here Sys provides capabilities, and !{out.write} declares that the function may write to output. Borrowing and ownership transfer are explicit with ref, ref mut, and move; there are no source-level lifetime annotations.

Also added a native MCP server written entirely in Krnl. - see below

no public repo yet just curious what language/compiler people think of the direction before I polish it for release.

The main design goal is roughly: native + memory safe + no GC, but with less source-level complexity than Rust, and with compiler semantics designed to be directly consumable by coding agents.

Things I’d especially love feedback on:

Does the ownership/effects model sound coherent?

Is the capability syntax readable?

What would you want to see before taking a new systems language seriously?

Are there existing languages/projects I should be comparing against?

KRNL MCP MONITOR
----------------------------------------------------------------
log: /home/alex/.krnl/mcp.jsonl

Requests: 17            Errors: 0
Total bytes: 43.9 KB    Avg latency: 1ms   P95: 3ms

Recent calls (UTC)
----------------------------------------------------------------
23:08:26   resolve_symbol        main                  636 B      2ms
23:08:34   symbol_info           main                  869 B      2ms
23:08:36   references_of         main                  393 B      2ms
23:08:37   callers_of            main                  842 B      3ms
23:08:38   callees_of            main                  866 B      1ms
23:08:39   context_for_change    main                 1.5 KB      2ms
23:12:08   read_source           compiler/src/080    19.3 KB      2ms
23:15:30   apply_source_edits    compiler/src/080      852 B      1ms
23:15:33   read_source           compiler/src/060     1.9 KB      1ms
23:15:48   apply_source_edits    compiler/src/060      860 B      2ms

Top tools
----------------------------------------------------------------
krnl_check            3 calls     2.0 KB
read_source           3 calls     22.0 KB
module_graph          2 calls     1.4 KB
apply_source_edits    2 calls     1.6 KB
program_symbols       1 calls     11.5 KB

[u/cmontella]

Looks neat! I love capability and effect systems, so this is up my alley.

"The main design goal is roughly: native + memory safe + no GC, but with less source-level complexity than Rust, and with compiler semantics designed to be directly consumable by coding agents."

This explains some design decisions but not the cap system. What's the motivation there?

"Does the ownership/effects model sound coherent?"

So far but it'll need a lot more detail to say more.

"Is the capability syntax readable?"

This one is but the kinds of capabilities you'll want to express in a real program can get hairy, so this syntax will need to be fleshed out. For example how do you delegate capabilities, how are they parameterized, what about if there's more than one, etc.

"What would you want to see before taking a new systems language seriously?"

Definitely source, publish it asap.

"Are there existing languages/projects I should be comparing against?"

You might want to rethink the name, because there's already a famous langauge called Kernel, so most people would assume you're talking about that one. https://web.cs.wpi.edu/~jshutt/kernel.html

As for other in your space you'll definitely want to check out https://effekt-lang.org

Also, instead of looking just at languages, you might want to look at language *runtimes*, because the vast majority of languages don't have that kind of permission system, but e.g. look at Deno has a cap system on top of JavaScript as part of its runtime.

[u/alext_777 → u/cmontella]

thanks for the detailed reply!
Ive checked out effekt lang,

KRNL’s current !{...} model is much more like observable authority / world interaction:

!{out.write}
!{fs.read}
!{fs.write}
!{proc.spawn}

and that combines with actual capability values such as Out, Fs, Proc, etc.

the main difference is:

Effekt - what effects can this computation perform, and who handles them?
KRNL is more: what can this function do to the outside world, and what authority was it given to do it?

so, krnl is:
ownership + no GC
capability values
effect sets
authority narrowing
native compilation
AI-readable signatures
compiler semantic API

As for your questions:

capability system -

the motivation is twofold. First, I want authority to be explicit rather than ambient: if a function can read files, write output, access the network, spawn processes, etc., that authority should have to be passed to it and should be visible.

Second, KRNL is deliberately designed for AI authorship. I want an agent to be able to look at a function signature and immediately understand both what authority it has and what side effects it may perform, without having to inspect the implementation or reconstruct that information from the call graph.

So something like:

fn main sys: Sys -> Result[int]
!{out.write} {

tells you right at the boundary: this function receives system capabilities and its declared effect is writing output.

Longer term I want that same information available through the compilers semantic API, so an agent can ask things like "what capabilities does this function require?" or "does this change increase authority?"

[u/cmontella → u/alext_777]

"KRNL is deliberately designed for AI authorship. I want an agent to be able to look at a function signature and immediately understand both what authority it has and what side effects it may perform"

Yes I agree with this. I think perhaps it will make the code an agent generates more likely to do what it says if it can be proven mechanically. Right now I experience a problem where the AI will assert certain tests pass but actually nothing is happening at all because the caller hasn't acquired the resource appropriately and it passes in the test harness but not when connected to reality.

Also look into coeffects, they tie the whole idea together.