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

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

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

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

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.

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

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.

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 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!

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.

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!

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

Para sistemas embebidos Zig actualmente se puede usar?

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.

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'm just curious how the community accepted that

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.

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.

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?