A well established serialization / de-serialization API is needed, like rust’s serde, or python’s pydantic, that supports
json
messagepack
ZON
CBOR
CSV
YAML
Something that supports configuration files and allows me to write validation logic. I imagine that this should likely come after “writer-gate” changes that are planned for the standard library soon (refactoring of reader, writer API).
I’ve attempted to make progress on the serialization front with GitHub - kj4tmp/lizpack: A MessagePack Library for Zig , but I’m not super happy with how I have accomplished serialization options (choosing array or string when serializing [] const u8 for example). Probably deserves its own topic.
The library likely needs to support
both allocation and zero-allocation deserialization / serialization
I already use Zig for all my personal projects.
Its not really a library that i am missing.
Since we are talking about useage in production, my company at this point uses Zig to build part of its C code. If we are at any point switching into it, it would be because of the IO interface. (we do IO intensive stuff, and belive it would be more optimal then our current implementation, also we could benefit from the Zig ecosystem)
So we are looking towards IO interface being released and libraries moving towards it. This would also propably help with the parsers mentioned above, you could make a parser directly parsing from IO input as it would be comming in?
For me it’s less about libraries, but about additional language interoperability options.
For instance, the “one missing thing” before I could consider switching smth fundamental like the sokol headers over to Zig would be some solution to access macOS/iOS ObjC framework APIs with the same ease as @cImport or translateC.
E.g. being directly able to import any framework header like Cocoa or Metal, and coding against those APIs with the same ease as using ObjC directly.
A similar situation may arise for C++ if Microsoft drops C API support for D3D (unlikely, but there have been subtle ABI compatibility problems in D3D12 in the past which clearly show that the D3D team doesn’t care much about C).
…and similar for WASM support on the web, e.g. having an Emscripten-like ‘web api’ package which wraps web APIs like WebGL, WebGPU, WebAudio and with the same optimization options for the JS shim code and WASM like Emscripten does (e.g. ‘linking’ a single JS shim from many per-web-api shims, running that through a JS optimizer, and the same for running the WASM output through Bynarien/wasm-opt).
…some (most?) of those things could be handled through complex build.zig.zon packages which include helper tools for code generation and optimization.
But OTH: I still firmly believe that most non-trivial Zig projects will be mixed-language projects (typically Zig/C, but also Zig/C/C++/ObjC, maybe also Zig/Rust or Zig/Swift), so instead of “porting the world” to Zig I would rather see that same effort put into “tearing down the walls” between different language ecosystems.
while this is true with status-quo Zig bindings, i’m not sure that it’s always the case. eg. my understanding of the implementation of ARC and blocks is that there’s what is essentially C codegen that the compiler does when compiling Objective-C, adding calls to specific “retain/release” symbols or adding struct definitions in the case of blocks.
certainly some of that could be made much simpler to hook into with Zig. i’ve been working a bit haphazardly on it for a while over at this repo.
Yes, but (AFAIK) the most important feature of ARC is that the compiler does static ownership tracking and avoids adding redundant retain/release calls (e.g. it’s basically figuring out if an assignment works like std::unique_ptr (e.g. no retain/release needed because ownership is moved), or like std::shared_ptr (e.g. retain/release is needed because ownership is shared).
I don’t think that can be done with a simple code transform, instead in order to implement ARC the compiler needs to analyze the AST.
It might be off-topic but it would be nice to have a retained mode, cross-platform “native” looking GUI library. Something that would be backed by gtk on linux, the win API on windows, etc…
A doubly-linked list can be used to perform stack and queue operations but they are are verbose.
Making it usable with generic data types would be would help cut down a lot of boilerplate.
Also, adding methods like toArray to return the underlying data, and contains to perform a search would make it more usable.
Not libraries, but these would improve development ergonomics significantly:
Improved integer casting
Graph traversals require coercions to and from usize and isize to check for boundaries.
For example, declarations like const row = @as(isize, @intCast(vertex.x)) + delta[0]; get in the way of readability. Something like const row: isize = vertex.x + delta[0]; is a lot more readable.
And not some “We’re lock free until you do something silly like, uh, iterate across keys at which point we take a gigantic lock” (looking at you, Rust). No, genuinely, truly lock-free no matter what operation you are doing.
Is this complex? Yeah. Is this an open problem is CS for compiled languages? Possibly.
But, man, I miss “java.util.concurrent” every single day when not able to access the JVM.
