Sharing a body of pure-Mojo open-source work we just put out — and genuinely after feedback from people who know MAX/Mojo deeper than we do.
Over a short sprint on Mojo 1.0 (Light of Baldr LLC), we built and open-sourced 11 projects, on the bet that Mojo 1.0 is ready to host real systems software end-to-end, not just ML kernels. Everything is Apache-2.0 at lightofbaldr (Adam Kruger) · GitHub.
A full pure-Mojo web stack — no Python/Go/Node on the request path:
- mojo-http — HTTP/1.1 server on raw POSIX sockets via FFI
- mojo-serve —
serve .-style static server + a Flask/FastAPI-shaped routing core - mojo-json — RFC-8259 parser/emitter (Mojo stdlib has none — fills the gap)
- mojo-template — Jinja2-inspired HTML engine (autoescape, if/for, filters)
- mojo-gpuq — a Redis-shaped queue/KV/task store whose payloads live in GPU memory (CUDA Driver API via
std.ffi) - mojo-cudart-shim — an
LD_PRELOADinterposer that caps reported GPU memory for MAX on unified-memory hosts - baldr — a batteries-included bundle that unifies the above into one import surface (the “FastAPI of Mojo”); 242 tests green
Security tooling:
- mojo-yara — a YARA-compatible scanner, bit-equal to C libyara 4.5.0 across 150 matching decisions
- mojo-multimatch — the one I’d most love eyes on: a GPU-resident Aho-Corasick multi-pattern matching kernel. Three backends behind one dispatcher (scalar / GPU / a SIMD-CPU slot). Same Mojo source on two architectures with zero per-arch changes — measured ~15× over scalar on Ada (RTX 4070), ~47× on GB10 Grace-Blackwell. The dispatcher is
std.gpubyte-level lane math over a flat goto table.
And a demo that wires the stack into one running app: mojo-stack-demo / mojo-stack-demo-v2.
What’s next: a pure-Mojo BPE tokenizer, a GPU scan kernel for gpuq’s FIND, and exploring a model bring-up on MAX.
Would genuinely value feedback — especially on the GPU kernel design, and anything that would make these more useful to the community. Repos: lightofbaldr (Adam Kruger) · GitHub
— Adam, Light of Baldr