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

@prologic@twtxt.net Not bad for a start, ey! Looking forward to see you going down these rabbit holes and opening one can of worms after the other. :‘-D Very, very impressive, hats off to you. :-)

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

@prologic@twtxt.net Can you just make them optional? :-) But that of course complicates things.

@prologic@twtxt.net That’s impressive. How large are the resulting binaries? You don’t have any optimizations in place yet, do you?

@movq@www.uninformativ.de I hid in the workshop with earmuffs for the absolute worst part.

@javivf@adn.org.es Heck yeah, let’s do this! :-) Welcome to 2026.

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: ❌

@prologic@twtxt.net Not bad. 😃

@prologic@twtxt.net Anything by Charlotte de Witte. 😅 For example:

https://www.youtube.com/watch?v=QfkgSlmoe1I

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

Happy new year! Waiting for ours watching the celebrations around the world. 🥳🥳🥳

@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!

@lyse@lyse.isobeef.org Ooh, lovely! 🌇

I’m drowning the noise with this: https://www.youtube.com/watch?v=tgivYC2s6hs

😅

@shinyoukai@neko.laidback.moe We finally abandoned our GitLab. I publicly mirrored my code in the Mills Data Center a few days ago: https://git.mills.io/lyse/tt2

@movq@www.uninformativ.de Well, just a very limited subset thereof:

1. inline and multiline code blocks using single/double/triple backticks (but no code blocks with just indentation)
   
2. markdown links using using [text](url)
   
3. markdown media links using ![alt](url)
   

And that’s it. No bold, italics, lists, quotes, headlines, etc.

Just like mentions, plain URLs, markdown links and markdown media URLs are highlighted and available in the URLs View. They’re also colored differently, similarly to code segments.

I definitely should write some documentation and provide screenshots.

@lyse@lyse.isobeef.org You actually have a Markdown parser/renderer in there? Oh dear. I would have been (well, I am) way too lazy for that. 😅

@prologic@twtxt.net Happy New Year 🥳🎆

It totally sounds like an active warzone around here. So, I just went on a very, very, very quick stroll to check out our sunset from ontop our hill (were all the bangs are way more horrible): https://lyse.isobeef.org/abendhimmel-2025-12-31/

Happy New Year (2026) 🥳

Hurray, I finally fixed another rendering bug in tt that was bugging me for a long time. Previously, when there were empty lines in a markdown multiline code block, the background color of the code block had not been used for the empty lines. So, this then looked as if there were actually several code blocks instead of a single one.

https://lyse.isobeef.org/tmp/tt-bugfix-empty-lines-in-multiline-code-blocks.png