Hi.

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

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.

Heya! Just asked CS Academy for Zig 0.16 support. Mihai, kindly attended my request and submissions can be now done in Zig!

This also means Zig will be an option in the upcoming IEEEXtreme 20.0, since the contest runs on CS Academy.

For those unfamiliar with the platform, CS Academy (csacademy.com) is a competitive programming site. You pick a problem, submit your code, and it gets run against hidden tests. It's a nice platform because it also has lessons on data structures and algorithms, so you can learn there as well.

They even asked me if there are any libraries beyond std worth bundling. I told them std is plenty, but they're open to suggestions, so reach out to [contact@csacademy.com](mailto:contact@csacademy.com) if you have any!

On a side note, I maintain a fork of competitest.nvim that lets you submit to CS Academy and Kattis (also supports Zig) right from Neovim and shows you the verdict: https://git.yhkze.net/yuuhikaze/competitest.nvim/

AI is advancing in many fields including game dev, mostly no game achieved anything but the prototypes are "great".

But I've just read a excelent developer that used three.js to create awesome mathematical rendering thinking about stopping its development and somehow retire, he said someone upload his video about wave and water render with openai astra and it got 90% right.

I just thought Zig is the last banner of anti AI dev(or maybe friendly AI usage) along with C and C++ devs.

That's sad, I know people say "now devs can focus on product and ship it faster" but for me coding is fun and really brings out our long developed knowledge, all projects I had to do full vibe coded brought me no joy.

Whats your toughts?

Zigar, the toolkit that allows you to use Zig in your JavaScript or PHP projects, has been upgraded to support Zig 0.17.0. This time around I'm able to get it out quickly since the project was already tracking master.

When running zig init, the template scaffolds both an executable (main.zig) and an exportable module (root.zig) in build.zig.

Just want to verify if my mental model is correct: 1. If I only want an executable (and don't plan to export a library/module), can I simply delete root.zig and remove the module-related exports/artifacts from build.zig? 2. Is there any built-in zig init flag or alternative command to scaffold an executable-only project without the library boilerplate?

thanks!

For example, some piece of code that looks like this:

public foo(a, b)
{
    return fooImpl(a, b);
}

private fooImpl(a, b)
{
    // 100 lines of logic
}

I'm talking about this kind of pattern, which I have seen everywhere pretty much. When we have the "public API" with functions that we expose publicly, that just calls into other function that isn't exposed publicly, where the implementation lays.

I just don't get the idea behind the "extra step". Why not just expose the implementation function publicly?

If it requires some slight tweaks that won't affect return value nor the arguments it takes, then there are no problems.
If it does require some tweaks which will affect return value and / or it's arguments, then the public function will require changing as well.

Some sources online mention "logging", but then why not just log at the top and then continue with the function, why log in a separate function and call into another function?

Some sources mention multithreading, which I'm not that experienced with, so I'm hoping my answer lays somewhere in there.

Please help me reason about this because everything I can think of as a justification for something like this, makes no sense. And seeing it everywhere makes me assume there has to be a good reason that I'm just missing and unaware of.

Hi r/Zig! A while ago I posted about PyOZ, a library for writing Python extension modules in Zig (think PyO3, but Zig). 0.13.1 just came out and it's a big one, so here's an update.

What it looks like

const std = @import("std");
const pyoz = @import("PyOZ");

/// Runs on a std.Io task, off the GIL; cancelling the asyncio task cancels it.
fn fetch(io: std.Io, n: i64) !i64 {
    try io.sleep(.fromMilliseconds(100), .awake);
    return n * 2;
}

const Countdown = struct {
    n: i64,

    pub fn __aiter__(self: *Countdown) *Countdown {
        return self;
    }

    pub fn __anext__(self: *Countdown) ?i64 {
        if (self.n == 0) return null; // StopAsyncIteration
        defer self.n -= 1;
        return self.n;
    }

    pub fn scaled(self: *const Countdown, args: pyoz.Args(struct { by: i64 = 10 })) i64 {
        return self.n * args.value.by;
    }
};

pub const Module = pyoz.module(.{
    .name = "demo",
    .funcs = &.{pyoz.func("fetch", pyoz.asyncFn(fetch), "Double n, asynchronously").withParams("n")},
    .classes = &.{pyoz.class("Countdown", Countdown)},
    .gil_used = false, // safe on free-threaded CPython
});

await asyncio.gather(*(demo.fetch(i) for i in range(1000)))   # ~0.45s
[x async for x in demo.Countdown(3)]                          # [3, 2, 1]
demo.Countdown(4).scaled(by=3)                                 # 12

Everything is generated at comptime from plain Zig declarations: argument conversion, classes, dunder methods, keyword arguments, and .pyi type stubs. The stubs are embedded in the binary and extracted when the wheel is built.

What's new in 0.13.1

• Zig 0.16. Ported to the new std.Io. The CLI no longer uses C at all: the vendored miniz went away in favor of std.compress.flate, so it's a single static binary.
• Async on std.Io. pyoz.asyncFn / pyoz.asyncMethod turn a Zig function into something you can await from Python (an asyncio.Future). It runs on its own std.Io task without the GIL, and cancelling the Python task cancels the Zig one: the next Io call returns error.Canceled. Classes can also implement __aiter__, __anext__, __await__, __aenter__ and __aexit__.
• Free-threaded Python (3.14t). Every method, property and protocol slot runs under a per-object critical section, so one Zig object can be shared between threads with no GIL. It costs nothing on regular builds, since the locks are removed at comptime.
• Cross-built, portable wheels. This is where Zig shines. pyoz build --release --target all builds wheels for Linux, macOS and Windows on x86_64 and aarch64 from a single machine, for any CPython 3.10–3.14 including free-threaded builds. Wheels target glibc 2.17 and a baseline CPU, and the platform tag (manylinux_2_17_x86_64, macosx_13_0_arm64, …) is read from the built binary, so they're ready to upload to PyPI. No Docker or CI matrix needed.
• Keyword arguments on class methods via pyoz.Args(...), contributed by marselester.
• Complete PyPI metadata, and pip install from source works even without Zig installed: the build backend falls back to the ziglang package.

Links

• Docs: https://pyoz.dev (the upgrading guide covers moving from 0.12: https://pyoz.dev/upgrading/)
• Repo: https://github.com/pyozig/PyOZ
• pip install pyoz, then pyoz init myproject

Feedback, bug reports, and contributions are very welcome, especially from anyone using free-threaded Python or cross-compiling wheels.

Its Zig bindings over our C Diavasi client. Same gRPC consume contract: TLS, join a group, ack batches; server keeps the cursor.

Zig 0.16 + libgrpc.

https://github.com/diavasis/diavasi-zig.

This cpu "emulator" is more of a CPU simulator since i don't understand shi about CPUs.
sorry if you were looking to find some LC-3 or some things like that.

Its a 16-bit cpu with 128 registers, and a 128 KB stack (you use offsets to manipulate it).

The most fun part for me right now is the assembler because this is the first time I'm making a lexer and stuff in something other than god-dang C#.

Whilst developing this I've come to learn lots of new things and use much less AI.
For example I learnt you're not supposed to use catch with try like in mainstream languages.
and i also scratched the tip of the iceberg that is ownership.

Github: https://github.com/orewaluffy500/fox16

I wrote a simple documentation for writing machine code directly and I'm still working on the assembler (today I wrote the base for the compiler so I can add more instructions and eventually labels)