What's everybody working on?

[gustafla]

I’m currently using stb_vorbis in my main long-running zig project (a demo engine). I’m very interersted in this port. Are you planning to publish the code?

[gustafla]

In addition to the demo engine I mentioned previously, it really bothered my ego that I didn’t have any hands-on experience with Zig 0.16 async Io. I was reading the zio thread and one thing lead to another and I made this toy TCP file server: GitHub - gustafla/zio-flate-server: Zig async Io project: A concurrent local file server with gzip compression and caching · GitHub

It’s not AI generated code but I had an intensive Gemini chat during development. It’s very nice to be able to explain my assumptions and think about the mechanisms and problems while writing each prompt, sort of like having a nerd-out with a colleague. I would of course prefer to do this (e.g. pair programming) with a real human, but LLM seems to work decently as a sink for my own thoughts too.

[Anthon]

@gustafla

I would of course prefer to do this (e.g. pair programming) with a real human,

One of the advantages of getting older is that you can do pair programming with yourself:

I tend to write down ideas, and an outline of an implementation, and when I read it back a day or two later, it is difficult to understand what the person, that wrote down the idea, had in mind. So I come up with some new solution and then have to come up with arguments why it is better.

Looking back at some implementation outlines I come across that way, I think I fulfil the stronger non-I policy, as that encompasses any non-AI policy.

[lukeflo]

Currently I’m working on building my ls style TUI filemanager in Zig.

Because ls -lah --group-directories-first is one of my most used Linux commands on my private machine as on the servers I admin at work, I always felt like having it as interactive TUI would be great. Other common TUI file manager like yazi or ranger have too much unnecessary stuff for me (Before have been user of simple fff). And its fun building TUIs

[KT-Casper]

First post .

I am working on a Fully validating XML 1.0/1.1 Parser with all the bells and whistles (entity expansion, DTD validation, namespaces, ect). I have a test harness in place for the W3 test suite, so I’m currently working on passing all the tests it has, then I’ll fuzz test it to oblivion. I was gonna triage libxml2’s issue history as well to try and catch any issues the tests won’t cover. So still a while to go on the front but I’m finding it very enjoyable.

The ultimate end goal is to eventually have an XSD 1.1 validator I can use for a use case in my day job, so I expect I’ll be working on it for a long time.

[zigo]

What the first argument (a dot) means in the call return c.json(., .{}); shown on the page https://spiderme.org/? Something I haven’t learned?

[llllOllOOll]

Here’s a simple example of returning a JSON list with Spider:

pub fn index(c: *spider.Ctx) !spider.Response {
    const tickets = try spider.pg.query(
        struct { protocol: []const u8, title: []const u8, status: []const u8 },
        c.arena,
        "SELECT protocol, title, status FROM tickets ORDER BY created_at DESC LIMIT 10",
        .{},
    );
    return c.json(tickets, .{});
}

Output:

[
  {"protocol":"2026-0003","title":"Ceiling leak — block A corridor","status":"in_progress"},
  {"protocol":"2026-0001","title":"Burned light bulb — block A corridor","status":"resolved"}
]

If you want to get in touch, we have a simple Discord channel.

[sohro_desu]

Mission-critical performance drawing app for Android and PC that can rival or surpass Procreate the drawing app for iOS

The link to my original post: Telegram: View @sono_rakugaki

One of many reasons why: Telegram: View @sono_rakugaki

Currently, the project is stalled because I’m busy to survive

You’re seeing my 6–7 minute sketch in my own drawing app, which I’m writing from scratch in Zig.

I started writing it a month ago. Progress so far:

— Hand-rolled Wayland communication functions (no libwayland)
— Implemented Bresenham’s Line Algorithm to eliminate dotted lines. The algorithm interpolates dots between two positions, forming a consistent, continuous line.
— Implemented basic tablet and pen recognition protocols.
— A simple pressure algorithm: the harder you press, the blacker the color becomes; the softer, the grayer it gets, approaching white.
— Pen button for erasing mode. Well, the color changes to white and you paint white ;') Not a proper eraser, and no layers yet.
— Frame-based updates to avoid screen tearing, thousands of function calls per second, and other performance/efficiency issues. I continuously ask the system, “Are you ready?” Whenever it responds with yes, I perform a screen update in a rectangle for the affected surface, roughly speaking.

Now I’m learning how to write my own ultra-minimalistic UI library (much like Clay). I will never use any bloated libraries such as Qt or whatever.

Right now, there is literally zero lag when drawing, and the screen is incredibly smooth. This is in debug mode with an extremely messy codebase as of now. Imagine all the optimizations I’m going to make for mission-critical performance. I’ll make sure everything stays true to my vision even after I release the app for Android and PC.

#android_drawing_app_project

Zero dependency on any external libraries. The only dependency is libc for these kernel level system call functions: shm_open, shm_unlink, ftruncate, send, recv and so on.

Also have to say explicitly: NO AI IS EVER USED FOR CODE GENERATION. Fuck AI, fuck the vibe coders. Besides, AI knows no shit about Zig (which is good)

I’m handwriting everything myself. I do use AI, BUT only for learning math, algorithms, geometry and stuff like that, NEVER for ready to copy&paste code

[zigster]

This week - bit burnt out from doing serious work in the last few weeks, so I’m currently working on a completely useless toy that mixes up some new-to-me tech in purely experimental ways to do absolutely nothing useful at all, with little to no direction or purpose.

And I’m having a blast.

Using a single zig build to compile and execute a polyglot system of services that connect together in non-interesting ways.

At the core is an Erlang app that maintains a simple DB of running games. It presents a web page that lists all the games like a lobby, and allows users to add/delete games. Uses SSE to broadcast realtime updates to connected users. So far so good.

Then - for no useful reason at, the Erlang app has a supervision tree of a pool of external heavyweight client apps. This supervisor launches the apps and monitors them - so if you kill one, it gets respawned by the supervisor.

Then, implement a heavyweight client app in Zig that connects to the Beam, and looks like any other beam process, with its own Pid. It subscribes to the games list and receives broadcast messages as games update. The Erlang app spawns a handful of these concurrently and monitors them.

Then implement the same client in Odin, because why not ?

Now getting the Zig and Odin clients to send messages to each other through the beam, for no good reason at all.

Next step after that - going to get the “system” to distribute the external clients over a wide cluster of machines, using ssh to remote spawn them. And add a console command on the beam app to set the scale/number of active clients up and down dynamically.

Last step is run 3 or more Erlang hubs with multiple distributed zig/odin processes, and use raft protocol to distribute game crud operations across the cluster. Would be cool to get this cluster to seek out new machines to auto-replicate itself to as well, preferably in an uncontrolled and unlimited fashion.

When I’m done with that, probably delete the app and get back to work.

[Dok8tavo]

I’m writing an interface for type constraints. After a few rewrites I think I’ve finally reached a satisfying design (for me).

One big problematic for me was to forbid nonsensical constaints representations (last in date was a constraint that required the type to be a non-allowzero c pointer).

I’m finishing a composable core of implementations before publishing. But I’d like to eventually implement an ergonomic type-matching mechanic among other things.

[Cloudef]

I spent yesterday porting the whole Sorvi ecosystem to zig 0.16. The sorvi cores itself did not require any code changes. Most changes were in Harha (VFS library due to IO duh), and then the ELF loading code.

I hit into one codegen bug which someone kindly had already reported https://codeberg.org/ziglang/zig/issues/35373

I hope to have first public release soonish. I’ve been playing with the zig’s self-hosted wasm backend and try to get it output valid sorvi cores so I could have live editable examples on the project’s website. Unfortunately I did not get it to produce yet valid wasm binaries.

The web frontend has been rewritten completely in mostly zig, as I got zig’s relocatable wasm binaries working It is much faster and more stable now, and I added ability to browse the sandboxed filesystem, so you can do whatever you want with the files of various sorvi cores.

You can try out various cores here (the server may be slow, some cores like elma may crash/freeze due to UB in C++ code)
https://cloudef.pw/sorvi/#supertux.sorvi
https://cloudef.pw/sorvi/#elma.sorvi
https://cloudef.pw/sorvi/#doom.sorvi

[AndreasHefti]

I currently working on Nano Dash, a game and tribute to my favorite childhood game Boulder Dash on the C64. The game will have a thin story with boss fights and power-ups too and many little additions to the original. And it comes with a built in editor.

It is all written in Zig with raylib as only dependency (no AI, whether for coding nor for graphics or sound)

[BradenEverson]

Been working on a piano playing robot alongside my more mechanical engineeringy inclined roommate. Right now the solenoid “hand” is stationary but we plan to create two belt driven hands that occupy any of the 5 octaves.

I have a minimal MIDI parser (note on/off as well as tempo and time signature), and a runtime for interpreting MIDI events and actuating the solenoids. Now I’m working on a solver that will try to plan hand movements to capture future notes that need to be played outside of the octaves the hands are at currently.

Demo video can be found in the README since I don’t think I can attach videos in here: GitHub - BradenEverson/maestro: Playing our piano · GitHub

[Logickin]

I have been building a binding from a dynamic library for a music tracker community, with additional safety features to make it more beginner friendly to handle undefined behavior and error (you many also use the original API if you wish).

Recently just updated one of my projects involving the library to zig 0.16.0 which is a simple wavetable editor for exporting Serum or Vital Like wavetable as the modular synth modules into the music tracker, with zaudio for audio preview and dvui for the gui.

Haliaeetus Wavetable - Out Now! [SunVox]

[menosbits]

I’ve been working on a terminal app launcher. It’s like rofi, but for the terminal.

I’m currently working on TUI bugs and the next steps are building a config parser and the actual application runner.

[sprsquish]

I’ve started working on a single user ActivityPub app a la snac2. I’m pretty much ripping off snac2 to learn Zig. It’s my first time really digging into Zig. I’ve spent so much time at $job using LLMs that it feels really good getting back to actually thinking about and writing software.

[jmctagger]

Does it only play in C major, or am I not seeing the photo correctly?

[SpinTensor]

I guess it can also play in A-minor.

[andrewrk]

Nice it has the same music theory handicap as me

[lukeflo]

Sounds very interesting. I’m curious to see the code and try it out.