Applications and libraries that use the 0.16.0 preview of std.Io

I have been noodling with the new std.Io interface, and while I have been able to get pretty far by reading the standard library docs and code, and blog posts on the matter, it is always helpful to look at how things are used in practice. Are there good examples of applications or libraries that use the new std.Io that are worth looking at? Feel free to plug whatever you’re working on that uses it, even if it’s just something like AOC :smiley:

1 Like

I have integrated it for timers, but I am still working on networking, and I haven’t added concurrency yet either.

My biggest revelation so far is that std.Io.Duration is actually a nice type to have.

2 Likes

Fun fact, I have actually been using gatorcat in one of my projects :slight_smile: (but I haven’t fully upgraded it to 0.15.0, let alone 0.16.0)

zaprus - do THINGS with NETWORKS in ZIG

2 Likes

When I last looked a while ago, there wasn’t a working kqueue implementation, so that ruled out experiments on Mac / bsd for me. So been happily “stuck” on 0.15.x for a while, no problem with that.

looking at the stdlib code now (a shallow look anyway), appears to be a decent kqueue module, complete with both x86 and arm64 asm for context switching and a “Fiber” struct (stackfull coroutines ?)

Don’t know yet if it’s totally complete … but looks like it may be ready to play with at least. I could be wrong, but I think Loris has been doing his dev streams on Mac ?

will try over the next few weeks building :

  • an example stdlib only http server that uses coroutines for handlers, if that’s possible yet
  • Experiment with adding an option for long lived coroutine handlers in http.zig-dev using the new Io
  • Experiment with replacing http.zig thread pool with std Io (might take a bit longer, big change)
  • Extend the Datastar zig SDK to use stdlib + coroutines (currently assumes http.zig and thread pool with short lived handlers)
  • Get the D* demo apps all working with this, and add some that employ long lived coroutine handlers to show that off as a viable option.
  • Trivial benchmarks of the 2 approaches (long lived coroutine vs thread pool + long lived open connections list) compared with the same solution in Go.

I’m hoping at least to be able to demonstrate an async http service that handles around 20k concurrent long lived SSE connections on a small box. Currently achieving that with the thread pool + open connections list approach, although the ergonomics of it are a bit jank.

Might work now already, or might have to wait a bit till 0.16 settles

1 Like

What platform are you noodling on ?

Linux + iouring, Mac, etc

I am on Linux, but I have been sticking to the Threaded Io implementation, since it seems much more solid (not sure if the story has changed since I first started playing around with it though). I would definitely love to see those programs as you are able to get around to them! Especially the last one; I am actually working on porting a Go application to Zig myself.

2 Likes

Ah - my little experiment is going to take a while longer :frowning:

No major issue - the new Io vtable continues to grow a bit, and implementation details in Threaded are not 100% in Evented yet. And kqueue still has some major chunks as TODO still, which prevent doing a full http server using Evented outside of iouring.

Bits of it already run, and they do look good. Will give it a few more weeks and try again.

A few days ago i upgraded Tobias Simetsreiter / zig-git-crawler · GitLab

to zig master, because i hit an integer overflow in the 0.15 writer…

It’s using Thread Groups with std.IO as opposed to everything single threaded now.

Do you know about ccusage?

A CLI tool for analyzing Claude Code/Codex CLI usage from local JSONL files.

However, it’s yet another terminal app written using web tech.
I thought writing a version in Zig would be a great way to explore the new std.Io API:

  • parse all the files using std.Io.Threaded
  • read the JSON files by streaming them from disk
  • download the price per million tokens of each model from the web
  • optionally upload the results to a dedicated internal server

I built a version in Zig, with support for more agents (CCusage only supports Claude Code and OpenAI Codex) which is 20 times faster and uses about 80 times less memory.

Not sure it’s the most idiomatic way of doing it. I keep reading the std lib and changing the code from time to time. Feel free to take a look and point out improvements.

Mandatory poop screenshot: