Been a few weeks working on this, majority of it was done in like 10 days, but then life, and bugs needed fixed and feature creep, and everything. Either try it out or not, I needed something specific that I had more control over for my other projects, so now this exists.
I present to you Flow, which started from the fairly simple question:
what would a systems language look like if a huge amount of its development was driven through LLMs?
What started off as a simple experiment has become an actual compiler + language ecosystem.
Flow is statically typed and aimed at writing relatively compact code without giving up native performance. It has multiple compilation paths, including C and MLIR/LLVM.
A lot of people wonder about whether or not an LLM can generate a compiler from a schema.
I think it's time we start asking ourselves whether we can construct enough feedback and verification around an LLM that the language remains coherent while the implementation is scaled up.
I've learned a lot of things about how best to use LLMs as tools, as well as a lot of the science behind traditional compiler engineering, in the process. By embracing the tooling and having fun, there's a lot of cool stuff to be made.
I just released madc v0.82.0, and this is probably the biggest portability milestone for the project so far.
madc already supported Linux, and v0.76.0 added the first public macOS builds. With v0.82.0, Windows joins them, and all three platforms now ship together from the same source tree:
Public binaries are now available for all three.
A few highlights from this release:
I have been experimenting a lot with LLMs and new programming languages. Most of my experiments have been around extending C with multimethod and a better cpp. Minimal languages like tcl, lisp, forth are super easy to prototype with LLMs.
Because of the way RLVR works I think Perl5 makes an excellent language like go/C for LLM generation. LLMs learn to write code by making tests pass.
After experimenting with PEG grammars with pigeon in go, I decided to give moarvm a try. I like Raku but I like Perl5 even more. Although I never programmed in Perl professionally, it was my first language. I made the first port of Perl (miniperl) to asm.js back in the day.
Raptor is a dynamic language - roughly a Perl5 subset of Raku targeting Wasm, Go and MoarVM. It supports go FFI, C FFI, refinement types, predicate types, multimethods, defensive programming, literate programming and standalone binary packaging (raptor pack). These are the features I have always wanted in Perl. There's rudimentary wasm support. There's also PHP mode.
If you know Raku then you already know raptor. Raptor will never support OO like Raku or PyObject like Python. I intend it to support C FFI thoroughly and a strict procedural style along with universal function calling syntax. That's probably the main difference between Raptor and Raku.
I think the future of programming will be to make languages with parsable grammars, good verification support and must include literate programming for humans.
The language was mostly written by Anti Gravity - Gemini 3.6. Library bindings, podlit are written by Gemini 3.7 which was released today. My role was just in pushing it to implement more tests.
I have mostly built this on windows. It should work on Linux. Expect bugs, memory leaks and probably some wrong semantics. Future versions will make it closer to Raku.
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