Hi, I'm new to Zig and didn't have much to play with, I came from Rust and wanted to know what are the advantages and disadvantages compared to Rust

From an Andrew Kelley comment on codeberg:

Current plan is

1. resilient parser
2. syntax errors no longer stop the pipeline, nor do they stop zig fmt from working, same thing with unused var decls
3. hard tabs become errors again, but fixed by zig fmt
4. #presence of errors causes compiler to report failure, but still produces a binary anyway, so you can still use it ... if u nasty

https://codeberg.org/ziglang/zig/issues/37375#issuecomment-26357399

Doesnt #4 basically means they are warnings then?

2 is desperately needed. Zig compiler bugs out way faster than any other language I use.

3 is going backwards again.

Hi! I have only 1-2 years of experience in C/C++ and 1 day ago I starter learning zig. But the syntax is confusing and I can't understand the philosophy. For my first zig-evening I barely could understand functon arguments, I mean pointers in function args. It's me or zig is really differenti from C? Like it hasn't anything Mike C! It's completely different.

How can I start, how can understand zig?

Also I think zig is really cool, but I can't build anything with Zig because I don't have studied control flow in Zig. How you guys learned zig? What mindset do I need to program in zig?

I'm sorry if my eng it's bad but I'm noto eng. Thanks for reading this yapping ❤️

https://codeberg.org/ziglang/zig/issues/37375

As I understand, it will forbid top-imports in file-level structs.

Hey everyone!

I noticed that Zig's std.fmt.byteToHex doesn't use SIMD, so I built hex-zig, a SIMD-accelerated library for hex encoding and decoding.

It provides speedups, especially for larger inputs.

Check it out: https://github.com/52funny/hex-zig

Feedback and suggestions are welcome!

We Have Traits at Home

I was noodling for a while with some functional programming languages, and in the process I stumbled onto a rather nice way to handle comptime abstraction. After using it in a few places, I thought I would type up a blog post and share.

The gist: you can imitate OCaml modules or Rust traits at comptime, and it can be a nice way to make your function interfaces more explicit without involving VTable machinery.

My blog is fairly young, and I'm thinking of writing more articles in this direction, so any feedback is very much appreciated. Let me know what you think, and if you would be interested in more articles that expand on this idea.

Made a Hack Assembler in Zig as part of project 6 of the Nand2Tetris course, also took the oportunity to learn about static allocations and follow some patterns used in TigerBeetle, so for example in the SymbolTable I'm using StringHashMapUnmanaged and using ensureTotalCapacity with a hard cap, so that later I can add items to it using putAssumeCapacityNoClobber. I recommend this blog post to learn more about it https://nickmonad.blog/2025/static-allocation-with-zig-kv/

Why is this issue happening? Please help. What other information should I provide?

Hey! I'm working on a terminal manipulation library in Zig called termy, inspired by Rust's Crossterm. It's still early in development, and I'm trying to figure out the API before I get too far into the project.

One thing I'm unsure about is whether terminal operations should work directly, like this:

try termy.setForeground(&writer, .red);
try termy.writeAll(&writer, "Some Error!\n");
try termy.setForeground(&writer, .reset);

Or whether I should use a queue-based approach, similar to crossterm where you queue multiple commands and write them together:

try termy.queue(&writer, .{
    termy.style.Fg.Color{ .Red = {} },
    termy.style.Print{ .msg = "Some Error!\n" },
    termy.style.Fg.Color{ .Reset = {} },
});

try writer.flush();

I'm not sure which approach makes more sense in terms of performance and usability, or which feels more natural to use in Zig. I love how the data-oriented approach looks, but I think it may affect performance.

I'd appreciate some feedback!

• Which approach would you prefer, and why?
• Would it make sense to support both?
• Are there any common mistakes I should avoid when designing a Zig library?
• What features would make you choose termy over other terminal libraries?

I'm still working on the fundamentals, so I'd rather get the design right now than have to change everything later.

I’m not sure if this is the right place for a post like this, given that the game itself is written in Rust, but I thought you might find it interesting. You can try it out here: https://livedox.itch.io/vix. I’d be happy to answer any questions

Hi.

Just zls is released :D

https://github.com/zigtools/zls

Hi all!

I work as a Linux system admin, and I have to give a little internal presentation at work.

I thought it would be a fun idea to stay in the spirit of Linux and system administration and present everything very simply through a terminal! :D (just an excuse to practice my Zig skills)

So I made this simple thingy over the weekend.

It prints ASCII title/subtitle, then steps through the slides.
Each step can either be just a line of text, or it can call feh and open an image to show something visually.
At the end of each slide, it asks for input to either keep going, go to the previous slide or just quit out.

I know it's an EXTREMELY simple project with nothing fancy going on, but I just thought I'd share it if anyone wants to use it for the similar purpose or has any suggestions to extend it further and make something more interesting out of it!

https://codeberg.org/neuroDEVergent/terminal-preZent

i install zig and zls and zvm and i dont know what to do next

Hello, I built an open source IDE on android, it took me 2 years to build this as a solo developer. It's not vibecoded(you can check the commit history).

In the new release, I added the zig compiler and zls LSP server to the app. It's completely offline.

For people saying "why would I code on the phone if I have a PC", the app is not intended for building production level apps, it's intended to do small prototyping, quick testing of snippets, learning syntax, and especially for leetcoders.

There are many features like git and GitHub integration, AI code completion, Agentic sessions, 245 themes, local gguf models, termux integration, etc are available in the app.

Also, the app is completely free and open source. So no ads, no payments or anything.

Source code: https://github.com/heckmon/roxum-ide

Playstore link: https://play.google.com/store/apps/details?id=com.roxum

I started Zig a few weeks ago and I've had many issues with console things, The only time it's easy is when I'm allowed to use debug prints.

So I decided to make my own library, And I wanted to make it so the writer/reader's themselves own their stuff.

The library provides two structs, `Writer` and `Reader`, each have 1 base constructor and default constructor(s) too.
They both give you methods like `printline` and `read` aswell as their ignorant counterparts such as `printlineIgnoreError` and `readIgnoreError`.

I would love feedback since I'm sure there's at least one memory leak I didn't find.
I have made an IO helper previously but that was almost entirely vibe-coded, This time I actually read the documentation and figured stuff out on my own.

Thanks for viewing this! The repository is at https://github.com/orewaluffy500/rustyio

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.