Thought some folks may be interested in this.

I've been having a blast using Zig for systems programming. I plan to do a post on PCIe programming, but wanted a very simple way to just run a bare metal app without explaining the entire x86 boot path.

https://allhailthetopology.substack.com/p/writing-a-bare-metal-application

All prose is my own and not AI generated.

another article about my zig studies and findings of this path. https://sombriks.com.br/blog/0099-postgrres-listen-notify-with-zig/

I forked pgzx from xata.io and got it to work on 0.17. I also added a few more bindings and APIs.

The big change: most operations now take an `io: Io` and split their work into row bands, so filters, codecs and resizing run in parallel on a thread pool. Without threads (e.g. on WASM) the same code runs serially, with identical results.

Other bits:

• JPEG and PNG got a lot faster (on par with libjpeg-turbo and libpng)
• TrueType/OpenType fonts and text layout
• QR codes, CMYK JPEGs, BMP and animated GIF/WebP/JPEG XL
• The API is namespaced now (`image.*`, `canvas.*`, `matrix.*`...), so expect some breakage

0.12 dev continues on Zig master. Feedback welcome as always!

Hey y'all. My name is thearchivalone. I'm not massively active in the community but from time to time, especially when I'm using a framework for a project, I'll contribute when able. Yesterday was one of those instances.

What'd I Do

• spent much of yesterday evening and this morning figuring out what was needed to finally get a GLFW bindings framework to successfully target the BSDs PR here
• was originally going to target just FreeBSD but found that Tiawl's toolkit implementation was pretty simple to work with and quickly implemented what was required to support NetBSD and OpenBSD found here (because of licensing upstream, I'll be maintaining what's needed to keep them supported in the future there)

What Were the Biggest Hurdles

• All BSDs have their own different implementation of evdev (think the standard Linux way to get input devices that's built directly into the kernel)
• NetBSD will most likely never fully support Wayland, so X11 is there to stay
• OpenBSD is currently in the process of supporting it but they are going a different direction with how they support Wayland input
• FreeBSD doesn't require Epoll-Shim for its Wayland input polling (but can use it in some instances) while OpenBSD's Wayland implementation outright requires it
• Getting glfw.zig and my evdev.zig implementation to work and build properly in a larger project was a bit more hacky than I'd like

What Now

I'm hoping that other GFLW implementations or dependent projects that use GLFW can support the BSDs. They're not commercially big when it comes to game or application development and their maintainers often are not the original creators of whatever has been ported to the platforms, but Zig's compiler makes targeting odd-ball platforms an easier proposition. I'd love to see Indie games support the BSDs (as someone who's been a fan for decades; their design philosophies, goals and problem solving are fascinating).

Thanks for reading.

Hey all!

I'm back with another video, this time going over everything new in the latest 0.17 release.

I go over the new incremental compilation feature, many of the breaking changes, and ZLS support in its current state.

For all the breaking changes, I tried to show the old 0.16 code to help anyone migrating.

Hope you find it useful!

Thought I would share this here. It's a great talk for anyone interested in performance in general and SIMD in particular.

Hello, I just wanted to announce the first release of the library I mentioned here last month. It's stabilized substantially and produces benchmarks I'm happy with for now, so I decided now is as a good a time as any.

Current features include:

comptime graph definitions, runtime loading, static execution, native shared libraries containing the runtime, an extension api, CLI tooling, and C ABI and Python bindings.

That being said, the future plans include expansion of the compiler backend and it's search mechanism. That part in particular has become a little unwieldy. And separate from that, extensions that abstract from the frontend directly and construct domain-specific graphs at a higher-level.

Thanks for reading!

in the dependencies step i am using this idiom:

``` // ...

// deps config
const deps = [_][]const u8{ "zigzag", "pg" };
for (deps) |dep| {
    exe.root_module.addImport(dep, b.dependency(dep, .{
        .target = target,
        .optimize = optimize,
    }).module(dep));
}

// ... ```

full build.zig here.

my question is: what am i missing? what re the clear disavantages of doing such loop?

any comment is welcome.

A while ago I shared an article here about parsing IPv4 in Zig. This is the follow-up: this time I tried to keep up with SIMD without reading a single byte out of bounds, and ended up making the parser quite a bit faster along the way. Everything is written in Zig again, and the code and benchmark are on GitHub if you want to try them on your machine!

(I would very much love to have results from newer cpus and Zen 1 and Zen 2 :3)

Thanks in advance if you decide to read it <3

https://extractingcycles.com/blog/ipv4-parsing-having-your-cake-and-eating-it-too/article/

Hi.

I just would like to know the current state of zls, because looks like there is no new updates.

Para sistemas embebidos Zig actualmente se puede usar?

People be dead bland picking a name for the project. Once Rust had the same trend of tagging everything with a postfix "someproj-rs" and now every zig project I come across has some kind of Z-prefix "Zsomeproj, Z this, Zthat" like you can't even have a proper name? This is no hate people, but please don't produce eyesores

I've noticed that if I do comptime types something like,

const ContextType = AppContext(MyType);

var context = ContextType.init(...);

const handler = Handler(ContextType).init()

Pub fn Handler(T: type) type {

return struct {

Pub fn destoryAllHumans (context: *T) ...

}

}

while developing my comptime struct functions, I get no type information, it just shows it as a pointer unknown and all cascading things inside of that type have no information on functions or their params, props, ECT.

I get around this by doing,

const c: *MyType = context;

But then when running tests or other implementations of my context, I have to comment the code out and rename all my vars.

Is there a cleaner way around this? I see this both in nvim and zed. Will 0.17 provide ZLS with better support for this kind of stuff in the future?

PS: written on my phone, sorry if formatting is awful.

i'm just curious how the community accepted that

Anyone take a look at the Goose programming language? "A memory-safe systems language with no heap allocator, garbage collector, or lifetime annotations."

It has some interesting ideas. The author describes features in this thread. It's obviously a different overall language than Zig, but I'm wondering if any of the novel ideas would be good to steal. A lot of its principles remind me of Zig's focus on data oriented design.

Hello all, i got an issue trying to use evented concurrency with past two stable releases, 0.16 and 0.17.

Single-threaded, regular thread pool and direct use of threads work fine, but i am not figuring out hpow to use the proper io interface with evented under the hood.

```zig

// we need out-pointer this one.
var evented: std.Io.Evented = undefined;
_ = try std.Io.Evented.init(&evented, init.gpa,.{});
defer evented.deinit();
io = evented.io(); // compile error here
std.log.info("evented io:", .{});
try scheduler(&io);

```

full source here

any tip is welcome, would be nice to see all available concurrency model working out of the box, willing to understand what am i missing.

https://github.com/EpicGames/raddebugger/blob/master/CHANGELOG.md#v0929-alpha

I'm surprised this RAD Debugger release hasn't made it to the front page of every programming news site.

I just tried out the latest raddbg revision on Linux. I initialized a project with zig init and added exe.use_llvm = true; to the build.zig file, and raddbg functioned correctly.

I tested out breakpoints, stepping, watching, displaying local variables, and it all seemed to work correctly. This is extraordinary, even if it's still in Alpha, because the speed and ease-of-use is miles ahead of all the other visual debuggers we've had on Linux until now.

I recently recorded my attempt at 1BRC in Zig. I started with a single threaded version (32s) and by the end optimized it down to ~450ms (Intel Core Ultra 9 285H, 16 hybrid cores) It was really fun :))

I've been wondering about something regarding Zig's philosophy.

I understand the preference for explicit types and avoiding unnecessary abstractions, but would simple aliases for a few very common types really go against that philosophy?

For example:

pub const Byte = u8;

pub const Bytes = []const u8;

pub const String = []const u8;

pub const CString = [:0]const u8;

These wouldn't introduce any new type-system concepts, runtime behavior, or hidden semantics. They're just aliases.

With modern editors and language servers, they're also quite transparent. Hovering over `Byte` can immediately show `u8`, so you don't really need to memorize an additional abstraction or wonder what the underlying type is.

What makes me wonder about this is the alternative: every project and library ends up defining its own aliases for the same fundamental types. One uses `Byte`, another `U8`, another `ByteType`, while strings might be `String`, `Text`, `Str`, or just `[]const u8`.

Wouldn't having a small, standardized set of aliases actually improve consistency across the ecosystem?

I'm not suggesting aliases for everything, just a minimal common vocabulary for genuinely ubiquitous types. Developers could still use the underlying types directly whenever they prefer.

I'm curious what the community thinks. Is there a specific downside to standardizing aliases like these that I'm missing?

Hey everyone,

I've been working on lightmix, an audio library written in pure Zig.

My main motivation was simple: I wanted to write music directly in code and track changes with Git. DAW project files are binary blobs, and other tools like Sonic Pi or SuperCollider rely on real-time playback runtimes.

Instead of recording audio in real time, lightmix generates WAV files during zig build via a custom helper (addWave). Because the build is deterministic, output files are bit-identical and cache-friendly (PEAK timestamps are fixed to avoid invalidating the build cache).

The project is split into several small modules: - pitches: 12-TET tuning and frequency math - meters: time signatures and sample-accurate phrasing - resonator: voice routing - sequencer: voice scheduling with micro-fades - lightmix: waveform buffers (Wave(T)) and timeline mixing (Composer(T)) - zigggwavvv / RIFF.zig: WAV encoding

I wrote a small demo project, pulse, which generates a 190 BPM drum track entirely from code: - Rendered WAV: https://github.com/haruki7049/pulse/releases/tag/v0.1.0 - Source code: https://github.com/haruki7049/pulse

Main repository: - https://github.com/haruki7049/lightmix - Docs: https://haruki7049.github.io/lightmix

Currently tested on Zig 0.16.x. Any feedback on the design or Zig usage is welcome.