Software Engineer · Programming Languages · Compilers · Developer Tooling
I build software close to the underlying machinery —
languages, compiler internals, systems software, infrastructure, and tools for developers.
$ whoami
focus programming languages · compilers · developer tooling · systems
primary Go · C · SvelteKit · Astro
also Rust · C++ · TypeScript · Python · C# · React · Lua
$ current
→ designing and building the Peeper programming language
→ compiler architecture and semantic analysis
→ type systems, ownership, data flow and drop semantics
→ language tooling and LSP
→ contributing to open-source developer tools
A programming language and compiler designed around a simple principle:
Things should work and feel the way they look.
The project spans language design, parsing, semantic analysis, type checking, ownership, data-flow analysis, drop semantics, module systems, compiler architecture, and developer tooling.
compiler language-design type-system ownership data-flow LSP
Programming language compiler and language implementation project.
Unicode-based Bangla keyboard IME for Linux.
In-memory key-value cache database.
Server load balancer built around lightweight networking and infrastructure primitives.
Command-line multi-file compression and encryption tool with zero external dependencies.
Modern C++ GUI framework with platform abstraction for Linux/X11 and Windows/Win32.
Self-hostable realtime messaging platform with end-to-end encryption.
Progressive web application for instrument tuning.
I contribute upstream when I find something worth fixing, simplifying, or extending.
Zed High-performance code editor and developer tooling.
GOCQLX CQL query builder for ScyllaDB.
D2 Declarative diagram scripting language.
Socket.IO Deno Socket.IO implementation for Deno.
Lore Version control system from Epic Games.
FreeLLMAPI Open-source tooling around accessible LLM APIs.
The implementation matters, but so does the structure around it.
I tend to optimize for systems with:
- explicit semantics
- predictable behavior
- small, understandable abstractions
- centralized invariants
- minimal accidental complexity
- architecture that makes incorrect implementations harder to introduce
A question I keep coming back to is:
How should the system be structured so the next change is difficult to get wrong?
I write about programming languages, compiler architecture, software engineering, developer tooling, and implementation experiments at:





