Tool</th>	Elements</th>	Size</th></tr></thead>
Arrays</td>	Same</td>	Comptime</td></tr>
Many-item pointers</td>	Same</td>	Runtime</td></tr>
Structs</td>	Different</td>	Comptime</td></tr>
???</td>	Different</td>	Runtime</td></tr> </tbody></table> At this point, you’ll notice a missing piece – what if we want to access contiguously stored data, with differing types, but the size/length of that data is only known at runtime?</p> A use-case</a></h2> It’s fun to design tools for imaginary problems, but before we continue, is this really something that people need? I believe that it is. Here is a snippet of code</a> in Zig’s standard library where such a thing might be useful.</p> The status quo</a></h2> To do this today, you essentially have to take the following steps:</p> Calculate the size of the data you need to store</li> Allocate a `[]u8</code> to store it in</li>` `Break up that byte slice into pieces for each field using a lot of @ptrCast</code>/@alignCast</code></li>` `Initialize the data in each field, making sure to keep track of all runtime lengths</li> </ol> Here I have done so using a simplified version of the use-case from the standard library:</p>`// A known-size data structure</span></span> const</span> Connection</span> = struct</span> {</span></span> client: Client,</span></span> host_len:</span> usize</span>,</span></span> read_buffer_len:</span> usize</span>,</span></span> write_buffer_len:</span> usize</span>,</span></span> };</span></span> </span> // First, calculate the size of, and then allocate, a byte slice for the data</span></span> const</span> length</span> =</span> calculateSizeAtRuntime</span>(input);</span></span> const</span> bytes</span> = try</span> gpa.</span>alignedAlloc</span>(</span>u8</span>,</span> @alignOf</span>(Connection), length);</span></span> </span> // Then break up that byte slice into its components</span></span> const</span> conn:</span> </span>Connection</span> =</span> @ptrCast</span>(bytes);</span></span> </span> const</span> host_offset</span> =</span> @sizeOf</span>(Connection);</span></span> const</span> host</span> =</span> bytes[host_offset..][</span>0</span>..input.host_len];</span></span> </span> const</span> read_buffer_offset</span> =</span> host_offset</span> +</span> input.host_len;</span></span> const</span> read_buffer</span> =</span> bytes[read_buffer_offset..][</span>0</span>..input.read_buffer_len];</span></span> </span> const</span> write_buffer_offset</span> =</span> read_buffer_offset</span> +</span> input.read_buffer_len;</span></span> const</span> write_buffer</span> =</span> bytes[write_buffer_offset..][</span>0</span>..input.write_buffer_len];</span></span> </span> // Initialize the known-size data, storing runtime sizes</span></span> conn.</span> =</span> .{</span></span> .client</span> =</span> input.client,</span></span> .host_len</span> =</span> input.host_len,</span></span> .read_buffer_len</span> =</span> input.read_buffer_len,</span></span> .write_buffer_len</span> =</span> input.write_buffer_len,</span></span> };</span></span> </span> // Initialize the runtime sized data</span></span> @memcpy</span>(host, input.host);</span></span></code></pre> Doing all of this correctly can be tricky. Even just the first step is more complex than you might think. In our example, the host and buffer fields are both arrays of u8</code>s, but what if the elements have an alignment requirement? If your fields are not ordered correctly, subsequent fields may become unaligned if you don’t pad correctly. If you don’t track all of the lengths, you can accidentally introduce undefined behavior, and as a result, possible security vulnerabilities. Let alone resizing the thing if the lengths change later!</p> We can do better!</p> Variable Length Arrays</a></h2> As an aside, some programming languages have a concept of variable length arrays</strong> (VLA). The idea is to have an array (stack allocated contiguous data) with a length that is known at runtime (it is variable).</p> Zig does not, and will not</a>, have VLAs in the language spec. Instead, you can allocate a slice on the heap. If you want to have the data on the stack, use an array as a bounded backing store, and work with a slice into it:</p> // We have an upper limit of 32 values</span></span> const</span> my_buffer: [</span>32</span>]</span>u64 = undefined</span>;</span></span> const</span> my_vla: []</span>u64 =</span> my_buffer[</span>0</span>..runtime_length];</span></span></code></pre>Dreaming up an API</a></h2> Variable length arrays don’t, and won’t, exist in Zig, but what if they did? We might have defined our Connection</code> type something like this:</p> const</span> Connection</span> = struct</span> {</span></span> client: Client,</span></span> host:</span> </span>VariableLengthArray</span>(</span>u8</span>)</span></span> read_buffer:</span> </span>VariableLengthArray</span>(</span>u8</span>),</span></span> write_buffer:</span> </span>VariableLengthArray</span>(</span>u8</span>)</span></span> };</span></span></code></pre> Working with it would be a little easier, because we can just initialize the VLAs at runtime:</p> const</span> conn</span> =</span> Connection{</span></span> .client</span> =</span> input.client,</span></span> .host</span> =</span> .</span>initWithSlice</span>(input.host),</span></span> .read_buffer</span> =</span> .</span>initWithCapacity</span>(input.read_buffer_len),</span></span> .write_buffer</span> =</span> .</span>initWithCapacity</span>(input.write_buffer_len),</span></span> };</span></span></code></pre> The VariableLengthArray type could handle the alignment of our data, and we can just focus on the data itself, accessing the fields directly:</p> std.debug.</span>print</span>(</span>"Host: {s}</span>\n</span>"</span>, .{conn.host});</span></span> const</span> reader</span> =</span> stream.</span>reader</span>(conn.read_buffer);</span></span> const</span> writer</span> =</span> stream.</span>writer</span>(conn.write_buffer);</span></span></code></pre> And yet, all of this data is stored contiguously in memory, without having to allocate each individual field separately!</p> An implementation</a></h2> We can actually achieve something sort of like this with some good ’ole Zig flavored comptime meta programming.</p> We’ll define two structs: a ResizableArray(T)</code>, and a ResizableStruct(Layout)</code> that uses them. The ResizableArray(T)</code> will just be a marker type - such a thing, as far as I know, can’t actually exist in Zig. It’s used by the comptime code in ResizableStruct(Layout)</code> to know which fields have runtime known lengths.</p> The ResizableStruct(Layout)</code> will act as a utility type that makes working with pointers to each field easier. We’d use it like this:</p> const</span> Connection</span> =</span> </span>ResizableStruct</span>(</span>struct</span> {</span></span> client: Client,</span></span> host:</span> </span>ResizableArray</span>(</span>u8</span>)</span></span> read_buffer:</span> </span>ResizableArray</span>(</span>u8</span>),</span></span> write_buffer:</span> </span>ResizableArray</span>(</span>u8</span>)</span></span> });</span></span> </span> const</span> conn</span> = try</span> Connection.</span>init</span>(allocator, .{</span></span> .host</span> =</span> input.host_len,</span></span> .read_buffer</span> =</span> input.read_buffer_len,</span></span> .write_buffer</span> =</span> input.write_buffer_len,</span></span> });</span></span> defer</span> conn.</span>deinit</span>(allocator);</span></span> </span> const</span> client</span> =</span> conn.</span>get</span>(.client);</span></span> client.</span>* =</span> input.client;</span></span> </span> const</span> host</span> =</span> conn.</span>get</span>(.host);</span></span> @memcpy</span>(host, input.host);</span></span> </span> const</span> reader</span> =</span> stream.</span>reader</span>(conn.</span>get</span>(.read_buffer));</span></span> const</span> writer</span> =</span> stream.</span>writer</span>(conn.</span>get</span>(.write_buffer));</span></span> </span> // We can resize the arrays later; this invalidates the above pointers.</span></span> conn.</span>resize</span>(.{</span></span> .host</span> =</span> 123</span>,</span></span> .read_buffer</span> =</span> 456</span>,</span></span> .write_buffer</span> =</span> 789</span>,</span></span> });</span></span></code></pre> The Connection</code> becomes a utility type. It’s kind of like a Slice</code>, or an ArrayList</code>. It can be passed around, stored in arrays, and can be resized at runtime. The only information it needs to store is a pointer to the start of the data, and the lengths of each array. The backing implementation looks like this:</p> const</span> Connection</span> = struct</span> {</span></span> ptr: [</span></span>]</span>u8</span>,</span></span> lens:</span> struct</span> {</span></span> host:</span> usize</span>,</span></span> read_buffer:</span> usize</span>,</span></span> write_buffer:</span> usize</span>,</span></span> }</span></span> }</span></span></code></pre> The only cost is four usize</code>s! This works because we are able to use comptime magic to get the size of each field. Let’s take a look at the current implementation of the get</code> method:</p> pub</span> fn</span> get</span>(self: Self,</span> comptime</span> field:</span> </span>FieldEnum</span>(Layout)) blk: {</span></span> const</span> Field</span> =</span> @FieldType</span>(Layout,</span> @tagName</span>(field));</span></span> break</span> :blk</span> if</span> (</span>isResizableArray</span>(Field)) []Field.Element</span> else </span>Field;</span></span> } {</span></span> const</span> offset</span> =</span> offsetOf</span>(self.lens,</span> @tagName</span>(field));</span></span> const</span> size</span> =</span> sizeOf</span>(self.lens,</span> @tagName</span>(field));</span></span> const</span> bytes</span> =</span> self.ptr[offset..][</span>0</span>..size];</span></span> </span> return</span> @ptrCast</span>(</span>@alignCast</span>(bytes));</span></span> }</span></span></code></pre> Look familiar? This is the same basic pattern used in the example use-case when we broke up the byte array. The comptime magic comes in by examining ResizableArray</code>. First, we can easily check if a field is resizable with a little helper function:</p> pub</span> fn</span> </span>ResizableArray</span>(</span>comptime</span> T:</span> type</span>) </span>type</span> {</span></span> return struct</span> {</span></span> pub const</span> Element</span> =</span> T;</span></span> };</span></span> }</span></span> </span> fn</span> isResizableArray</span>(</span>comptime</span> T:</span> type</span>) </span>bool</span> {</span></span> return</span> @typeInfo</span>(T) </span>==</span> .@"struct"</span> and</span></span> @hasDecl</span>(T,</span> "Element"</span>) </span>and</span></span> T</span> ==</span> </span>ResizableArray</span>(T.Element);</span></span> }</span></span></code></pre> Once we know FieldType</code> is a ResizableArray(T)</code>, we can then safely access FieldType.Element</code>. With the array element types and the self.lens</code> struct, we now have everything we need to calculate the size, offset and alignment of every field, regardless of their positioning in the struct.</p> I have published a minimal implementation of this API as a package on GitHub</a>, and you can use it today. The API docs are on GitHub pages</a> as well, but they can be boiled down to four methods:</p> init</code> to allocate the memory</li> get</code> to get a pointer to a field</li> resize</code> to resize the arrays</li> deinit</code> to free the memory</li> </ul> Request for feedback</a></h2> I think this, or something like it, would be a valuable addition to Zig’s standard library, but it needs scrutiny. If you have a real world use-case for this type, I would love to hear about it. If you can think of enhancements to the API, feel free to open an issue on GitHub.</p> The color doesn't matter 2025-07-13T00:00:00+00:00 In a recent blog post</a>, Loris Cro highlighted the new direction for Zig’s approach to async I/O. Various discussions</a> have</a> since</a> unfolded on whether or not this design really</em> removes function coloring</a> or not.</p> I can see why if you squint at the design in a certain way, you might see red and blue. Personally, I think calling it coloring is a stretch; but I’m not sure the answer to whether it is or isn’t matters. It’s a fun philosophical debate, but it’s missing the point.</p> What matters most in this conversation is the downstream impact these designs have on the language and ecosystem. JavaScript’s breed of function coloring created a sync world, a callback world, and a promise world. Rust’s function colors has created four</a> standard</a> libraries</a> and counting</a>, and still doesn’t seem to have a solution for library authors</a>.</p> The Zig team has made the claim that their design (whether colored or not) has found a way to mitigate the downstream impact on library authors and language users. Doing so has come with some trade-offs, but they claim to have designed for the majority use case. Their claim is:</p> The standard library won’t have to care about colors.</li> Your library won’t have to care about colors.</li> Your application gets to decide what your favorite color is.</li> </ol> If true, and they back this up with code samples in the blog post, it would solve the core problem that function colors often create: ecosystem fragmentation. That you have to pass around, or retrieve, a std.Io</code> interface from somewhere isn’t some kind of limitation – it’s the entire point.</p>

tristanpemble.com - tristanpemble

quiz: a vibecoded QUIC library in Zig

2026-02-09T00:00:00+00:00

I know, I know. I promise I will explain myself, but before I do, I need to set the stage. That said, if that title did not make you spit out your drink, you might want to reflect on that.

Yes, this post was written with my own feeble brain. No, I do not look forward to comments by people who haven’t read it.

On coding agents</a></h2>
I feel like every one of these articles starts with staking some flag in the ground for or against LLM agents, specifically in terms of software development. Usually that comes with some peacock puffing on morals that I don’t find very interesting.
If you must know, I find it all mildly amusing. I enjoy seeing people lose their mind at what they perceive they are now capable of, and the potential of the technology. I equally enjoy other people shouting at those people about actually realized returns, S-curves, hype cycles, and the negative impact the technology will have/is having on society. I think all of these people have a lot of good points.
Consider me an AI nihilist. Equal parts horrified and entertained, but comfortably powerless in steering what seems like an inevitability at this point. Microsoft’s approach to agentic product development disgusts me, so I will choose to stop using GitHub going forward and elect to use Codeberg instead. However, I recognize my complete lack of ability as an individual to change what is happening.
How I use them</a></h2>
Despite my abject horror, I also use the things daily. Often times in ways that I consider perfectly reasonable: summarization, recall, jumping off into concepts I don’t yet know deeply, basic autocomplete, diving into and learning a new codebase. If it has to do with consumption, I have basically no qualms with the tools, and find them quite helpful.
Other times, I use them in ways that I believe are extraordinarily unreasonable.. which I can basically reduce to producing things other people might use or consume that I have not personally vetted. In concrete terms, in the last month and a half, I have “vibecoded” these projects with Claude Code (mostly in Zig, sometimes Rust):

an email client, with..</li>
a mostly working HTML/CSS rendering engine</li>
a UI library</li>
a Signals library</li>
WebAssembly component model tooling for Zig</li>
a whole ass database engine</li>
a tree walking interpreter that successfully evaluates (some of) Zig</li>
a scripting language inspired by that interpreter</li>
a bare metal NixOS HashiCorp cluster with full chain-of-trust signing</li>
a zero allocation HTTP framework</li>
a zero allocation templating library</li>
an old school bulletin board</li>
personal accounting software</li> </ul>
Here’s the thing: if you look at my Codeberg/GitHub, you’re not going to find a single one of these projects. Not one. I am not using any of these projects. They have been deployed nowhere. I would never personally sign up for maintaining any of these codebases. I could never in a million years suggest anyone else ever use these codebases for anything even resembling a production workload. As such, I have not unleashed them into the world, because I believe doing so would be reckless and irresponsible.
So why did I “vibe” them? If I am honest with myself, I think it’s a mixture: two parts joy ride to one part learning experience. I think that in some fucked up way, they have served as a dystopian form of occupational therapy after years and years of pouring myself into other people’s projects professionally. There’s also an element of curious compulsion.
Would I stake my personal security, or my own professional integrity on these projects; let alone take on the liability of an end user’s security? Fuck no.
The library</a></h2>
Reflecting on that thought, I had an idea. What is one of the worst possible projects I could vibecode completely blind with coding agents? Something no one in their right mind should ever use. A library that would curl the toenails of any mildly security conscious programmer in our industry.
There could be worse, but I arrived on a network transport protocol.
Off and on over the last 24 hours, I have used Claude Code to generate a QUIC implementation in the Zig programming language. I have not read a single line of code. As far as I know, it works. I applied my 25 years of experience as a programmer, and my many years as a software architect, lead and manager to herd these agent bastards into writing an implementation that looks like it probably works.
Here’s what I am thinking. Either these LLMs are sufficiently capable that you trust this codebase with the security of all of your network communication.. or they aren’t. I think most of us believe they have not earned such trust.
I would highly encourage you not to use this library in your own software, but you can find the codebase here on Codeberg</a>. The codebase is not really the point, though.
On liability</a></h2>
The thing I really want to discuss, and it’s one of the big reasons I think that LLMs are such a shit show right now in the software industry, is liability.
Please excuse the tired analogy; if I design and sign off on a bridge, and that bridge collapses, killing a bunch of people, I am liable. It doesn’t matter if the blueprints are generated with a large language model or a passel of highly skilled possums with sharpies clenched in their teeth. The design is backed by my personal desire not to lose my reputation, my job, or spend many years in jail. If leadership is pushing me to “ship it”, my personal desire for freedom holds me accountable for neglect. It holds weight.
This, evidently, has not been the case with software. I could have created this library at my day job and had it licensed to any number of organizations. Over the course of a year, your PII might leak due to my complete lack of regard for your personal safety and security. That could lead to the persecution of any number of people (perhaps even their deaths), the loss of ungodly amounts of money, or the leaking of national secrets, who knows!
It’s possible that my employer might be sued. In a just world, the executives might even be held liable. Yet I, the person who wrote the software, would walk freely on to my next contract, taking a six figure salary, telling a machine what product I need to sell to maintain my income.
In our industry’s current framework, there is no personal incentive for me to push back upward against bad leadership (or walk). That creates no incentive for that leadership to stop pushing downward on me to ship the slop. Couple that with an executive level prisoner’s dilemma, and it basically guarantees a top down push spiraling us into insanity.
I don’t know what an answer looks like, but this doesn’t feel right to me. I just hope that we course correct soon.

Functions considered harmful

2025-09-09T00:00:00+00:00

Some readers may disagree with this article due to years of indoctrination by Big O.

In this article, I will rationalize why I choose to write all of my applications in one 50,000-line main()</code> function using strongly worded convictions, contrarian arguments, and loosely constructed hypotheticals.
Our industry has fully embraced using functions as the fundamental primitive to build all software on top of. Whether it’s a library written in a functional style, or an imperative codebase for an application starting with main</code>, every codebase I encounter these days is a function call graph of incalculable complexity.
After 25 years of programming, I have come around to believe that calling and declaring functions is not only an antipattern; it is downright harmful!
Functions are unsafe</a></h2> You see a function named sort</code>. What does it do? Does it allocate? Is it writing to disk? Is it thread safe? Maybe it’s computing hash collisions without your knowledge or consent. Once, in the early years of my career, I called a function named processPayroll</code>. To this day I believe that in the time between call and return it began a sentient uprising of starving workers inside my CPU. Unfortunately, I was forced to interrupt it. A seemingly innocuous function call might delete your entire hard drive. It could SWAT your stepfather. Hell, it might even kill your entire family. It is truly a mystery what happens behind any given function call in any given codebase, and most codebases have thousands (millions!) of them. I prefer the safety of my 50,000 line main()</code> function. Functions create maintenance headaches</a></h2> This one is for management. Due to the indirection that function calls inherently create, maintaining code written with functions is extremely difficult (dare I say, impossible). Your developers might be reading code to initialize a database connection, and suddenly they are redirected to a file in another codebase entirely(!). Code changed here could break code over there. You are spending precious money, on precious man hours, for your developers to look at code they didn’t even write. With a 50,000 line main()</code> function, none of this is an issue. As a manager, your job is to reduce context switching for your team. I strongly encourage you to reorient your team toward building the functionless architecture of your company’s future. Functions decrease performance</a></h2> You may not know this, but functions come with a performance cost. Program counters need to be incremented and decremented. Arguments must be pushed to the stack. Stack frames must be allocated and deallocated. I assume all of this takes time. I haven’t measured it, but my 50,000 line main()</code> function with zero tests probably has much more predictible performance. Don’t even get me started on closures. Proposal</a></h2> Instead of using functions, keep it simple – neatly contain all of your logic within one file, in a single, clean 50,000 line main()</code> function. You will soon find that any time you need to understand what your code is doing, it is right in front of you. If it calls the cops on your neighbors, that’s on you. Your mind will be freed from the constant hell of function drilldown.
Depth=2 2025-08-04T00:00:00+00:00 A common observation of language ecosystems that reach a certain amount of critical mass in adoption is that they start to have an explosion in the depth of dependency trees when building applications. The more I think about the problem, the more it resembles evolutionary biology. In natural ecosystems, resources are limited. This creates a selective pressure that regulates the growth of organisms. Developer ecosystems lack a naturally regulating force. Imagine a language that imposed a restriction on packages such that: There are three kinds of packages: library, framework, application</li> A library can only depend on the standard library (depth=0</code>)</li> A framework can only depend on the standard library, or user libraries (depth=1</code>)</li> An application can depend on frameworks, user libraries, and the standard library (depth=2</code>)</li> </ol> The package ecosystem gets completely flattened to a maximum tree depth of 2. Such a constraint, imposed on the entire ecosystem, might change the way it organizes. Serious consideration would be put into pulling in a package: congrats, you’re now a framework, the reusability of your code has reduced logarithmically. I can imagine relaxing the restriction on libraries, or perhaps an additional type of package called an interface. Interfaces would be able to depend on each other, but they can only contain interface definitions – no implementations. You can imagine such an HTTP</code> interface package that exports Request</code> and Response</code>. It would then be easy for a language maintainer to identify which of these interfaces are candidates for promotion into the standard library. Inevitably, someone would try to circumvent the limitation. If I were the language maintainer, I would probably attempt to blacklist the tool in my implementation. But I am not a language maintainer, and I’m certain that would result in a beautiful scandal – complete with angry people who do not, and will never, use the language trying to influence its direction. My first Zig Day 2025-08-03T00:00:00+00:00 I just got back from my first “Zig Day</a>”, which happened to also be Portland’s inaugural</a>. We started the day with a quick mingle. We then briefly formed a circle to introduce ourselves and say what project we had brought with us, or what we were hoping to learn. We then broke out organically into groups, coded all day, went out to lunch, came back, coded some more, and finally, shared what we had done all day. While there, I met a student from DigiPen who drove down from Seattle to visit their buddy in Portland. They were both excited to learn about the event, and that it coincided with the trip. We worked through bindings for CLAP</a>, an open protocol for building audio plugins for Digital Audio Workstations. This is something I’ve always wanted to get into, and for whatever reason, just never did. Thanks to them, I have a new hobby. I talked to someone who was working on their command line Markdown parser and renderer. It was their first Zig project, coming from a tenured career using C++. We were both excited to talk about what Zig did differently that inspired us. They demoed their project to me, and it was my first time seeing Kitty’s terminal graphics protocol</a> in action. Thanks to them, I felt like I took a step toward the future. While they got help from someone to debug an edge case, I spoke with a hardware engineer who had come to work on their serialization code for some kind of compression tool they had been developing. They had expressed an interest in flexible array members in Zig, a concept I have recently become quite familiar with</a>. Thanks to them, I was able to work through a real world use-case for software I had written with someone who I respect. The day was simple. There were no sponsors, and there were no recruiters. We were not expected to consume, and we were not expected to produce. The only expectation of any one of us was to connect with each other. We were people gathering in our community library to share this thing we love. </div> This low key, palpably genuine vibe did not happen by accident. The format of the event, outlined by Loris Cro last year in a blog post</a>, follows the format of a meetup that he had attended called “Open Source Saturday”. As the VP of Community at the Zig Software Foundation, Loris proposed that members of the Zig community start a regular “Zig Day” in their own cities following a similar format. Andrew Kelley, president of ZSF and the original creator of the language, put this particular instance of the event together in his hometown of Portland – not just to lead by example – but also, because it’s exactly the kind of thing that he wants to attend. This is the thing about Zig, and the community that is building around it, that has had the most lasting impact on me. There’s a genuine belief in a better way to do things. There’s a deep rooted curiosity. There’s a respect for the humanity involved in software development. And, most importantly, there’s follow-through. Today, in my eyes, was the physical manifestation of all of these things. These are not technical merits. They will not appear on benchmarks or feature lists. They are not quantifiable in any way, whatsoever. They are subtle, but I find them pervasive. Something about this community surrounding this particular language brings me back the joy I felt when I first began my path on this career. </div> I have been asked to take over organizing future Zig Day events in Portland. The cadence in which we will hold them has not yet been determined. Given the commitment involved – a full Saturday – we think every other month might be suitable. If you attended today, I would love to hear your feedback</a>. If you live nearby but were unable to attend, we look forward to seeing you at the next one. Subscribe on zig.day</a> to be notified of future events. If you do not live near us and would like to attend a Zig Day in your city, you can check if there is one being organized</a>. If there is not, it is quite manageable to organize your own</a>. You’ll be glad you did. Promise. Resizable structs in Zig 2025-07-26T00:00:00+00:00 In this post I will make the case for the concept of a “runtime resizable struct” in Zig. I will then design an API by exploiting Zig’s powerful comptime functionality. If you want to skip straight to the implementation, a minimal proof of concept is available as a package on GitHub</a>. Arrays and many-item pointers</a></h2> Zig has support for many kinds of collection types in its standard library. All of them can broadly be broken down to two primitive backing types for contiguous data storage: [N]T</code> – arrays</a>, when you always know the length at compile time.</li> [*]T</code> – many-item pointers</a>, when you may not know the length at compile time.</li> </ul> You may be wondering about slices. Slices</a> can be thought of as syntax sugar around a many-item pointer and a length: // A desugared slice type const PersonSlice = struct { ptr: [*]Person, len: usize, };</code></pre> Once you allocate the slice, you can’t grow or shrink its memory without reallocating. That’s why we have std.ArrayList</code></a>, which is just a wrapper around a slice (itself sugar for many-item pointers) that provides helpers to manage reallocating that slice: // A naive ArrayList implementation const PersonList = struct { items: []Person, pub fn append(self: PersonArrayList, allocator: Allocator, person: Person) !void { self.items = try allocator.realloc(self.items, self.items.len + 1); self.items[self.items.len] = person; } };</code></pre> We can build up lots of interesting collection types with these primitives, but at the end of the day, we have arrays, many-item pointers, and slices (which are just many-item pointers!). If the size is fixed at compile time, you’ll probably be working with arrays. If the size may be influenced by runtime values, you’ll probably be working with many-item pointers. Structs</a></h2> Arrays/pointers work well for contiguous storage of the same type, but a struct</a> can be thought of as contiguous collection of different types: const City = struct { name: []const u8, population: u32, area: f32, };</code></pre> It has a compile time known number of values, they have a compile time known size, and as a result, the size of the struct is known at compile time. The problem</a></h2> Let’s break down the three tools I outlined above for contiguous storage: Tool</th> Elements</th> Size</th></tr></thead> Arrays</td> Same</td> Comptime</td></tr> Many-item pointers</td> Same</td> Runtime</td></tr> Structs</td> Different</td> Comptime</td></tr> ???</td> Different</td> Runtime</td></tr> </tbody></table> At this point, you’ll notice a missing piece – what if we want to access contiguously stored data, with differing types, but the size/length of that data is only known at runtime? A use-case</a></h2> It’s fun to design tools for imaginary problems, but before we continue, is this really something that people need? I believe that it is. Here is a snippet of code</a> in Zig’s standard library where such a thing might be useful. The status quo</a></h2> To do this today, you essentially have to take the following steps: Calculate the size of the data you need to store</li> Allocate a []u8</code> to store it in</li> Break up that byte slice into pieces for each field using a lot of @ptrCast</code>/@alignCast</code></li> Initialize the data in each field, making sure to keep track of all runtime lengths</li> </ol> Here I have done so using a simplified version of the use-case from the standard library: // A known-size data structure const Connection = struct { client: Client, host_len: usize, read_buffer_len: usize, write_buffer_len: usize, }; // First, calculate the size of, and then allocate, a byte slice for the data const length = calculateSizeAtRuntime(input); const bytes = try gpa.alignedAlloc(u8, @alignOf(Connection), length); // Then break up that byte slice into its components const conn: *Connection = @ptrCast(bytes); const host_offset = @sizeOf(Connection); const host = bytes[host_offset..][0..input.host_len]; const read_buffer_offset = host_offset + input.host_len; const read_buffer = bytes[read_buffer_offset..][0..input.read_buffer_len]; const write_buffer_offset = read_buffer_offset + input.read_buffer_len; const write_buffer = bytes[write_buffer_offset..][0..input.write_buffer_len]; // Initialize the known-size data, storing runtime sizes conn.* = .{ .client = input.client, .host_len = input.host_len, .read_buffer_len = input.read_buffer_len, .write_buffer_len = input.write_buffer_len, }; // Initialize the runtime sized data @memcpy(host, input.host);</code></pre> Doing all of this correctly can be tricky. Even just the first step is more complex than you might think. In our example, the host and buffer fields are both arrays of u8</code>s, but what if the elements have an alignment requirement? If your fields are not ordered correctly, subsequent fields may become unaligned if you don’t pad correctly. If you don’t track all of the lengths, you can accidentally introduce undefined behavior, and as a result, possible security vulnerabilities. Let alone resizing the thing if the lengths change later! We can do better! Variable Length Arrays</a></h2> As an aside, some programming languages have a concept of variable length arrays (VLA). The idea is to have an array (stack allocated contiguous data) with a length that is known at runtime (it is variable). Zig does not, and will not</a>, have VLAs in the language spec. Instead, you can allocate a slice on the heap. If you want to have the data on the stack, use an array as a bounded backing store, and work with a slice into it: // We have an upper limit of 32 values const my_buffer: [32]u64 = undefined; const my_vla: []u64 = my_buffer[0..runtime_length];</code></pre>Dreaming up an API</a></h2> Variable length arrays don’t, and won’t, exist in Zig, but what if they did? We might have defined our Connection</code> type something like this: const Connection = struct { client: Client, host: VariableLengthArray(u8) read_buffer: VariableLengthArray(u8), write_buffer: VariableLengthArray(u8) };</code></pre> Working with it would be a little easier, because we can just initialize the VLAs at runtime: const conn = Connection{ .client = input.client, .host = .initWithSlice(input.host), .read_buffer = .initWithCapacity(input.read_buffer_len), .write_buffer = .initWithCapacity(input.write_buffer_len), };</code></pre> The VariableLengthArray type could handle the alignment of our data, and we can just focus on the data itself, accessing the fields directly: std.debug.print("Host: {s}\n", .{conn.host}); const reader = stream.reader(conn.read_buffer); const writer = stream.writer(conn.write_buffer);</code></pre> And yet, all of this data is stored contiguously in memory, without having to allocate each individual field separately! An implementation</a></h2> We can actually achieve something sort of like this with some good ’ole Zig flavored comptime meta programming. We’ll define two structs: a ResizableArray(T)</code>, and a ResizableStruct(Layout)</code> that uses them. The ResizableArray(T)</code> will just be a marker type - such a thing, as far as I know, can’t actually exist in Zig. It’s used by the comptime code in ResizableStruct(Layout)</code> to know which fields have runtime known lengths. The ResizableStruct(Layout)</code> will act as a utility type that makes working with pointers to each field easier. We’d use it like this: const Connection = ResizableStruct(struct { client: Client, host: ResizableArray(u8) read_buffer: ResizableArray(u8), write_buffer: ResizableArray(u8) }); const conn = try Connection.init(allocator, .{ .host = input.host_len, .read_buffer = input.read_buffer_len, .write_buffer = input.write_buffer_len, }); defer conn.deinit(allocator); const client = conn.get(.client); client.* = input.client; const host = conn.get(.host); @memcpy(host, input.host); const reader = stream.reader(conn.get(.read_buffer)); const writer = stream.writer(conn.get(.write_buffer)); // We can resize the arrays later; this invalidates the above pointers. conn.resize(.{ .host = 123, .read_buffer = 456, .write_buffer = 789, });</code></pre> The Connection</code> becomes a utility type. It’s kind of like a Slice</code>, or an ArrayList</code>. It can be passed around, stored in arrays, and can be resized at runtime. The only information it needs to store is a pointer to the start of the data, and the lengths of each array. The backing implementation looks like this: const Connection = struct { ptr: [*]u8, lens: struct { host: usize, read_buffer: usize, write_buffer: usize, } }</code></pre> The only cost is four usize</code>s! This works because we are able to use comptime magic to get the size of each field. Let’s take a look at the current implementation of the get</code> method: pub fn get(self: Self, comptime field: FieldEnum(Layout)) blk: { const Field = @FieldType(Layout, @tagName(field)); break :blk if (isResizableArray(Field)) []Field.Element else *Field; } { const offset = offsetOf(self.lens, @tagName(field)); const size = sizeOf(self.lens, @tagName(field)); const bytes = self.ptr[offset..][0..size]; return @ptrCast(@alignCast(bytes)); }</code></pre> Look familiar? This is the same basic pattern used in the example use-case when we broke up the byte array. The comptime magic comes in by examining ResizableArray</code>. First, we can easily check if a field is resizable with a little helper function: pub fn ResizableArray(comptime T: type) type { return struct { pub const Element = T; }; } fn isResizableArray(comptime T: type) bool { return @typeInfo(T) == .@"struct" and @hasDecl(T, "Element") and T == ResizableArray(T.Element); }</code></pre> Once we know FieldType</code> is a ResizableArray(T)</code>, we can then safely access FieldType.Element</code>. With the array element types and the self.lens</code> struct, we now have everything we need to calculate the size, offset and alignment of every field, regardless of their positioning in the struct. I have published a minimal implementation of this API as a package on GitHub</a>, and you can use it today. The API docs are on GitHub pages</a> as well, but they can be boiled down to four methods: init</code> to allocate the memory</li> get</code> to get a pointer to a field</li> resize</code> to resize the arrays</li> deinit</code> to free the memory</li> </ul> Request for feedback</a></h2> I think this, or something like it, would be a valuable addition to Zig’s standard library, but it needs scrutiny. If you have a real world use-case for this type, I would love to hear about it. If you can think of enhancements to the API, feel free to open an issue on GitHub. The color doesn't matter 2025-07-13T00:00:00+00:00 In a recent blog post</a>, Loris Cro highlighted the new direction for Zig’s approach to async I/O. Various discussions</a> have</a> since</a> unfolded on whether or not this design really removes function coloring</a> or not. I can see why if you squint at the design in a certain way, you might see red and blue. Personally, I think calling it coloring is a stretch; but I’m not sure the answer to whether it is or isn’t matters. It’s a fun philosophical debate, but it’s missing the point. What matters most in this conversation is the downstream impact these designs have on the language and ecosystem. JavaScript’s breed of function coloring created a sync world, a callback world, and a promise world. Rust’s function colors has created four</a> standard</a> libraries</a> and counting</a>, and still doesn’t seem to have a solution for library authors</a>. The Zig team has made the claim that their design (whether colored or not) has found a way to mitigate the downstream impact on library authors and language users. Doing so has come with some trade-offs, but they claim to have designed for the majority use case. Their claim is: The standard library won’t have to care about colors.</li> Your library won’t have to care about colors.</li> Your application gets to decide what your favorite color is.</li> </ol> If true, and they back this up with code samples in the blog post, it would solve the core problem that function colors often create: ecosystem fragmentation. That you have to pass around, or retrieve, a std.Io</code> interface from somewhere isn’t some kind of limitation – it’s the entire point.