👋 Looking for other interested folks to continue to evolve the development of Salty.im 🙏 I've been hard™ at work on the v2 branch and @doesnm.p.psf.lt has been incredibly helpful so far. Be great ot have a few more folks to join us, some of the v2 highlights include:

• Double Ratchet by default.
• Group Chat (sender/client fan-out for now)
• Much better TUI with background agent.
• Mobile App coming soon™ (iOS in progress, Android next, same codebase)

Trying an experiment. Created a Github repo for mu over at https://github.com/prologic/mu as a social experiment to see if we can maintain a tailored Github docs-only repo of a project, see if it gets any interest 🤔

Have finally put together the beginnings of a site for Mu (µ) https://mu-lang.dev 🤞 #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!

Btw @movq 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 process stdlib module (very basic, but it works)
• An ffi stdob module that supports dlopen / dlsym and calling C functions with a nice mu-esque wrapper ffi.fn(...)
• A sqlite stdlib 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).

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 🤦‍♂️

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 🤔

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.

https://git.mills.io/prologic/aoc2025

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 🤣

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]

AoC Day #1 solution (mu): https://gist.mills.io/prologic/d3c22bcbc22949939b715a850fe63131

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 fn and braces:

fn add(a, b) {
    return a + b
}

• Variables use := for declaration and = for assignment:

x := 10
x = x + 1

• Control flow includes if / else and while:

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. 🎄

Thank you for the encouragement and love and kind words, @lyse @movq @bender @doesnm and others along the way I'm not sure of their feed uris 💕 I'll keep at it, but for the time being I will keep my distance, mostly off IRC, because I don't have the energy to spare in that kind of engagement (what//if the worst happens, it's so draining). I need to remember what I ever did any of this for, it was back in ~2020 and I wanted really to build small interconnected communities that any non "tech savvy" person (more or less) could also benefit from ane enjoy. Even if there are aspects of the specs we've built/extended over time that aren't "perfect"™, they're "good enough"™ that they've last 5+ years (I believe this is 6 years running now). I want to spend a bit of time going back to why I did any of this in the the first place, and get a little micro-SaaS offering going (barely covering running costs) so encourage more folks to run pods, and thus twtxt feeds and grow the community ever so slightly. Other than that, I plan to get the specs "in order" to a point (with @movq and @lyse's help) where I hope they'll stand the test of time -- like SMTP.

Thank you all ! 🙏

🤔 💭 🧐 What if, What if we built our own self-hosted / small-web / community-built/run Internet on top of the Internet using Wireguard as the underlying tech? What if we ran our own Root DNS servers? What if we set a zero tolerance policy on bots, spammers and other kind of abuse that should never have existed in the first place. Hmmmm

Weekend! Whooo 🤣 Having a few too many glassses of 🍷 listening to music on Youtube and playing Chess which I haven't been playing much lately 😢

Been mucking around with designing my own camper (floor plan).

Responded to a bunch of Twtxt open issues across multiple repositories today 👌

Am I the only one that's confused by the discussions, and then the voting we had on the whole threading model? 🤔 I'm not even sure what I voted for, but I know it wasn't the one that won haha 🤣 (which I'm still very much against for based on an intuition, experience and lots of code writing lately).

@bender I noticed that although the Discover view (and your own Timeline) is much improved with a MaxAgeDays configuration at the pod level, that now some profiles are rather empty. This is only because well, they're a bit "inactive" so to speak 🗣️ Not sure what to do about this at the moment... Open to ideas? 💡