Have finally put together the beginnings of a site for Mu (µ) https://mu-lang.odev 🤞 #mu #mu-lang
yes, yes that’s right. Mu (µ) now has a built-in LSP server for fans of VS Code / VSCodium 😅 You just go install ./cmd/mu-lsp/... and install the VS extension and hey presto 🥳 You get outlines of any Mu source, Find References and Go to Definition!
./bin/mu -B -o ... -p muos/amd64 ... target.
@prologic@twtxt.net I’d love to take a look at the code. 😅
I’m kind of curious to know how much Assembly I need vs. How much of a microkernel can I build purely in Mu (µ)? 🤔
Can’t really answer that, because I only made a working kernel for 16-bit real mode yet. That is 99% C, though, only syscall entry points are Assembly. (The OpenWatcom compiler provides C wrappers for triggering software interrupts, which makes things easier.)
But in long mode? No idea yet. 😅 At least changing the page tables will require a tiny little bit of Assembly.
./bin/mu -B -o ... -p muos/amd64 ... target.
I’m kind of curious to know how much Assembly I need vs. How much of a microkernel can I build purely in Mu (µ)? 🤔
./bin/mu -B -o ... -p muos/amd64 ... target.
Whohoo! 🥳
You have no idea how great a feeling this is! This includes the Mu stdlib and runtime as well, not just some simple stupid program, this means a significant portion of the runtime and stdlib “just works”™ 🤣
Btw @movq@www.uninformativ.de you’ve inspired me to try and have a good ‘ol crack at writing a bootloader, stage1 and customer microkernel (µKernel) that will eventually load up a Mu (µ) program and run it! 🤣 I will teach Mu (µ) to have a ./bin/mu -B -o ... -p muos/amd64 ... target.
Took me nearly all week (in my spare time), but Mu (µ) finally officially support linux/amd64 🥳 I completely refactored the native code backend and borrowed a lot of the structure from another project called wazero (the zero dependency Go WASM runtime/compiler). This is amazing stuff because now Mu (µ) runs in more places natively, as well as running everywhere Go runs via the bytecode VM interpreter 🤞
This week, Mu (µ) get s bit more serious and starts to refactor the native backend (a lot). Soon™ we will support darwin/arm64, linux/arm64 and linux/amd64 (Yes, other forms of BSD will come!) – Mu (µ) also last week grew concurrency support too! 🤣
Mu (µ) is coming along really nicely 🤣 Few things left to do (in order):
- Finish the concurrency support.
- Add support for sockets
- Add support for
linux/amd64
- Rewrite the heap allocator
- Rewrite Mu (µ) in well umm Mu (µ) 😅
Here’s a screenshot showing off the builtin help(): 
Mu (µ) is now getting much closer to where I want it to be, it now has:
- A
processstdlib module (very basic, but it works)
- An
ffistdob module that supportsdlopen/dlsymand calling C functions with a nice mu-esque wrapperffi.fn(...)
- A
sqlitestdlib module (also very basic) that shows off the FFI capabilities
😅
Opinion / Question time…
Do you think Mu (µ)’s native compiler and therefore emitted machine code “runtime” (which obviously adds a bit of weight to the resulting binary, and runtime overheads) needs to support “runtime stack traces”, or would it be enough to only support that in the bytecode VM interpreter for debuggability / quick feedback loops and instead just rely on flat (no stacktraces) errors in natively built compiled executables?
So in effect:
Stack Traces:
- Bytecode VM Interpreter: ✅
- Native Code Executables: ❌
Nice! 😊 Here are the startup latencies for the simplest Mu (µ) program. println("Hello World"):
- Interpreter: ~5ms
- Native Code: ~1.5ms
Hmmm 🤔
Excluding merges, 1 author has pushed 171 commits to main and 175 commits to all branches. On main, 294 files have changed and there have been 52880 additions and 18269 deletions.
From the Mu (µ) Gitea Activity Tab
mu (µ) now has builtin code formatting and linting tools, making µ far more useful and useable as a general purpose programming language. Mu now includes:
- An interpreter for quick “scriptinog”
- A native code compiler for building native executables (Darwin / macOS only for now)
- A builtin set of developer tools, currently: fmt (-fmt), check (-check) and test (-test).
@movq@www.uninformativ.de Mu (µ)’s startup latency appears to be ~10ms on my machine:
$ time ./bin/mu ./foo.mu
real 0m0.011s
user 0m0.004s
sys 0m0.006s
println(1, 2) was bring printed as 1 2 in the bytecode VM and 1 nil when natively compiled to machine code on macOS. In the end it turned out the machine code being generated / emitted meant that the list pointers for the rest... of the variadic arguments was being slot into a register that was being clobbered by the mu_retain and mu_release calls and effectively getting freed up on first use by the RC (reference counting) garbage collector 🤦♂️
@lyse@lyse.isobeef.org Yeah I remember you said some days back that your interest in compilers was rekindled by my work on mu (µ) 😅
Whoo! I fixed one of the hardest bugs in mu (µ) I think I’ve had to figure out. Took me several days in fact to figure it out. The basic problem was, println(1, 2) was bring printed as 1 2 in the bytecode VM and 1 nil when natively compiled to machine code on macOS. In the end it turned out the machine code being generated / emitted meant that the list pointers for the rest... of the variadic arguments was being slot into a register that was being clobbered by the mu_retain and mu_release calls and effectively getting freed up on first use by the RC (reference counting) garbage collector 🤦♂️
@movq@www.uninformativ.de I’ve managed to bring a simple “Hello World!” in mu (µ) (at least on macOS / Darwin / ARM64) down to ~86KB (previously ~146KB) 🥳
Hmmm I need to figure out a way to reduce the no. of lines of code / complexity of the ARM64 native code emitter for mu (µ). It’s insane really, it’s a whopping ~6k SLOC, the next biggest source file is the compiler at only ~800 SLOC 🤔
@movq@www.uninformativ.de Oh that’s fine, Mu can compile to native code and so far binaries. at least on macOS are in the order of Kb in size 😂
@movq@www.uninformativ.de It’d be cool if you could get µ (Mu) running in your little toyOS 🤣 You’d technically only have to swap out the syscall() builtin for whatever your toy OS supports 🤔
I just had a closer look at https://git.mills.io/prologic/mu and it motivated me to do some compiler building myself again. Hopefully, I find some time in the next free days. I’m bad at it, but it’s always great fun.
@movq@www.uninformativ.de @kiwu@twtxt.net it just so happens to be a happy coincidence that I’m extending mu’s capabilities to now include a native toolchain-free compiler (doesn’t rely on any external gcc/clang or linkers, etc) that lowers the mu source code into an intermediate representation / IR (what @movq@www.uninformativ.de refers to as “thick layers of abstractions”…) and finally to SSA + ARM64 + Mach-O encoder to produce native binary executables (at least for me on my Mac, Linux may some later?) 🤣
@movq@www.uninformativ.de Pretty sure all my mu solutions are very slow, but not so slow as I optimized most of the implementations to avoid as much brute forcing as I could.
I cleaned up all my of AoC (Advent of Code) 2025 solutions, refactored many of the utilities I had to write as reusable libraries, re-tested Day 1 (but nothing else). here it is if you’re curious! This is written in mu, my own language I built as a self-hosted minimal compiler/vm with very few types and builtins.
I finished all 12 days of Advent of Code 2025! #AdventOfCode https://adventofcode.com — did it in my own language, mu (Go/Python-ish, dynamic, int/bool/string, no floats/bitwise). Found a VM bug, fixed it, and the self-hosted mu compiler/VM (written in mu, host in Go) carried me through. 🥳
Ooops, I’ve run into a bug or limitation with mu for Day 9 🤔
I just completed “Printing Department” - Day 4 - Advent of Code 2025 #AdventOfCode https://adventofcode.com/2025/day/4 – Again, I’m doing this in mu, a Go(ish) / Python(ish) dynamic langugage that I had to design and build first which has very few builtins and only a handful of types (ints, no flots). 🤣
I just completed “Lobby” - Day 3 - Advent of Code 2025 #AdventOfCode https://adventofcode.com/2025/day/3 – Again, I’m doing this in mu, a Go(ish) / Python(ish) dynamic langugage that I had to design and build first which has very few builtins and only a handful of types (ints, no flots). 🤣
Did I mention mu only supports ints? 🤔 I’m not sure if I’ll need flots for this year’s AoC? 🤔
I’m having to write my own functions like this in mu just to solve AoC puzzles :D
fn pow10(k) {
p := 1
i := 0
while i < k {
p = p * 10
i = i + 1
}
return p
}
I just completed “Gift Shop” - Day 2 - Advent of Code 2025 #AdventOfCode https://adventofcode.com/2025/day/2 – But again, I’m solving this in my own language mu that I had to build first 🤣
I just completed “Secret Entrance” - Day 1 - Advent of Code 2025 #AdventOfCode https://adventofcode.com/2025/day/1 — However I did it in my own toy programming language called mu, which I had to build first 🤣
Ahh that’s because I forgot to call main() at the end of the source file. mu is a bit of a dynamic programming language, mix of Go(ish) and Python(ish).
$ ./bin/mu examples/aoc2025/day1.mu
Execution failed: undefined variable readline
Come back from my trip, run my AoC 2025 Day 1 solution in my own language (mu) and find it didn’t run correctly 🤣 Ooops!
$ ./bin/mu examples/aoc2025/day1.mu
closure[0x140001544e0]
I actually can’t progress to day two till I get home 🤣 – I haven’t pushed the code for the mu compiler yet 🤦♂️ So no-one can check my work even if they were so kind 🤣
completely untested as i have no remote way of running mu code from Vietnam 🤣
AoC Day #1 solution (mu): https://gist.mills.io/prologic/d3c22bcbc22949939b715a850fe63131
The most interesting part about mu is that the language is actually self-hosted and written in itself. There is a stage zero compound written and go on a stage one compiler written in mu
Thinking about doing Advent of Code in my own tiny language mu this year.
mu is:
- Dynamically typed
- Lexically scoped with closures
- Has a Go-like curly-brace syntax
- Built around lists, maps, and first-class functions
Key syntax:
- Functions use
fnand braces:
fn add(a, b) {
return a + b
}
- Variables use
:=for declaration and=for assignment:
x := 10
x = x + 1
- Control flow includes
if/elseandwhile:
if x > 5 {
println("big")
} else {
println("small")
}
while x < 10 {
x = x + 1
}
- Lists and maps:
nums := [1, 2, 3]
nums[1] = 42
ages := {"alice": 30, "bob": 25}
ages["bob"] = ages["bob"] + 1
Supported types:
int
bool
string
list
map
fn
nil
mu feels like a tiny little Go-ish, Python-ish language — curious to see how far I can get with it for Advent of Code this year. 🎄
@movq@www.uninformativ.de Yes, the tools are surprisingly fast. Still, magrep takes about 20 seconds to search through my archive of 140K emails, so to speed things up I would probably combine it with an indexer like mu, mairix or notmuch.