What's everybody working on?

Now that 0.16 is out, I’ll try to update my TUI radio player zignight to the new compiler. The interface is done with Libvaxis, and it is dedicated to radios from the Nightride network.

Then, I’ll update it so users can make their own radio stations list instead of the hard-coded ones.

I didn’t take the time to upgrade it to 0.15, so I’m expecting quite some work.

6 Likes

I’ve been working on a platform for dna vector construction that will eventually be open sourced RUO. It uses a proprietary construction system that requires a license to then create a gene/cell therapy from.

The program encapsulates research, vector design, architecture, construction, inventory, results tracking, and more. The design and architecture happen in a combinatorial fashion and have some culling aspects based on functional targets and wanted funtionality. With a lot of on demand db queries filling in blanks.

Some parts in Zig, some in Go. Basically anything that needs to be highly managed memory-wise is in zig, including a custom gateway as some things are hosted on prem and we had some problems with more generic solutions.

I have a rendering background and mostly worked in C++ in the past for other tools. One was an engine for creatingmolecular simulations. Basically a game engine a computational biologist could use to create cellular interactions and simulatie therapeutic interventions 3 dimensionaly and show scientists the interaction.

It’s pretty stale at this point. I’ve wanted to remake in Zig, and rhe latest release notes and responses in recent threads make me feel like that is more of a possibility.

We are currently spinning out two therapy Co’s as a POC for the entire platform and the actual biology. Hoping in a few years most of this can be used by anyone. Our team includes 8 people with just me as the only programmer. So it’s been slow going.

6 Likes

I’m building an MPV client Shaven using libmpv that allows clients to be synchronized (essentially a watch party feature). The GUI is rendered using my imgui rendering library knots that I have been working on for the past month or two. It essentially is just an MPV client hooked up to an http server acting as an echo/relay point (also written in Zig), nothing clever being done really unlike some other projects in this thread, still having a blast writing it all in Zig :slight_smile: . Io has also been a real joy to use, really looking forward to all the different Io implementations to be fully implemented. Kudos to all the contributors, you guys have really outdone yourselves!

Apologies in advance for the lack of documentation, I will try to add some instructions on how to set it all up once I am satisfied with the client. Below is a screenshot of the playground app built using knots. You can find a small demo video in the repo for Shaven.

7 Likes

Still mainly working on my own programming language Ray and a bit on a SDF raymarch renderer using awesome @castholm SDL3 bindings. Still very WIP.

7 Likes

I just thought that I don’t have enough graph theory in my life :star_struck:

6 Likes

8 posts were split to a new topic: The removal of std.Thread.mutex and std.Thread.futex from the synchronization primitives saddens me

I’m working on my composable desktop workflow orchestration CLI toolbox (hope you enjoy my buzzword salad) called bmo, which is my eternal hobby project which also drives most interaction with my i3 desktop such as quick opening files, URL’s, command launch memory, state switching (and transition handling), terminal opening and hacker style dmenu-driven custom menus.

The bmo toolset itself is pretty niche (and far from presentable form) but the learning is really fun because writing it as just a CLI could make my life easier, I’ve decided to treat it as API to give myself a “dojo” to try out what works and what does not when working across multiple levels on the stack frame: how to manage memory, contexts, lifetimes, and my recent “enemy” - error payload handling. And since bmo makes heavy use of several of my own Zig dependencies (eg. zig-bareini), I can work on both sides of the API contract.

Past week I’ve been focusing on error payload handling.

First, I’m a stickler for helpful error messages. For example, for config errors I always want to report details like file path and line/column numbers, but do so regardless of whether the error comes from tokenization (inside my zig-bareini lib) or it’s domain of the specific tool (ie. semantically invalid or ambiguous config options).

Earier version of bmo would make this relatively simple, since in most cases simply std.log + std.process.exit while the error details are still fresh would be enough. Treating it as API, however, is more fun.

Recently I’ve been adopting Diagnostic pattern, where I require API user to instantiate a Diag struct and pass pointer to it, and specific error code then signifies that details have been saved, and the diag itself can help with the reporting and even outlive the context of the API call. However, it becomes more tricky once I start to combine various diagnostic structs and still want to preserve ergonomics.

I was literally in the middle of figuring this out when Andrew announced this thread on Libera :slight_smile: . So back to work! :hammer_and_wrench: :brain: :pick:

Edit: I’m still doing all this on 0.15.2. Once I get something that kind of works well, I can’t wait to start updating my code to 0.16.0.

3 Likes

as a fellow DSP nerd, I’m curious about this! Is there a repo for this ? Would love to take a look at it :slight_smile:

Been updating the codebase of Traction Point, the game I am working on, to Zig 0.16. Here’s my particle effect editor, in which you define the effect using a node graph. Normally I just interpret the data at runtime, but I’ve been working on having the editor compile the effects to native code, by generating Zig code as you can see in the smaller window. Now works with 0.16 too :smiling_face_with_sunglasses:

14 Likes

nice, wishlisted!

I’m also reading through at your blogpost about the zig modding and I’m really liking this part:

This is one of the reasons I think using Zig for modding is so nice. You only need the Zig compiler and my modding SDK, and you can start writing your own mod, perhaps using one of the example mods as a base.

Esp. because modding can be a great way to get into programming, and I like the idea of a future where people can get into programming with basically just zig.

5 Likes

Wait you can code on your phone?
How is your experience using a keyboard-based editor on your phone?

I had the assumption that programs like that are only “good” on PC (without actually testing it, the most dangerous type of assumption). I would be very happy to be proven wrong.

Thanks! Very kind of you to add the links here too :wink:

And yes, Zig is awesome for modding! Especially since the out-of-the-box wasm support allows you to sandbox it.

1 Like

Main Project

Earlier this year I made a game prototype, and brought it to a local Seattle Indies play testing event. It went pretty well, so I’m spending more time figuring out if this is a project worth pursuing. Currently that means setting up a rendering stack, and doing an art test for a style I want to try. Sorry, too early for screenshot on this public of a forum.

Other

I’ve hosted a couple Zig Day Seattle events at this point. The next one is probably a month or two away. Sign up for notifications at https://zig.day/usa/seattle/

I did a test on implementing multi-threading in wasm/js, as an exploration for the awebo project. https://codeberg.org/ScottRedig/zig-wasm-minimal-multithreading

During the most recent Zig day Seattle I updated my websocket via Io.Reader/Writer experiment to 0.16, and got the autobahn testsuite to run against it. There’s some more work to be done here, but will be a PR to std at some point: https://codeberg.org/ScottRedig/websocket_test (more context: https://github.com/ziglang/zig/issues/24937)

https://github.com/scottredig/zig-javascript-bridge (easily call JS from Zig WASM) and https://github.com/scottredig/zig-demo-webserver (host the install folder on a webserver, pure build system) have been updated to 0.16.0.

4 Likes

Unfortunately, I currently don’t have permission from my company to publish this. But we’ll try.

1 Like

honestly i dont personally code on my phone. The reason why i built this was because of the coding agents i kept using (amp specifically).
I keep wanting to prompt my agents from my phone when i am outside, and prompting is like a chat. The nvim above is just to show what can be done, because i have definitely seen ppl use phones to code on HN)

1 Like

Gotcha, nonetheless, I’ll check it out and see if I can take inspiration to port my project to phone. Fingers crossed keyboard based and phone are not mutually exclusive.

I’m working on a correct, safe, highly-understandable concurrent run-time and language (CLEAR) that transpiles to Zig (the runtime is also written in Zig).

I just migrated it to Zig 16.0 → but I’m still trying to figure out how/where I might be able to use the new I/O.

The goal is to make the power of Zig and the safety of Rust accessible to almost the highest level of language users (Ruby, Python, Lua, etc) - and to make safe, concurrent code as understandable and accessible as SQL.

Without Zig, this project would be considerably harder (and have less benefits). The Zig build system and compiler rules!

5 Likes

Currently I’m working on a very cool project for work which I can’t really talk about for security reasons, but it involves rewriting a subset of libcamera to Zig using raw V4L2 bindings and integrate them with IO, rewriting a subset of opencv in Zig, porting a beautiful bluetooth/ble library from C to Zig, porting a beautiful qrcode reader from C to Zig (which is already done and 40% faster than the C version and 1800% faster than the one in opencv thanks for @vector(). Porting a driver for the ICM_20948 9axis imu from C to Zig, and a custom firmware from C to Zig, all of that is doubly secret because my boss doesn’t know about it, but I already doubled the battery life rewriting this firmware from C++/python to raw C. Now it’s time to scrap the barrel and get the remaining 20/30 % using Zig and to finally make this firmware easy to test, ultra portable, dependency free, and enjoyable to maintain because it’s written in a fun language. :slight_smile:

13 Likes

:frowning: I’ll keep an eye out for it if it ever does!

this is the way :laughing:

no gods, no masters

10 Likes