@shinyoukai@neko.laidback.moe Whoohoo! That’s a start to cross-platform support 🤣

Patch applied!

@shinyoukai@neko.laidback.moe No email has arrived here? 🤔

@shinyoukai@neko.laidback.moe Okay I pushed a commit that hopefully fixes this. I hope!

@shinyoukai@neko.laidback.moe Yes; however the interpreter is also platform dependent and relies on making raw syscalls. This is so the runtime semantics remain the same between the two execution modes.

I’ll see if I can add support for linux/amd64 and netbsd/amd64 for the VM at least.

@shinyoukai@neko.laidback.moe if you don’t show me the actual full stacktrace, I can’t fix the problem 😢

Most of it should work on other platforms, the bytecode VM that is. You may run into some platform quirks though that rely on syscall() – Let me know what you run into and I’ll try to fix them nw. The problem right now is I haven’t even begun to start work on another platform/architecture yet.

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():

It’s gone. 👋

@shinyoukai@neko.laidback.moe

Work kills the soul

it sure can! 🤣

Make it so number one !

@movq@www.uninformativ.de What’s Email?! 😂

@movq@www.uninformativ.de I quite like this part:

Many people write programs, but few stick with a program long enough to distill it.

@bender@twtxt.net No, I had my break/holiday earlier. I chose to work through, except the public holidays of course.

@movq@www.uninformativ.de Ahh nice! It’s been several decades since I’ve played that! Probably 3 actually come to think of it 🤣

@movq@www.uninformativ.de what game is that?

I basically worked through the Christmas break last year. I already had my holidays in Vietnam a few weeks earlier. 😆

Trying to build a native heap allocator that grows and isn’t statically wired into the binary’s image is fuck’n hard™ as 🤣

@movq@www.uninformativ.de 🤣

@movq@www.uninformativ.de Very cool! 😎

@shinyoukai@neko.laidback.moe Oh no, fuck that 🤣 That’s why I built an FFI so I can call C-functions via shared libraries 🤣

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
  

😅

@movq@www.uninformativ.de Looks kind of nice 😊

@movq@www.uninformativ.de What I wish for once on this miserable planet is for coporations one day ohave a different set of reasons to exist and thrive other than:

but since the only goal of that manufacturer is to make money, they do it

Life becomes very boring and uninteresting when your only goal in life is to “make more fucking money” 💰 Fuck 🤬 Fuck this Corporatocracy we live in 🤦‍♂️

@eldersnake@we.loveprivacy.club da fuq?! 🤯

@shinyoukai@neko.laidback.moe I can’t believe Trace and Edgewall Software is still around and in use 🤣

@lyse@lyse.isobeef.org It’s actually not nearly as half bad as I really thought it would be. Just having to eventually deal with the “lowering down” to machine code / ARM64 assembly in the end once you’ve verified the semantics in the VM.

@lyse@lyse.isobeef.org A “Hello World” binary is ~372KB in size. I currently have peephole optimization and deac code optimizations in play, and a few other performance related ones, but nothing too fancy. I have a test case that ensures fib(35) doesn’t regress too badly as I continue to evolve the language.

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

@shinyoukai@neko.laidback.moe Happy New Year to you too! 🥳

@movq@www.uninformativ.de This is fuck’n great shit™ Where did you find this? 🤔 Got any more shit™ like this? 🙏

@dce@hashnix.club Happy New Year to you too! 🥳

@ionores@twtxt.net Very nice! 😊 Happy New Year to you too!

Happy New Year (2026) 🥳

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

@movq@www.uninformativ.de Is this on yout little toy OS? 🤔

@lyse@lyse.isobeef.org I can tell you this right now, writing assembly / machine code is fucking hard work™ 😓 I’m sure @movq@www.uninformativ.de can affirm 🤣 And when it all goes to shit™ (which it does often), man is debugging fucking hard as hell! Without debug symbols I can’t use the regular tools like lldb or gdb 😂

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

@lyse@lyse.isobeef.org True !

@zvava@twtxt.net The problem you now then is you lose integrity of the message content if you compute the hashes at runtime rather than on the way in. So if your message content or database becomes corrupt in any way, so do your hashes.

Building native compilers is hard 🤣 Building bytecode VM / interpreters is way easier 🤣

@shinyoukai@neko.laidback.moe Very cool! 😎

@shinyoukai@neko.laidback.moe Nice! 👍

@movq@www.uninformativ.de Thanks! 🙏

@shinyoukai@neko.laidback.moe Nah it’s more like there’s a lot of repeated code, because when you go from source language to intermediate representation to machine code, well you just end up writing a lot of the same patterns over and over again. I need to dedupe this I think.

@kiwu@twtxt.net Ooof 😢 That’s rough!