https://news.ycombinator.com/Links for the intellectually curious, ranked by readers.https://openrouter.ai/announcements/series-bSat, 30 May 2026 17:27:28 +0000https://news.ycombinator.com/item?id=48338660<a href="https://news.ycombinator.com/item?id=48338660">Comments</a><article class="flex flex-col gap-6 px-8" morss_own_score="4.423312883435583" morss_score="12.985812883435582"><h1>OpenRouter Raises $113M Series B</h1><p>OpenRouter · <time>5/28/2026</time></p><img src="https://openrouter.ai/_next/image?url=%2Fimages%2Fblog%2Fseries-b.png&amp;w=3840&amp;q=75&amp;dpl=dpl_759dHfa9M2hqRqohcC736WRwsxLz"><div class="prose-slate prose-hr:border-current prose-table:min-w-full prose-table:overflow-hidden prose-table:rounded-lg prose-table:border prose-table:border-current prose-ol:list-decimal prose-ol:pl-8 prose-ul:list-disc prose-ul:pl-8 prose-ol:pb-4 prose-ul:pb-4 prose-li:whitespace-normal prose-th:border prose-th:border-current prose-th:px-4 prose-th:py-2 prose-td:border prose-td:border-current prose-td:px-4 prose-td:py-2 prose-h3:font-medium prose-h3:text-current prose-p:break-words prose-p:leading-6 prose-p:whitespace-pre-wrap prose-blockquote:border-l-2 prose-blockquote:pl-4 prose-blockquote:italic prose-blockquote:border-slate-10 prose-blockquote:text-slate-11 prose-img:max-w-full prose-img:h-auto prose-img:rounded-lg prose-img:shadow-sm prose-img:my-4 prose-img:mx-auto prose-img:block tracking-tight flex flex-col gap-6" morss_own_score="3.125" morss_score="27.625"><p>Today we're announcing our $113M Series B, led by <a href="https://capitalg.com/">CapitalG<span>(opens in new tab)</span></a> (Alphabet's independent growth fund), with participation from <a href="https://www.nvidia.com/en-us/about-nvidia/nventures/">NVentures<span>(opens in new tab)</span></a> (NVIDIA's venture capital arm), <a href="https://www.servicenow.com/">ServiceNow<span>(opens in new tab)</span></a> Ventures, <a href="https://www.mongodb.com/">MongoDB<span>(opens in new tab)</span></a> Ventures, <a href="https://www.snowflake.com/">Snowflake<span>(opens in new tab)</span></a> Ventures, <a href="https://www.databricks.com/">Databricks<span>(opens in new tab)</span></a> Ventures, <a href="https://amppublic.com/">AMP PBC<span>(opens in new tab)</span></a>, and <a href="https://pacecapital.com/">Pace Capital<span>(opens in new tab)</span></a>, alongside our existing investors <a href="https://a16z.com/">Andreessen Horowitz<span>(opens in new tab)</span></a> and <a href="https://menlovc.com/">Menlo Ventures<span>(opens in new tab)</span></a>.</p> <h2>Where we are</h2> <p>Over the last six months, weekly volume on OpenRouter has grown from 5 trillion to 25 trillion tokens. We are on pace to process over a quadrillion tokens this year and serve 8M+ developers building across 400+ models. AI is rapidly shifting from experimentation into critical production apps and agents, and that transition requires infrastructure that works reliably at scale, across providers, across modalities, and across use cases. This growth reflects the simple fact that developers love building on OpenRouter.</p> <h2>Why this round matters</h2> <p>The composition of this investor group is deliberate. CapitalG, NVentures, ServiceNow Ventures, MongoDB Ventures, Snowflake Ventures, and Databricks Ventures are more than financial backers; they are the infrastructure and platform companies that enterprises already depend on. Their participation reflects a shared view: as organizations move from single-model pilots to multi-model production systems, they need a routing and gateway layer purpose-built for that complexity.</p> <p>OpenRouter is that layer. We sit between agents and model providers, handling the routing, reliability, cost optimization, and compliance that production AI demands. The breadth of strategic investors in this round signals that the market has converged on this as a critical piece of the stack.</p> <h2>What we've been building</h2> <p>The past year has been focused on expanding what OpenRouter can do for production workloads:</p> <ul> <li><strong>Multimodal inference</strong>: Beyond text, OpenRouter now supports <a href="https://openrouter.ai/models?output_modalities=image">image<span>(opens in new tab)</span></a>, <a href="https://openrouter.ai/models?output_modalities=audio">audio<span>(opens in new tab)</span></a>, <a href="https://openrouter.ai/models?output_modalities=speech">speech<span>(opens in new tab)</span></a>, <a href="https://openrouter.ai/models?output_modalities=transcription">transcription<span>(opens in new tab)</span></a>, <a href="https://openrouter.ai/models?output_modalities=embedding">embedding<span>(opens in new tab)</span></a>, and <a href="https://openrouter.ai/models?output_modalities=video">video<span>(opens in new tab)</span></a> models.</li> <li><strong>Enterprise controls</strong>: <a href="https://openrouter.ai/docs/guides/features/workspaces">Workspaces<span>(opens in new tab)</span></a>, spend management, <a href="https://openrouter.ai/docs/guides/features/guardrails">guardrails<span>(opens in new tab)</span></a>, and <a href="https://openrouter.ai/docs/guides/privacy/zero-data-retention">zero-data-retention<span>(opens in new tab)</span></a> policies for organizations deploying AI at scale.</li> <li><strong>Intelligent routing</strong>: Provider-level failover, cost and latency optimization, and quality-aware routing that goes beyond simple load balancing.</li> </ul> <h2>What's next</h2> <p>We'll use this funding to continue scaling our infrastructure, deepen enterprise capabilities, and continue to invest in intelligent routing; teams need help finding the right model and provider for every request. We're grateful to our customers, partners, investors, and the developer community building with us as we continue scaling the infrastructure layer for the multi-model AI era.</p></div></article>https://ziglang.org/devlog/2026/#2026-05-30Sat, 30 May 2026 17:29:22 +0000https://news.ycombinator.com/item?id=48338673<a href="https://news.ycombinator.com/item?id=48338673">Comments</a><div class="changelist" morss_own_score="2.7610037841067516" morss_score="13.777189001744025"> <div id="2026-05-30" morss_own_score="2.8641509433962264" morss_score="36.713757745248806"> <span>May 30, 2026</span> <h1><a href="https://ziglang.org/devlog/2026/#2026-05-30">ELF Linker Improvements </a></h1> <p>Author: Matthew Lugg</p><p>I’ve spent the past few weeks working on our new ELF linker which debuted in Zig 0.16.0. At the time of the 0.16.0 release, this linker implementation was in its fairly early stages, and only really supported linking Zig-only code without any external libraries (even libc)—hence why it was (and still is) disabled by default (it can be enabled with <code>-fnew-linker</code>). However, quite a lot of progress has been made since that initial release!</p><p>Here’s a nice milestone—as of <a href="https://codeberg.org/ziglang/zig/pulls/35533">my latest PR</a>, the new ELF linker is capable of building the self-hosted Zig compiler with LLVM and LLD libraries enabled, a task which requires quite a few features under the hood.</p><pre><code>[<span>mlugg</span><span>@nebula</span> <span>master]</span><span>$</span> <span># Build the Zig compiler using the new linker:</span> <span>[mlugg@nebula</span> <span>master]</span><span>$</span> <span>zig</span> <span>build</span> <span>-Dno-lib</span> <span>-Dnew-linker</span> <span>-Denable-llvm</span> <span>[mlugg@nebula</span> <span>master]</span><span>$</span> <span># Use that compiler to build something with LLVM and LLD:</span> <span>[mlugg@nebula</span> <span>master]</span><span>$</span> <span>./zig-out/bin/zig</span> <span>build-exe</span> <span>~/hello.zig</span> <span>-fllvm</span> <span>-flld</span> <span>[mlugg@nebula</span> <span>master]</span><span>$</span> <span>./hello</span> <span>Hello,</span> <span>World!</span> <span>[mlugg@nebula</span> <span>master]</span><span>$</span> </code></pre> <p>Of course, an ELF linker isn’t necessarily the most exciting thing in the world, which is why the headline feature of this new linker is its support for fast incremental compilation. After the recent enhancements, it is now possible (on x86_64 Linux) to perform incremental rebuilds while linking external libraries, C sources, etc—without any additional performance overhead! Here’s a clip of me trying it out on <a href="https://github.com/andrewrk/tetris">Andrew’s Tetris clone</a>:</p><p><figure><figcaption>A few silly changes to Andrew’s Tetris clone being built in around 30ms each.</figcaption></figure></p><p>Oh, and fast incremental rebuilds also work nicely on the Zig compiler itself:</p><pre><code>[mlugg@nebula master]$ zig build -Dno-lib -Denable-llvm -fincremental --watch Build Summary: 4/4 steps succeeded install success └─ install zig success └─ compile exe zig Debug native success 36s Build Summary: 4/4 steps succeeded install success └─ install zig success └─ compile exe zig Debug native success 244ms Build Summary: 4/4 steps succeeded install success └─ install zig success └─ compile exe zig Debug native success 228ms Build Summary: 4/4 steps succeeded install success └─ install zig success └─ compile exe zig Debug native success 288ms Build Summary: 4/4 steps succeeded install success └─ install zig success └─ compile exe zig Debug native success 283ms </code></pre><p>The biggest missing feature of this linker implementation right now is that it still does not yet support generating DWARF debug information for Zig code—that’s definitely my next priority. But even without that support, it’s amazing just how useful instant rebuilds can be, for example in any situation where you’re doing a lot of print debugging.</p><p>If you’re using the master branch of Zig and you’re on x86_64 Linux, consider trying out incremental compilation with the new ELF linker if it previously wasn’t working with your project! I expect many codebases to already work great with it, unlocking the ability to rebuild your project in milliseconds. Of course, if you come across any bugs, please do <a href="https://codeberg.org/ziglang/zig/issues">open an issue</a>.</p><p>And if you’re currently sticking to tagged releases of Zig, don’t worry—as Andrew mentioned in his last devlog, Zig 0.17.0 is just around the corner, so it won’t be long before you can try this too!</p> </div> <div id="2026-05-26" morss_own_score="2.8980392156862744" morss_score="50.398039215686275"> <span>May 26, 2026</span> <h1><a href="https://ziglang.org/devlog/2026/#2026-05-26">Build System Reworked </a></h1> <p>Author: Andrew Kelley</p><p>Big branch just landed: <a href="https://codeberg.org/ziglang/zig/pulls/35428">separate the maker process from the configurer process</a></p><p>This devlog entry is essentially a preview of the upcoming release notes, but serves as an advanced notice to those who want to help test out the new features and provide feedback that will guide the Zig project moving forward.</p><p>Before, <code>build.zig</code> files plus the build system implementation were all compiled into one bloated process, in Debug mode. After <code>build.zig</code> logic finished constructing a build graph in memory, the “build runner” code executed it.</p><p>Now, <code>build.zig</code> files are compiled into a small process (the “configurer”) in debug mode. After this logic finishes constructing a build graph in memory, it is serialized to a binary configuration file. The parent <code>zig build</code> process is aware of this file and caches it for next time. While waiting for all that, it asynchronously compiles the build graph execution process (the “maker”) in release mode. Once the configuration file is available and the maker process is finished compiling, the maker process is executed, passing it the configuration file. The maker process only needs to be compiled once per <code>zig version</code> thanks to the global cache. The maker process then executes the build graph, which is contained within the serialized configuration file.</p><p>The primary motivation of this change was to make <code>zig build</code> faster, in three ways:</p><ol><li><p>Only the user’s <code>build.zig</code> logic will be compiled with each change, rather than the entire build system along with it. This is starting to become more valuable now that we have introduced <code>--watch</code>, <code>--fuzz</code> and <code>--webui</code>. The build system can grow more features without making <code>zig build</code> take longer.</p></li><li><p>Now the build system can skip rerunning the <code>build.zig</code> logic entirely when it knows nothing will change, for example if you add <code>-freference-trace</code> to your <code>zig build</code> command line, it now avoids re-running your <code>build.zig</code> logic redundantly, using the same configuration as last time.</p></li><li><p>Now the process that actually executes the build graph is compiled with optimizations enabled.</p></li></ol><p>To demonstrate points 2 and 3, here is the difference between running <code>zig build --help</code> before and after:</p><pre><code>Benchmark 1 (34 runs): master/zig build -h measurement mean ± σ min … max outliers delta wall_time 150ms ± 5.52ms 145ms … 165ms 4 (12%) 0% peak_rss 84.8MB ± 275KB 84.2MB … 85.1MB 0 ( 0%) 0% cpu_cycles 593M ± 4.01M 588M … 608M 2 ( 6%) 0% instructions 995M ± 52.5K 995M … 995M 0 ( 0%) 0% cache_references 25.8M ± 165K 25.4M … 26.1M 0 ( 0%) 0% cache_misses 651K ± 20.1K 619K … 697K 0 ( 0%) 0% branch_misses 918K ± 7.44K 906K … 935K 0 ( 0%) 0% Benchmark 2 (348 runs): branch/zig build -h measurement mean ± σ min … max outliers delta wall_time 14.3ms ± 744us 13.2ms … 23.3ms 8 ( 2%) ⚡- 90.4% ± 0.4% peak_rss 78.5MB ± 562KB 77.1MB … 81.4MB 7 ( 2%) ⚡- 7.4% ± 0.2% cpu_cycles 24.1M ± 821K 22.8M … 27.1M 3 ( 1%) ⚡- 95.9% ± 0.1% instructions 43.7M ± 23.8K 43.7M … 43.8M 56 (16%) ⚡- 95.6% ± 0.0% cache_references 1.46M ± 14.6K 1.40M … 1.50M 19 ( 5%) ⚡- 94.3% ± 0.1% cache_misses 142K ± 4.87K 127K … 157K 2 ( 1%) ⚡- 78.1% ± 0.4% branch_misses 126K ± 1.37K 120K … 129K 12 ( 3%) ⚡- 86.3% ± 0.1% </code></pre><p>It’s dramatic because before, <code>build.zig</code> logic was being executed with each <code>zig build</code> command, but now, the build system uses the cached, serialized configuration instead.</p><p>Aside from performance, I expect third-party tooling such as ZLS to benefit from consuming the serialized configuration file rather than maintaining a fork of the build runner.</p><p>This changeset heavily reworks the internal mechanism of the zig build system, however, it is mostly non-breaking from an API perspective, with the exceptions noted in the PR linked above.</p><p>For most people I’m guessing this is the main breaking change they’ll hit:</p><pre><code><span>if</span> <span>(</span><span>b</span><span>.</span><span>args</span><span>)</span> <span>|</span><span>args</span><span>|</span> <span>{</span> <span>run_cmd</span><span>.</span><span>addArgs</span><span>(</span><span>args</span><span>)</span><span>;</span> <span>}</span> </code></pre> <p>⬇️</p><pre><code><span>run_cmd</span><span>.</span><span>addPassthruArgs</span><span>(</span><span>)</span><span>;</span> </code></pre> <p>This removes a capability from build scripts since they can no longer observe those arguments. In exchange, it means that when changing those arguments, build scripts no longer must be rebuilt from source.</p><p>If you’re someone who wants to influence the direction of Zig, this is a good time to upgrade your projects to the development version and try out these changes. We’ll be releasing 0.17.0 within a couple weeks from now. However, if you don’t have time, and you find out that 0.17.0 broke your build, don’t worry, there will be plenty of opportunity to get fixes in for the 0.17.1 tag as well.</p> </div> <div id="2026-04-08" morss_own_score="2.804560260586319" morss_score="23.345543867143697"> <span>April 08, 2026</span> <h1><a href="https://ziglang.org/devlog/2026/#2026-04-08">Incremental compilation with LLVM </a></h1> <p>Author: Matthew Lugg</p><p>I’ve been spending a bit of time working on personal projects after merging my <a href="https://ziglang.org/devlog/2026/#2026-03-10">type resolution changes</a> last month, but I did find the time recently to make some improvements to the LLVM codegen backend. This involved a few different enhancements with various goals, but one nice user-facing change was that I managed to get incremental compilation working with the LLVM backend.</p><p morss_own_score="7.0" morss_score="11.0">Sadly this can’t do anything to speed up the dreaded LLVM Emit Object: that time is entirely down to LLVM. However, what incremental compilation <em>does</em> help with is minimizing the time spent in the actual Zig compiler code, which means that if your code has compile errors (so “LLVM Emit Object” will be skipped), you’ll usually get those errors very quickly. (Of course, it does still give you a <em>slight</em> speed-up in successful builds too.)</p><p>This support is available in master branch builds right now, and will be in the 0.16.0 release (which we’ll be tagging very soon).</p><p>For anyone who still hasn’t tried it, especially if you’re using Zig’s master branch, please do try out incremental compilation by passing <code>-fincremental --watch</code> to <code>zig build</code>! The Zig core team have benefited from incremental compilation in our workflows for a good year now, and we’re also hearing good things from users. The feature is relatively stable at this point, and people are often surprised how much time they can save just by getting up-to-date compile errors in milliseconds rather than seconds.</p><p>I haven’t really personally used incremental compilation with the LLVM backend, but all of the incremental test coverage in CI is now enabled for the LLVM backend, and I’ve had positive feedback from users, so it’s definitely worth giving a shot. As always, if you encounter bugs in incremental compilation, please report them if you can!</p><p>Thank you, and I hope you find this useful :)</p> </div> <div id="2026-03-10" morss_own_score="2.7709090909090905" morss_score="36.71578088578089"> <span>March 10, 2026</span> <h1><a href="https://ziglang.org/devlog/2026/#2026-03-10">Type resolution redesign, with language changes to taste </a></h1> <p>Author: Matthew Lugg</p><p>Today, <a href="https://codeberg.org/ziglang/zig/pulls/31403">I merged a 30,000 line PR</a> after two (arguably three) months of work. The goal of this branch was to rework the Zig compiler’s internal type resolution logic to a more logical and straightforward design. It’s a quite exciting change for me personally, because it allowed me to clean up a bunch of the compiler guts, but it also has some nice user-facing changes which you might be interested in!</p><p>For one thing, the Zig compiler is now lazier about analyzing the fields of types: if the type is never initialized, then there’s no need for Zig to care what that type “looks like”. This is important when you have a type which doubles as a namespace, a common pattern in modern Zig. For instance, when using <code>std.Io.Writer</code>, you don’t want the compiler to also pull in a bunch of code in <code>std.Io</code>! Here’s a straightforward example:</p><pre><code><span>const</span> <span>Foo</span> <span>=</span> <span>struct</span> <span>{</span> <span>bad_field</span><span>:</span> <span>@compileError</span><span>(</span><span>"i am an evil field, muahaha"</span><span>)</span><span>,</span> <span>const</span> <span>something</span> <span>=</span> <span>123</span><span>;</span> <span>}</span><span>;</span> <span>comptime</span> <span>{</span> <span>_</span> <span>=</span> <span>Foo</span><span>.</span><span>something</span><span>;</span> <span>}</span> </code></pre> <p>Previously, this code emitted a compile error. Now, it compiles just fine, because Zig never actually looks at the <code>@compileError</code> call.</p><p>Another improvement we’ve made is in the “dependency loop” experience. Anyone who has encountered a dependency loop compile error in Zig before knows that the error messages for them are entirely unhelpful—but that’s now changed! If you encounter one (which is also a bit less likely now than it used to be), you’ll get a detailed error message telling you exactly where the dependency loop comes from. Check it out:</p><pre><code><span>const</span> <span>Foo</span> <span>=</span> <span>struct</span> <span>{</span> <span>inner</span><span>:</span> <span>Bar</span> <span>}</span><span>;</span> <span>const</span> <span>Bar</span> <span>=</span> <span>struct</span> <span>{</span> <span>x</span><span>:</span> <span>u32</span> <span>align</span><span>(</span><span>@alignOf</span><span>(</span><span>Foo</span><span>)</span><span>)</span> <span>}</span><span>;</span> <span>comptime</span> <span>{</span> <span>_</span> <span>=</span> <span>@as</span><span>(</span><span>Foo</span><span>,</span> <span>undefined</span><span>)</span><span>;</span> <span>}</span> </code></pre> <pre><code>$ zig build-obj repro.zig error: dependency loop with length 2 repro.zig:1:29: note: type 'repro.Foo' depends on type 'repro.Bar' for field declared here const Foo = struct { inner: Bar }; ^~~ repro.zig:2:44: note: type 'repro.Bar' depends on type 'repro.Foo' for alignment query here const Bar = struct { x: u32 align(@alignOf(Foo)) }; ^~~ note: eliminate any one of these dependencies to break the loop </code></pre><p>Of course, dependency loops can get much more complicated than this, but in every case I’ve tested, the error message has had enough information to easily see what’s going on.</p><p>Additionally, this PR made big improvements to the Zig compiler’s “incremental compilation” feature. The short version is that it fixed a huge amount of known bugs, but in particular, “over-analysis” problems (where an incremental update did more work than should be necessary, sometimes by a big margin) should finally be all but eliminated—making incremental compilation significantly faster in many cases! If you’ve not already, consider <a href="https://ziglang.org/download/0.15.1/release-notes.html#Incremental-Compilation">trying out incremental compilation</a>: it really is a lovely development experience. This is for sure the improvement which excites me the most, and a large part of what motivated this change to begin with.</p><p>There are a bunch more changes that come with this PR—dozens of bugfixes, some small language changes (mostly fairly niche), and compiler performance improvements. It’s far too much to list here, but if you’re interested in reading more about it, you can take a look at <a href="https://codeberg.org/ziglang/zig/pulls/31403">the PR</a> on Codeberg—and of course, if you encounter any bugs, please do open an issue. Happy hacking!</p> </div> <div id="2026-02-13" morss_own_score="2.730125523012552" morss_score="43.23012552301255"> <span>February 13, 2026</span> <h1><a href="https://ziglang.org/devlog/2026/#2026-02-13">io_uring and Grand Central Dispatch std.Io implementations landed </a></h1> <p>Author: Andrew Kelley</p><p>As we approach the end of the 0.16.0 release cycle, Jacob has been hard at work, bringing <code>std.Io.Evented</code> up to speed with all the latest API changes:</p><p>Both of these are based on userspace stack switching, sometimes called “fibers”, “stackful coroutines”, or “green threads”.</p><p morss_own_score="7.0" morss_score="11.0">They are now <strong>available to tinker with</strong>, by constructing one’s application using <code>std.Io.Evented</code>. They should be considered <strong>experimental</strong> because there is important followup work to be done before they can be used reliably and robustly:</p><ul><li><a href="https://codeberg.org/ziglang/zig/issues/31199">better error handling</a></li><li>remove the logging</li><li>diagnose the unexpected performance degradation when using <code>IoMode.evented</code> for the compiler</li><li><a href="https://codeberg.org/ziglang/zig/issues/31200">a couple functions still unimplemented</a></li><li>more test coverage is needed</li><li><a href="https://github.com/ziglang/zig/issues/157">builtin function to tell you the maximum stack size of a given function</a> to make these implementations practical to use when overcommit is off.</li></ul><p>With those caveats in mind, it seems we are indeed reaching the Promised Land, where Zig code can have Io implementations effortlessly swapped out:</p><pre><code><span>const</span> <span>std</span> <span>=</span> <span>@import</span><span>(</span><span>"std"</span><span>)</span><span>;</span> <span>pub</span> <span>fn</span> <span>main</span><span>(</span><span>init</span><span>:</span> <span>std</span><span>.</span><span>process</span><span>.</span><span>Init</span><span>.</span><span>Minimal</span><span>)</span> <span>!</span><span>void</span> <span>{</span> <span>var</span> <span>debug_allocator</span><span>:</span> <span>std</span><span>.</span><span>heap</span><span>.</span><span>DebugAllocator</span><span>(</span><span>.</span><span>{</span><span>}</span><span>)</span> <span>=</span> <span>.</span><span>init</span><span>;</span> <span>const</span> <span>gpa</span> <span>=</span> <span>debug_allocator</span><span>.</span><span>allocator</span><span>(</span><span>)</span><span>;</span> <span>var</span> <span>threaded</span><span>:</span> <span>std</span><span>.</span><span>Io</span><span>.</span><span>Threaded</span> <span>=</span> <span>.</span><span>init</span><span>(</span><span>gpa</span><span>,</span> <span>.</span><span>{</span> <span>.</span><span>argv0</span> <span>=</span> <span>.</span><span>init</span><span>(</span><span>init</span><span>.</span><span>args</span><span>)</span><span>,</span> <span>.</span><span>environ</span> <span>=</span> <span>init</span><span>.</span><span>environ</span><span>,</span> <span>}</span><span>)</span><span>;</span> <span>defer</span> <span>threaded</span><span>.</span><span>deinit</span><span>(</span><span>)</span><span>;</span> <span>const</span> <span>io</span> <span>=</span> <span>threaded</span><span>.</span><span>io</span><span>(</span><span>)</span><span>;</span> <span>return</span> <span>app</span><span>(</span><span>io</span><span>)</span><span>;</span> <span>}</span> <span>fn</span> <span>app</span><span>(</span><span>io</span><span>:</span> <span>std</span><span>.</span><span>Io</span><span>)</span> <span>!</span><span>void</span> <span>{</span> <span>try</span> <span>std</span><span>.</span><span>Io</span><span>.</span><span>File</span><span>.</span><span>stdout</span><span>(</span><span>)</span><span>.</span><span>writeStreamingAll</span><span>(</span><span>io</span><span>,</span> <span>"Hello, World!</span><span>\n</span><span>"</span><span>)</span><span>;</span> <span>}</span> </code></pre> <pre><code>$ strace ./hello_threaded execve("./hello_threaded", ["./hello_threaded"], 0x7ffc1da88b20 /* 98 vars */) = 0 mmap(NULL, 262207, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f583f338000 arch_prctl(ARCH_SET_FS, 0x7f583f378018) = 0 prlimit64(0, RLIMIT_STACK, NULL, {rlim_cur=8192*1024, rlim_max=RLIM64_INFINITY}) = 0 prlimit64(0, RLIMIT_STACK, {rlim_cur=16384*1024, rlim_max=RLIM64_INFINITY}, NULL) = 0 sigaltstack({ss_sp=0x7f583f338000, ss_flags=0, ss_size=262144}, NULL) = 0 sched_getaffinity(0, 128, [0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31]) = 8 rt_sigaction(SIGIO, {sa_handler=0x1019d90, sa_mask=[], sa_flags=SA_RESTORER, sa_restorer=0x10328c0}, {sa_handler=SIG_DFL, sa_mask=[], sa_flags=0}, 8) = 0 rt_sigaction(SIGPIPE, {sa_handler=0x1019d90, sa_mask=[], sa_flags=SA_RESTORER, sa_restorer=0x10328c0}, {sa_handler=SIG_DFL, sa_mask=[], sa_flags=0}, 8) = 0 writev(1, [{iov_base="Hello, World!\n", iov_len=14}], 1Hello, World! ) = 14 rt_sigaction(SIGIO, {sa_handler=SIG_DFL, sa_mask=[], sa_flags=SA_RESTORER, sa_restorer=0x10328c0}, NULL, 8) = 0 rt_sigaction(SIGPIPE, {sa_handler=SIG_DFL, sa_mask=[], sa_flags=SA_RESTORER, sa_restorer=0x10328c0}, NULL, 8) = 0 exit_group(0) = ? +++ exited with 0 +++ </code></pre><p>Swapping out only the I/O implementation:</p><pre><code><span>const</span> <span>std</span> <span>=</span> <span>@import</span><span>(</span><span>"std"</span><span>)</span><span>;</span> <span>pub</span> <span>fn</span> <span>main</span><span>(</span><span>init</span><span>:</span> <span>std</span><span>.</span><span>process</span><span>.</span><span>Init</span><span>.</span><span>Minimal</span><span>)</span> <span>!</span><span>void</span> <span>{</span> <span>var</span> <span>debug_allocator</span><span>:</span> <span>std</span><span>.</span><span>heap</span><span>.</span><span>DebugAllocator</span><span>(</span><span>.</span><span>{</span><span>}</span><span>)</span> <span>=</span> <span>.</span><span>init</span><span>;</span> <span>const</span> <span>gpa</span> <span>=</span> <span>debug_allocator</span><span>.</span><span>allocator</span><span>(</span><span>)</span><span>;</span> <span>var</span> <span>evented</span><span>:</span> <span>std</span><span>.</span><span>Io</span><span>.</span><span>Evented</span> <span>=</span> <span>undefined</span><span>;</span> <span>try</span> <span>evented</span><span>.</span><span>init</span><span>(</span><span>gpa</span><span>,</span> <span>.</span><span>{</span> <span>.</span><span>argv0</span> <span>=</span> <span>.</span><span>init</span><span>(</span><span>init</span><span>.</span><span>args</span><span>)</span><span>,</span> <span>.</span><span>environ</span> <span>=</span> <span>init</span><span>.</span><span>environ</span><span>,</span> <span>.</span><span>backing_allocator_needs_mutex</span> <span>=</span> <span>false</span><span>,</span> <span>}</span><span>)</span><span>;</span> <span>defer</span> <span>evented</span><span>.</span><span>deinit</span><span>(</span><span>)</span><span>;</span> <span>const</span> <span>io</span> <span>=</span> <span>evented</span><span>.</span><span>io</span><span>(</span><span>)</span><span>;</span> <span>return</span> <span>app</span><span>(</span><span>io</span><span>)</span><span>;</span> <span>}</span> <span>fn</span> <span>app</span><span>(</span><span>io</span><span>:</span> <span>std</span><span>.</span><span>Io</span><span>)</span> <span>!</span><span>void</span> <span>{</span> <span>try</span> <span>std</span><span>.</span><span>Io</span><span>.</span><span>File</span><span>.</span><span>stdout</span><span>(</span><span>)</span><span>.</span><span>writeStreamingAll</span><span>(</span><span>io</span><span>,</span> <span>"Hello, World!</span><span>\n</span><span>"</span><span>)</span><span>;</span> <span>}</span> </code></pre> <pre><code>execve("./hello_evented", ["./hello_evented"], 0x7fff368894f0 /* 98 vars */) = 0 mmap(NULL, 262215, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f70a4c28000 arch_prctl(ARCH_SET_FS, 0x7f70a4c68020) = 0 prlimit64(0, RLIMIT_STACK, NULL, {rlim_cur=8192*1024, rlim_max=RLIM64_INFINITY}) = 0 prlimit64(0, RLIMIT_STACK, {rlim_cur=16384*1024, rlim_max=RLIM64_INFINITY}, NULL) = 0 sigaltstack({ss_sp=0x7f70a4c28008, ss_flags=0, ss_size=262144}, NULL) = 0 sched_getaffinity(0, 128, [0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31]) = 8 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f70a4c27000 mmap(0x7f70a4c28000, 548864, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f70a4ba1000 io_uring_setup(64, {flags=IORING_SETUP_COOP_TASKRUN|IORING_SETUP_SINGLE_ISSUER, sq_thread_cpu=0, sq_thread_idle=1000, sq_entries=64, cq_entries=128, features=IORING_FEAT_SINGLE_MMAP|IORING_FEAT_NODROP|IORING_FEAT_SUBMIT_STABLE|IORING_FEAT_RW_CUR_POS|IORING_FEAT_CUR_PERSONALITY|IORING_FEAT_FAST_POLL|IORING_FEAT_POLL_32BITS|IORING_FEAT_SQPOLL_NONFIXED|IORING_FEAT_EXT_ARG|IORING_FEAT_NATIVE_WORKERS|IORING_FEAT_RSRC_TAGS|IORING_FEAT_CQE_SKIP|IORING_FEAT_LINKED_FILE|IORING_FEAT_REG_REG_RING|IORING_FEAT_RECVSEND_BUNDLE|IORING_FEAT_MIN_TIMEOUT|IORING_FEAT_RW_ATTR|IORING_FEAT_NO_IOWAIT, sq_off={head=0, tail=4, ring_mask=16, ring_entries=24, flags=36, dropped=32, array=2112, user_addr=0}, cq_off={head=8, tail=12, ring_mask=20, ring_entries=28, overflow=44, cqes=64, flags=40, user_addr=0}}) = 3 mmap(NULL, 2368, PROT_READ|PROT_WRITE, MAP_SHARED|MAP_POPULATE, 3, 0) = 0x7f70a4ba0000 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_SHARED|MAP_POPULATE, 3, 0x10000000) = 0x7f70a4b9f000 io_uring_enter(3, 1, 1, IORING_ENTER_GETEVENTS, NULL, 8Hello, World! ) = 1 io_uring_enter(3, 1, 1, IORING_ENTER_GETEVENTS, NULL, 8) = 1 munmap(0x7f70a4b9f000, 4096) = 0 munmap(0x7f70a4ba0000, 2368) = 0 close(3) = 0 munmap(0x7f70a4ba1000, 548864) = 0 exit_group(0) = ? +++ exited with 0 +++ </code></pre><p>Key point here being that the <code>app</code> function is identical between those two snippets.</p><p>Moving beyond Hello World, the Zig compiler itself works fine using <code>std.Io.Evented</code>, both with io_uring and with GCD, but as mentioned above, there is a not-yet-diagnosed performance degradation when doing so.</p><p>Happy hacking,</p><p>Andrew</p> </div> <div id="2026-02-06" morss_own_score="2.7857142857142856" morss_score="65.98756613756615"> <span>February 06, 2026</span> <h1><a href="https://ziglang.org/devlog/2026/#2026-02-06">Two Package Management Workflow Enhancements </a></h1> <p>Author: Andrew Kelley</p><p>If you have a Zig project with dependencies, two big changes just landed which I think you will be interested to learn about.</p><p>Fetched packages are now stored <em>locally</em> in the <code>zig-pkg</code> directory of the project root (next to your <code>build.zig</code> file).</p><p>For example here are a few results from <a href="https://codeberg.org/awebo-chat/awebo">awebo</a> after running <code>zig build</code>:</p><pre><code>$ du -sh zig-pkg/* 13M freetype-2.14.1-alzUkTyBqgBwke4Jsot997WYSpl207Ij9oO-2QOvGrOi 20K opus-0.0.2-vuF-cMAkAADVsm707MYCtPmqmRs0gzg84Sz0qGbb5E3w 4.3M pulseaudio-16.1.1-9-mk_62MZkNwBaFwiZ7ZVrYRIf_3dTqqJR5PbMRCJzSuLw 5.2M uucode-0.1.0-ZZjBPvtWUACf5dqD_f9I37VGFsN24436CuceC5pTJ25n 728K vaxis-0.5.1-BWNV_AxECQCj3p4Hcv4U3Yo1WMUJ7Z2FUj0UkpuJGxQQ </code></pre><p>It is highly recommended to add this directory to the project-local source control ignore file (e.g. <code>.gitignore</code>). However, by being outside of <code>.zig-cache</code>, it provides the possibility of distributing self-contained source tarballs, which contain all dependencies and therefore can be used to build offline, or for archival purposes.</p><p>Meanwhile, an <em>additional</em> copy of the dependency is cached globally. After filtering out all the unused files based on the <code>paths</code> filter, the contents are recompressed:</p><pre><code>$ du -sh ~/.cache/zig/p/* 2.4M freetype-2.14.1-alzUkTyBqgBwke4Jsot997WYSpl207Ij9oO-2QOvGrOi.tar.gz 4.0K opus-0.0.2-vuF-cMAkAADVsm707MYCtPmqmRs0gzg84Sz0qGbb5E3w.tar.gz 636K pulseaudio-16.1.1-9-mk_62MZkNwBaFwiZ7ZVrYRIf_3dTqqJR5PbMRCJzSuLw.tar.gz 880K uucode-0.1.0-ZZjBPvtWUACf5dqD_f9I37VGFsN24436CuceC5pTJ25n.tar.gz 120K vaxis-0.5.1-BWNV_BFECQBbXeTeFd48uTJRjD5a-KD6kPuKanzzVB01.tar.gz </code></pre><p>The motivation for this change is to make it easier to tinker. Go ahead and edit those files, see what happens. Swap out your package directory with a git clone. Grep your dependencies all together. Configure your IDE to auto-complete based on the <code>zig-pkg</code> directory. <a href="https://codeberg.org/awebo-chat/awebo/issues/61">Run baobab on your dependency tree</a>. Furthermore, by having the global cache have compressed files instead makes it easier to share that cached data between computers. In the future, <a href="https://github.com/ziglang/zig/issues/23236">it is planned to support peer-to-peer torrenting of dependency trees</a>. By recompressing packages into a canonical form, this will allow peers to share Zig packages with minimal bandwidth. I love this idea because it simultaneously provides resilience to network outages, as well as a popularity contest. Find out which open source packages are popular based on number of seeders!</p><p>The second change here is the addition of the <code>--fork</code> flag to <code>zig build</code>.</p><p>In retrospect, it seems so obvious, I don’t know why I didn’t think of it since the beginning. It looks like this:</p><pre><code>zig build --fork=[path] </code></pre><p>This is a <strong>project override</strong> option. Given a path to a source checkout of a project, all packages matching that project across the entire dependency tree will be overridden.</p><p>Thanks to the fact that package content hashes include name and fingerprint, <strong>this resolves before the package is potentially fetched</strong>.</p><p>This is an easy way to temporarily use one or more forks which are in entirely separate directories. You can iterate on your entire dependency tree until everything is working, while using comfortably the development environment and source control of the dependency projects.</p><p>The fact that it is a CLI flag makes it appropriately ephemeral. The moment you drop the flags, you’re back to using your pristine, fetched dependency tree.</p><p>If the project does not match, an error occurs, preventing confusion:</p><pre><code>$ zig build --fork=/home/andy/dev/mime error: fork /home/andy/dev/mime matched no mime packages $ </code></pre><p>If the project does match, you get a reminder that you are using a fork, preventing confusion:</p><pre><code>$ zig build --fork=/home/andy/dev/dvui info: fork /home/andy/dev/dvui matched 1 (dvui) packages ... </code></pre><p>This functionality is intended to enhance the workflow of dealing with ecosystem breakage. I already tried it a bit and found it to be quite pleasant to work with. The new workflow goes like this:</p><ol><li>Fail to build from source due to ecosystem breakage.</li><li>Tinker with <code>--fork</code> until your project works again. During this time you can use the actual upstream source control, test suite, <code>zig build test --watch -fincremental</code>, etc.</li><li>Now you have a new option: be selfish and just keep working on your own stuff, or you can proceed to submit your patches upstream.</li></ol><p>…and you can probably skip the step where you switch your <code>build.zig.zon</code> to your fork unless you expect upstream to take a long time to merge your fixes.</p> </div> <div id="2026-02-03" morss_own_score="2.702888583218707" morss_score="68.84715520588823"> <span>February 03, 2026</span> <h1><a href="https://ziglang.org/devlog/2026/#2026-02-03">Bypassing Kernel32.dll for Fun and Nonprofit </a></h1> <p>Author: Andrew Kelley</p><p>The Windows operating system provides a large ABI surface area for doing things in the kernel. However, not all ABIs are created equally. As Casey Muratori points out in his lecture, <a href="https://www.youtube.com/watch?v=5IUj1EZwpJY">The Only Unbreakable Law</a>, the organizational structure of software development teams has a direct impact on the structure of the software they produce.</p><p>The DLLs on Windows are organized into a heirarchy, with some of the APIs being high-level wrappers around lower-level ones. For example, whenever you call functions of <code>kernel32.dll</code>, ultimately, the actual work is done by <code>ntdll.dll</code>. You can observe this directly by using ProcMon.exe and examining stack traces.</p><p>What we’ve learned empirically is that the ntdll APIs are generally well-engineered, reasonable, and powerful, but the kernel32 wrappers introduce unnecessary heap allocations, additional failure modes, unintentional CPU usage, and bloat.</p><p>This is why the Zig standard library policy is to <a href="https://codeberg.org/ziglang/zig/issues/31131">Prefer the Native API over Win32</a>. We’re not quite there yet - we have plenty of calls into kernel32 remaining - but we’ve taken great strides recently. I’ll give you two examples.</p><h2>Example 1: Entropy</h2><p>According to the official documentation, Windows does not have a straightforward way to get random bytes.</p><p><a href="https://github.com/rust-random/rand/issues/111">Many projects including Chromium, boringssl, Firefox, and Rust</a> call <code>SystemFunction036</code> from <code>advapi32.dll</code> because it worked on versions older than Windows 8.</p><p>Unfortunately, starting with Windows 8, the first time you call this function, it dynamically loads <code>bcryptprimitives.dll</code> and calls <a href="https://learn.microsoft.com/en-us/windows/win32/seccng/processprng">ProcessPrng</a>. If loading the DLL fails (for example due to an overloaded system, which we have observed on Zig CI several times), it returns error 38 (from a function that has <code>void</code> return type and is documented to never fail).</p><p>The first thing <code>ProcessPrng</code> does is heap allocate a small, constant number of bytes. If this fails it returns <code>NO_MEMORY</code> in a <code>BOOL</code> (documented behavior is to never fail, and always return <code>TRUE</code>).</p><p><code>bcryptprimitives.dll</code> apparently also runs a test suite every time you load it.</p><p>All that <code>ProcessPrng</code> is <em>really</em> doing is <code>NtOpenFile</code> on <code>"\\Device\\CNG"</code> and reading 48 bytes with <code>NtDeviceIoControlFile</code> to get a seed, and then initializing a per-CPU AES-based CSPRNG.</p><p>So the dependency on <code>bcryptprimitives.dll</code> and <code>advapi32.dll</code> can both be avoided, and the nondeterministic failure and latencies on first RNG read can also be avoided.</p><h2>Example 2: NtReadFile and NtWriteFile</h2><p><code>ReadFile</code> looks like this:</p><pre><code class="zig" morss_own_score="3.0" morss_score="10.5"><span>pub</span> <span>extern</span> <span>"kernel32"</span> <span>fn</span> <span>ReadFile</span><span>(</span> <span>hFile</span><span>:</span> <span>HANDLE</span><span>,</span> <span>lpBuffer</span><span>:</span> <span>LPVOID</span><span>,</span> <span>nNumberOfBytesToRead</span><span>:</span> <span>DWORD</span><span>,</span> <span>lpNumberOfBytesRead</span><span>:</span> <span>?</span><span>*</span><span>DWORD</span><span>,</span> <span>lpOverlapped</span><span>:</span> <span>?</span><span>*</span><span>OVERLAPPED</span><span>,</span> <span>)</span> <span>callconv</span><span>(</span><span>.</span><span>winapi</span><span>)</span> <span>BOOL</span><span>;</span> </code></pre> <p><code>NtReadFile</code> looks like this:</p><pre><code class="zig" morss_own_score="3.0" morss_score="16.5"><span>pub</span> <span>extern</span> <span>"ntdll"</span> <span>fn</span> <span>NtReadFile</span><span>(</span> <span>FileHandle</span><span>:</span> <span>HANDLE</span><span>,</span> <span>Event</span><span>:</span> <span>?</span><span>HANDLE</span><span>,</span> <span>ApcRoutine</span><span>:</span> <span>?</span><span>*</span><span>const</span> <span>IO_APC_ROUTINE</span><span>,</span> <span>ApcContext</span><span>:</span> <span>?</span><span>*</span><span>anyopaque</span><span>,</span> <span>IoStatusBlock</span><span>:</span> <span>*</span><span>IO_STATUS_BLOCK</span><span>,</span> <span>Buffer</span><span>:</span> <span>*</span><span>anyopaque</span><span>,</span> <span>Length</span><span>:</span> <span>ULONG</span><span>,</span> <span>ByteOffset</span><span>:</span> <span>?</span><span>*</span><span>const</span> <span>LARGE_INTEGER</span><span>,</span> <span>Key</span><span>:</span> <span>?</span><span>*</span><span>const</span> <span>ULONG</span><span>,</span> <span>)</span> <span>callconv</span><span>(</span><span>.</span><span>winapi</span><span>)</span> <span>NTSTATUS</span><span>;</span> </code></pre> <p>As a reminder, <em>the above function is implemented by calling the below function</em>.</p><p>Already we can see some nice things about using the lower level API. For instance, the <em>real</em> API simply gives us the error code as the return value, while the kernel32 wrapper hides the status code somewhere, returns a <code>BOOL</code> and then requires you to call <code>GetLastError</code> to find out what went wrong. Imagine! Returning a value from a function 🌈</p><p>Furthermore, <code>OVERLAPPED</code> is a fake type. The Windows kernel doesn’t actually know or care about it at all! The actual primitives here are events, APCs, and <code>IO_STATUS_BLOCK</code>.</p><p>If you have a synchronous file handle, then <code>Event</code> and <code>ApcRoutine</code> must be <code>null</code>. You get the answer in the <code>IO_STATUS_BLOCK</code> immediately. If you pass an APC routine here then some old bitrotted 32-bit code runs and you get garbage results.</p><p>On the other hand if you have an asynchronous file handle, then you need to either use an <code>Event</code> or an <code>ApcRoutine</code>. <code>kernel32.dll</code> uses events, which means that it’s doing extra, unnecessary resource allocation and management just to read from a file. Instead, Zig now passes an APC routine and then calls <code>NtDelayExecution</code>. This integrates seamlessly with cancelation, making it possible to cancel tasks while they perform file I/O, regardless of whether the file was opened in synchronous mode or asynchronous mode.</p><p>For a deeper dive into this topic, please refer to this issue:</p><p><a href="https://codeberg.org/ziglang/zig/issues/31131">Windows: Prefer the Native API over Win32</a></p> </div> <div id="2026-01-31" morss_own_score="2.475982532751092" morss_score="28.633894388337364"> <span>January 31, 2026</span> <h1><a href="https://ziglang.org/devlog/2026/#2026-01-31">zig libc </a></h1> <p>Author: Andrew Kelley</p><p>Over the past month or so, several enterprising contributors have taken an interest in the <a href="https://codeberg.org/ziglang/zig/issues/30978">zig libc subproject</a>. The idea here is to incrementally delete redundant code, by providing libc functions as Zig standard library wrappers rather than as vendored C source files. In many cases, these functions are one-to-one mappings, such as <code>memcpy</code> or <code>atan2</code>, or trivially wrap a generic function, like <code>strnlen</code>:</p><pre><code><span>fn</span> <span>strnlen</span><span>(</span><span>str</span><span>:</span> <span>[</span><span>*</span><span>:</span><span>0</span><span>]</span><span>const</span> <span>c_char</span><span>,</span> <span>max</span><span>:</span> <span>usize</span><span>)</span> <span>callconv</span><span>(</span><span>.</span><span>c</span><span>)</span> <span>usize</span> <span>{</span> <span>return</span> <span>std</span><span>.</span><span>mem</span><span>.</span><span>findScalar</span><span>(</span><span>u8</span><span>,</span> <span>@ptrCast</span><span>(</span><span>str</span><span>[</span><span>0</span><span>..</span><span>max</span><span>]</span><span>)</span><span>,</span> <span>0</span><span>)</span> <span>orelse</span> <span>max</span><span>;</span> <span>}</span> </code></pre> <p>So far, roughly 250 C source files have been deleted from the Zig repository, with 2032 remaining.</p><p>With each function that makes the transition, Zig gains independence from third party projects and from the C programming language, compilation speed improves, Zig’s installation size is simplified and reduced, and user applications which statically link libc enjoy reduced binary size.</p><p>Additionally, a <a href="https://codeberg.org/ziglang/zig/pulls/31037">recent enhancement</a> now makes zig libc share the Zig Compilation Unit with other Zig code rather than being a separate static archive, linked together later. This is one of the advantages of Zig having an integrated compiler and linker. When the exported libc functions share the ZCU, redundant code is eliminated because functions can be optimized together. It’s kind of like enabling LTO (Link-Time Optimization) across the libc boundary, except it’s done properly in the frontend instead of too late, in the linker.</p><p>Furthermore, when this work is combined with the recent <a href="https://codeberg.org/ziglang/zig/issues/30150">std.Io changes</a>, there is potential for users to seamlessly control how libc performs I/O - for example forcing all calls to <code>read</code> and <code>write</code> to participate in an io_uring event loop, even though that code was not written with such use case in mind. Or, <a href="https://codeberg.org/ziglang/zig/pulls/30788">resource leak detection</a> could be enabled for third-party C code. For now this is only a vaporware idea which has not been experimented with, but the idea intrigues me.</p><p>Big thanks to Szabolcs Nagy for <a href="https://wiki.musl-libc.org/libc-test.html">libc-test</a>. This project has been a huge help in making sure that we don’t regress any math functions.</p><p>As a reminder to our users, now that Zig is transitioning to being the static libc provider, if you encounter issues with the musl, mingw-w64, or wasi-libc libc functionality provided by Zig, <strong>please file bug reports in Zig first</strong> so we don’t annoy maintainers for bugs that are in Zig, and no longer vendored by independent libc implementation projects.</p><p>The very same day I sat at home writing this devlog like a coward, less than five miles away, <a href="https://www.kptv.com/2026/01/31/live-labor-unions-rally-march-portland-ice-facility-protest/">armed forces who are in my city against the will of our elected officials shot tear gas, unprovoked, at peaceful protestors</a>. Next time I hope to have the courage to join my neighbors, and I hope to not get shot like <a href="https://en.wikipedia.org/wiki/Killing_of_Alex_Pretti">Alex Pretti</a> and <a href="https://en.wikipedia.org/wiki/Killing_of_Ren%C3%A9e_Good">Renée Good</a>.</p> </div> </div> https://s-macke.github.io/VoxelSpace/Sat, 30 May 2026 14:25:50 +0000https://news.ycombinator.com/item?id=48336564<a href="https://news.ycombinator.com/item?id=48336564">Comments</a><div class="container-lg px-3 my-5 markdown-body" morss_own_score="5.048665620094191" morss_score="141.38707877926205"> <h1><a href="https://s-macke.github.io/VoxelSpace/">VoxelSpace</a></h1> <h1>Voxel Space</h1> <p><img src="https://s-macke.github.io/VoxelSpace/images/webdemo.gif"></p> <h1><strong><a href="https://s-macke.github.io/VoxelSpace/VoxelSpace.html">Web Demo of the Voxel Space Engine</a></strong></h1> <h2>History</h2> <p>Let us go back to the year 1992. The CPUs were 1000 times slower than today and the acceleration via a GPU was unknown or unaffordable. 3D games were calculated exclusively on the CPU and the rendering engine rendered filled polygons with a single color.</p> <p><img src="https://s-macke.github.io/VoxelSpace/images/gunship2000-1991.gif"> <em>Game Gunship 2000 published by MicroProse in 1991</em></p> <p>It was during that year <a href="http://www.novalogic.com/">NovaLogic</a> published the game <a href="https://en.wikipedia.org/wiki/Comanche_(video_game_series)">Comanche</a>.</p> <p><img src="https://s-macke.github.io/VoxelSpace/images/comanche-1992.gif"> <em>Game Comanche published by NovaLogic in 1992</em></p> <p>The graphics were breathtaking for the time being and in my opinion 3 years ahead of its time. You see many more details such as textures on mountains and valleys, and for the first time a neat shading and even shadows. Sure, it’s pixelated, but all games in those years were pixelated.</p> <h2>Render algorithm</h2> <p><a href="https://en.wikipedia.org/wiki/Comanche_(video_game_series)">Comanche</a> uses a technique called <a href="https://en.wikipedia.org/wiki/Voxel_Space">Voxel Space</a>, which is based on the same ideas like <a href="https://en.wikipedia.org/wiki/Ray_casting">ray casting</a>. Hence the Voxel Space engine is a 2.5D engine, it doesn’t have all the levels of freedom that a regular 3D engine offers.</p> <h3>Height map and color map</h3> <p>The easiest way to represent a terrain is through a height map and color map. For the game Comanche a 1024 * 1024 one byte height map and a 1024 * 1024 one byte color map is used which you can download on this site. These maps are periodic:</p> <p><img src="https://s-macke.github.io/VoxelSpace/images/periodicmap.gif"></p> <p>Such maps limit the terrain to “one height per position on the map” - Complex geometries such as buildings or trees are not possible to represent. However, a great advantage of the colormap is, that it already contains the shading and shadows. The Voxel Space engine just takes the color and doesn’t have to compute illumination during the render process.</p> <h3>Basic algorithm</h3> <p>For a 3D engine the rendering algorithm is amazingly simple. The Voxel Space engine rasters the height and color map and draws vertical lines. The following figure demonstrate this technique.</p> <p><img src="https://s-macke.github.io/VoxelSpace/images/linebyline.gif"></p> <ul> <li>Clear Screen.</li> <li>To guarantee occlusion start from the back and render to the front. This is called painter algorithm.</li> <li>Determine the line on the map, which corresponds to the same optical distance from the observer. Consider the field of view and the <a href="https://en.wikipedia.org/wiki/3D_projection">perspective projection</a> (Objects are smaller farther away)</li> <li>Raster the line so that it matches the number of columns of the screen.</li> <li>Retrieve the height and color from the 2D maps corresponding of the segment of the line.</li> <li>Perform the <a href="https://en.wikipedia.org/wiki/3D_projection">perspective projection</a> for the height coordinate.</li> <li>Draw a vertical line with the corresponding color with the height retrieved from the perspective projection.</li> </ul> <p>The core algorithm contains in its simplest form only a few lines of code (python syntax):</p> <pre><code><span>def</span> <span>Render</span><span>(</span><span>p</span><span>,</span> <span>height</span><span>,</span> <span>horizon</span><span>,</span> <span>scale_height</span><span>,</span> <span>distance</span><span>,</span> <span>screen_width</span><span>,</span> <span>screen_height</span><span>):</span> <span># Draw from back to the front (high z coordinate to low z coordinate) </span> <span>for</span> <span>z</span> <span>in</span> <span>range</span><span>(</span><span>distance</span><span>,</span> <span>1</span><span>,</span> <span>-</span><span>1</span><span>):</span> <span># Find line on map. This calculation corresponds to a field of view of 90° </span> <span>pleft</span> <span>=</span> <span>Point</span><span>(</span><span>-</span><span>z</span> <span>+</span> <span>p</span><span>.</span><span>x</span><span>,</span> <span>-</span><span>z</span> <span>+</span> <span>p</span><span>.</span><span>y</span><span>)</span> <span>pright</span> <span>=</span> <span>Point</span><span>(</span> <span>z</span> <span>+</span> <span>p</span><span>.</span><span>x</span><span>,</span> <span>-</span><span>z</span> <span>+</span> <span>p</span><span>.</span><span>y</span><span>)</span> <span># segment the line </span> <span>dx</span> <span>=</span> <span>(</span><span>pright</span><span>.</span><span>x</span> <span>-</span> <span>pleft</span><span>.</span><span>x</span><span>)</span> <span>/</span> <span>screen_width</span> <span># Raster line and draw a vertical line for each segment </span> <span>for</span> <span>i</span> <span>in</span> <span>range</span><span>(</span><span>0</span><span>,</span> <span>screen_width</span><span>):</span> <span>height_on_screen</span> <span>=</span> <span>(</span><span>height</span> <span>-</span> <span>heightmap</span><span>[</span><span>pleft</span><span>.</span><span>x</span><span>,</span> <span>pleft</span><span>.</span><span>y</span><span>])</span> <span>/</span> <span>z</span> <span>*</span> <span>scale_height</span><span>.</span> <span>+</span> <span>horizon</span> <span>DrawVerticalLine</span><span>(</span><span>i</span><span>,</span> <span>height_on_screen</span><span>,</span> <span>screen_height</span><span>,</span> <span>colormap</span><span>[</span><span>pleft</span><span>.</span><span>x</span><span>,</span> <span>pleft</span><span>.</span><span>y</span><span>])</span> <span>pleft</span><span>.</span><span>x</span> <span>+=</span> <span>dx</span> <span># Call the render function with the camera parameters: # position, height, horizon line position, # scaling factor for the height, the largest distance, # screen width and the screen height parameter </span><span>Render</span><span>(</span> <span>Point</span><span>(</span><span>0</span><span>,</span> <span>0</span><span>),</span> <span>50</span><span>,</span> <span>120</span><span>,</span> <span>120</span><span>,</span> <span>300</span><span>,</span> <span>800</span><span>,</span> <span>600</span> <span>)</span> </code></pre> <h3>Add rotation</h3> <p>With the algorithm above we can only view to the north. A different angle needs a few more lines of code to rotate the coordinates.</p> <p><img src="https://s-macke.github.io/VoxelSpace/images/rotate.gif"></p> <pre><code><span>def</span> <span>Render</span><span>(</span><span>p</span><span>,</span> <span>phi</span><span>,</span> <span>height</span><span>,</span> <span>horizon</span><span>,</span> <span>scale_height</span><span>,</span> <span>distance</span><span>,</span> <span>screen_width</span><span>,</span> <span>screen_height</span><span>):</span> <span># precalculate viewing angle parameters </span> <span>var</span> <span>sinphi</span> <span>=</span> <span>math</span><span>.</span><span>sin</span><span>(</span><span>phi</span><span>);</span> <span>var</span> <span>cosphi</span> <span>=</span> <span>math</span><span>.</span><span>cos</span><span>(</span><span>phi</span><span>);</span> <span># Draw from back to the front (high z coordinate to low z coordinate) </span> <span>for</span> <span>z</span> <span>in</span> <span>range</span><span>(</span><span>distance</span><span>,</span> <span>1</span><span>,</span> <span>-</span><span>1</span><span>):</span> <span># Find line on map. This calculation corresponds to a field of view of 90° </span> <span>pleft</span> <span>=</span> <span>Point</span><span>(</span> <span>(</span><span>-</span><span>cosphi</span><span>*</span><span>z</span> <span>-</span> <span>sinphi</span><span>*</span><span>z</span><span>)</span> <span>+</span> <span>p</span><span>.</span><span>x</span><span>,</span> <span>(</span> <span>sinphi</span><span>*</span><span>z</span> <span>-</span> <span>cosphi</span><span>*</span><span>z</span><span>)</span> <span>+</span> <span>p</span><span>.</span><span>y</span><span>)</span> <span>pright</span> <span>=</span> <span>Point</span><span>(</span> <span>(</span> <span>cosphi</span><span>*</span><span>z</span> <span>-</span> <span>sinphi</span><span>*</span><span>z</span><span>)</span> <span>+</span> <span>p</span><span>.</span><span>x</span><span>,</span> <span>(</span><span>-</span><span>sinphi</span><span>*</span><span>z</span> <span>-</span> <span>cosphi</span><span>*</span><span>z</span><span>)</span> <span>+</span> <span>p</span><span>.</span><span>y</span><span>)</span> <span># segment the line </span> <span>dx</span> <span>=</span> <span>(</span><span>pright</span><span>.</span><span>x</span> <span>-</span> <span>pleft</span><span>.</span><span>x</span><span>)</span> <span>/</span> <span>screen_width</span> <span>dy</span> <span>=</span> <span>(</span><span>pright</span><span>.</span><span>y</span> <span>-</span> <span>pleft</span><span>.</span><span>y</span><span>)</span> <span>/</span> <span>screen_width</span> <span># Raster line and draw a vertical line for each segment </span> <span>for</span> <span>i</span> <span>in</span> <span>range</span><span>(</span><span>0</span><span>,</span> <span>screen_width</span><span>):</span> <span>height_on_screen</span> <span>=</span> <span>(</span><span>height</span> <span>-</span> <span>heightmap</span><span>[</span><span>pleft</span><span>.</span><span>x</span><span>,</span> <span>pleft</span><span>.</span><span>y</span><span>])</span> <span>/</span> <span>z</span> <span>*</span> <span>scale_height</span><span>.</span> <span>+</span> <span>horizon</span> <span>DrawVerticalLine</span><span>(</span><span>i</span><span>,</span> <span>height_on_screen</span><span>,</span> <span>screen_height</span><span>,</span> <span>colormap</span><span>[</span><span>pleft</span><span>.</span><span>x</span><span>,</span> <span>pleft</span><span>.</span><span>y</span><span>])</span> <span>pleft</span><span>.</span><span>x</span> <span>+=</span> <span>dx</span> <span>pleft</span><span>.</span><span>y</span> <span>+=</span> <span>dy</span> <span># Call the render function with the camera parameters: # position, viewing angle, height, horizon line position, # scaling factor for the height, the largest distance, # screen width and the screen height parameter </span><span>Render</span><span>(</span> <span>Point</span><span>(</span><span>0</span><span>,</span> <span>0</span><span>),</span> <span>0</span><span>,</span> <span>50</span><span>,</span> <span>120</span><span>,</span> <span>120</span><span>,</span> <span>300</span><span>,</span> <span>800</span><span>,</span> <span>600</span> <span>)</span> </code></pre> <h3>More performance</h3> <p>There are of course a lot of tricks to achieve higher performance.</p> <ul> <li>Instead of drawing from back to the front we can draw from front to back. The advantage is, the we don’t have to draw lines to the bottom of the screen every time because of occlusion. However, to guarantee occlusion we need an additional y-buffer. For every column, the highest y position is stored. Because we are drawing from the front to back, the visible part of the next line can only be larger then the highest line previously drawn.</li> <li>Level of Detail. Render more details in front but less details far away.</li> </ul> <p><img src="https://s-macke.github.io/VoxelSpace/images/fronttoback.gif"></p> <pre><code><span>def</span> <span>Render</span><span>(</span><span>p</span><span>,</span> <span>phi</span><span>,</span> <span>height</span><span>,</span> <span>horizon</span><span>,</span> <span>scale_height</span><span>,</span> <span>distance</span><span>,</span> <span>screen_width</span><span>,</span> <span>screen_height</span><span>):</span> <span># precalculate viewing angle parameters </span> <span>var</span> <span>sinphi</span> <span>=</span> <span>math</span><span>.</span><span>sin</span><span>(</span><span>phi</span><span>);</span> <span>var</span> <span>cosphi</span> <span>=</span> <span>math</span><span>.</span><span>cos</span><span>(</span><span>phi</span><span>);</span> <span># initialize visibility array. Y position for each column on screen </span> <span>ybuffer</span> <span>=</span> <span>np</span><span>.</span><span>zeros</span><span>(</span><span>screen_width</span><span>)</span> <span>for</span> <span>i</span> <span>in</span> <span>range</span><span>(</span><span>0</span><span>,</span> <span>screen_width</span><span>):</span> <span>ybuffer</span><span>[</span><span>i</span><span>]</span> <span>=</span> <span>screen_height</span> <span># Draw from front to the back (low z coordinate to high z coordinate) </span> <span>dz</span> <span>=</span> <span>1.</span> <span>z</span> <span>=</span> <span>1.</span> <span>while</span> <span>z</span> <span>&lt;</span> <span>distance</span> <span># Find line on map. This calculation corresponds to a field of view of 90° </span> <span>pleft</span> <span>=</span> <span>Point</span><span>(</span> <span>(</span><span>-</span><span>cosphi</span><span>*</span><span>z</span> <span>-</span> <span>sinphi</span><span>*</span><span>z</span><span>)</span> <span>+</span> <span>p</span><span>.</span><span>x</span><span>,</span> <span>(</span> <span>sinphi</span><span>*</span><span>z</span> <span>-</span> <span>cosphi</span><span>*</span><span>z</span><span>)</span> <span>+</span> <span>p</span><span>.</span><span>y</span><span>)</span> <span>pright</span> <span>=</span> <span>Point</span><span>(</span> <span>(</span> <span>cosphi</span><span>*</span><span>z</span> <span>-</span> <span>sinphi</span><span>*</span><span>z</span><span>)</span> <span>+</span> <span>p</span><span>.</span><span>x</span><span>,</span> <span>(</span><span>-</span><span>sinphi</span><span>*</span><span>z</span> <span>-</span> <span>cosphi</span><span>*</span><span>z</span><span>)</span> <span>+</span> <span>p</span><span>.</span><span>y</span><span>)</span> <span># segment the line </span> <span>dx</span> <span>=</span> <span>(</span><span>pright</span><span>.</span><span>x</span> <span>-</span> <span>pleft</span><span>.</span><span>x</span><span>)</span> <span>/</span> <span>screen_width</span> <span>dy</span> <span>=</span> <span>(</span><span>pright</span><span>.</span><span>y</span> <span>-</span> <span>pleft</span><span>.</span><span>y</span><span>)</span> <span>/</span> <span>screen_width</span> <span># Raster line and draw a vertical line for each segment </span> <span>for</span> <span>i</span> <span>in</span> <span>range</span><span>(</span><span>0</span><span>,</span> <span>screen_width</span><span>):</span> <span>height_on_screen</span> <span>=</span> <span>(</span><span>height</span> <span>-</span> <span>heightmap</span><span>[</span><span>pleft</span><span>.</span><span>x</span><span>,</span> <span>pleft</span><span>.</span><span>y</span><span>])</span> <span>/</span> <span>z</span> <span>*</span> <span>scale_height</span><span>.</span> <span>+</span> <span>horizon</span> <span>DrawVerticalLine</span><span>(</span><span>i</span><span>,</span> <span>height_on_screen</span><span>,</span> <span>ybuffer</span><span>[</span><span>i</span><span>],</span> <span>colormap</span><span>[</span><span>pleft</span><span>.</span><span>x</span><span>,</span> <span>pleft</span><span>.</span><span>y</span><span>])</span> <span>if</span> <span>height_on_screen</span> <span>&lt;</span> <span>ybuffer</span><span>[</span><span>i</span><span>]:</span> <span>ybuffer</span><span>[</span><span>i</span><span>]</span> <span>=</span> <span>height_on_screen</span> <span>pleft</span><span>.</span><span>x</span> <span>+=</span> <span>dx</span> <span>pleft</span><span>.</span><span>y</span> <span>+=</span> <span>dy</span> <span># Go to next line and increase step size when you are far away </span> <span>z</span> <span>+=</span> <span>dz</span> <span>dz</span> <span>+=</span> <span>0.2</span> <span># Call the render function with the camera parameters: # position, viewing angle, height, horizon line position, # scaling factor for the height, the largest distance, # screen width and the screen height parameter </span><span>Render</span><span>(</span> <span>Point</span><span>(</span><span>0</span><span>,</span> <span>0</span><span>),</span> <span>0</span><span>,</span> <span>50</span><span>,</span> <span>120</span><span>,</span> <span>120</span><span>,</span> <span>300</span><span>,</span> <span>800</span><span>,</span> <span>600</span> <span>)</span> </code></pre> <h2>Links</h2> <p><a href="https://s-macke.github.io/VoxelSpace/VoxelSpace.html">Web Project demo</a> page</p> <p><a href="https://web.archive.org/web/20131113094653/http://www.codermind.com/articles/Voxel-terrain-engine-building-the-terrain.html">Voxel terrain engine - an introduction</a></p> <p><a href="http://www.simulationcorner.net">Personal website</a></p> <h2>Maps</h2> <p><a href="https://s-macke.github.io/VoxelSpace/maps/C1W.png">color</a>, <a href="https://s-macke.github.io/VoxelSpace/maps/D1.png">height</a></p> <p><img src="https://s-macke.github.io/VoxelSpace/images/thumbnails/C1W.png"> <img src="https://s-macke.github.io/VoxelSpace/images/thumbnails/D1.png"></p> <p><a href="https://s-macke.github.io/VoxelSpace/maps/C2W.png">color</a>, <a href="https://s-macke.github.io/VoxelSpace/maps/D2.png">height</a></p> <p><img src="https://s-macke.github.io/VoxelSpace/images/thumbnails/C2W.png"> <img src="https://s-macke.github.io/VoxelSpace/images/thumbnails/D2.png"></p> <p><a href="https://s-macke.github.io/VoxelSpace/maps/C3.png">color</a>, <a href="https://s-macke.github.io/VoxelSpace/maps/D3.png">height</a></p> <p><img src="https://s-macke.github.io/VoxelSpace/images/thumbnails/C3.png"> <img src="https://s-macke.github.io/VoxelSpace/images/thumbnails/D3.png"></p> <p><a href="https://s-macke.github.io/VoxelSpace/maps/C4.png">color</a>, <a href="https://s-macke.github.io/VoxelSpace/maps/D4.png">height</a></p> <p><img src="https://s-macke.github.io/VoxelSpace/images/thumbnails/C4.png"> <img src="https://s-macke.github.io/VoxelSpace/images/thumbnails/D4.png"></p> <p><a href="https://s-macke.github.io/VoxelSpace/maps/C5W.png">color</a>, <a href="https://s-macke.github.io/VoxelSpace/maps/D5.png">height</a></p> <p><img src="https://s-macke.github.io/VoxelSpace/images/thumbnails/C5W.png"> <img src="https://s-macke.github.io/VoxelSpace/images/thumbnails/D5.png"></p> <p><a href="https://s-macke.github.io/VoxelSpace/maps/C6W.png">color</a>, <a href="https://s-macke.github.io/VoxelSpace/maps/D6.png">height</a></p> <p><img src="https://s-macke.github.io/VoxelSpace/images/thumbnails/C6W.png"> <img src="https://s-macke.github.io/VoxelSpace/images/thumbnails/D6.png"></p> <p><a href="https://s-macke.github.io/VoxelSpace/maps/C7W.png">color</a>, <a href="https://s-macke.github.io/VoxelSpace/maps/D7.png">height</a></p> <p><img src="https://s-macke.github.io/VoxelSpace/images/thumbnails/C7W.png"> <img src="https://s-macke.github.io/VoxelSpace/images/thumbnails/D7.png"></p> <p><a href="https://s-macke.github.io/VoxelSpace/maps/C8.png">color</a>, <a href="https://s-macke.github.io/VoxelSpace/maps/D6.png">height</a></p> <p><img src="https://s-macke.github.io/VoxelSpace/images/thumbnails/C8.png"> <img src="https://s-macke.github.io/VoxelSpace/images/thumbnails/D6.png"></p> <p><a href="https://s-macke.github.io/VoxelSpace/maps/C9W.png">color</a>, <a href="https://s-macke.github.io/VoxelSpace/maps/D9.png">height</a></p> <p><img src="https://s-macke.github.io/VoxelSpace/images/thumbnails/C9W.png"> <img src="https://s-macke.github.io/VoxelSpace/images/thumbnails/D9.png"></p> <p><a href="https://s-macke.github.io/VoxelSpace/maps/C10W.png">color</a>, <a href="https://s-macke.github.io/VoxelSpace/maps/D10.png">height</a></p> <p><img src="https://s-macke.github.io/VoxelSpace/images/thumbnails/C10W.png"> <img src="https://s-macke.github.io/VoxelSpace/images/thumbnails/D10.png"></p> <p><a href="https://s-macke.github.io/VoxelSpace/maps/C11W.png">color</a>, <a href="https://s-macke.github.io/VoxelSpace/maps/D11.png">height</a></p> <p><img src="https://s-macke.github.io/VoxelSpace/images/thumbnails/C11W.png"> <img src="https://s-macke.github.io/VoxelSpace/images/thumbnails/D11.png"></p> <p><a href="https://s-macke.github.io/VoxelSpace/maps/C12W.png">color</a>, <a href="https://s-macke.github.io/VoxelSpace/maps/D11.png">height</a></p> <p><img src="https://s-macke.github.io/VoxelSpace/images/thumbnails/C12W.png"> <img src="https://s-macke.github.io/VoxelSpace/images/thumbnails/D11.png"></p> <p><a href="https://s-macke.github.io/VoxelSpace/maps/C13.png">color</a>, <a href="https://s-macke.github.io/VoxelSpace/maps/D13.png">height</a></p> <p><img src="https://s-macke.github.io/VoxelSpace/images/thumbnails/C13.png"> <img src="https://s-macke.github.io/VoxelSpace/images/thumbnails/D13.png"></p> <p><a href="https://s-macke.github.io/VoxelSpace/maps/C14.png">color</a>, <a href="https://s-macke.github.io/VoxelSpace/maps/D14.png">height</a></p> <p><img src="https://s-macke.github.io/VoxelSpace/images/thumbnails/C14.png"> <img src="https://s-macke.github.io/VoxelSpace/images/thumbnails/D14.png"></p> <p><a href="https://s-macke.github.io/VoxelSpace/maps/C14W.png">color</a>, <a href="https://s-macke.github.io/VoxelSpace/maps/D14.png">height</a></p> <p><img src="https://s-macke.github.io/VoxelSpace/images/thumbnails/C14W.png"> <img src="https://s-macke.github.io/VoxelSpace/images/thumbnails/D14.png"></p> <p><a href="https://s-macke.github.io/VoxelSpace/maps/C15.png">color</a>, <a href="https://s-macke.github.io/VoxelSpace/maps/D15.png">height</a></p> <p><img src="https://s-macke.github.io/VoxelSpace/images/thumbnails/C15.png"> <img src="https://s-macke.github.io/VoxelSpace/images/thumbnails/D15.png"></p> <p><a href="https://s-macke.github.io/VoxelSpace/maps/C16W.png">color</a>, <a href="https://s-macke.github.io/VoxelSpace/maps/D16.png">height</a></p> <p><img src="https://s-macke.github.io/VoxelSpace/images/thumbnails/C16W.png"> <img src="https://s-macke.github.io/VoxelSpace/images/thumbnails/D16.png"></p> <p><a href="https://s-macke.github.io/VoxelSpace/maps/C17W.png">color</a>, <a href="https://s-macke.github.io/VoxelSpace/maps/D17.png">height</a></p> <p><img src="https://s-macke.github.io/VoxelSpace/images/thumbnails/C17W.png"> <img src="https://s-macke.github.io/VoxelSpace/images/thumbnails/D17.png"></p> <p><a href="https://s-macke.github.io/VoxelSpace/maps/C18W.png">color</a>, <a href="https://s-macke.github.io/VoxelSpace/maps/D18.png">height</a></p> <p><img src="https://s-macke.github.io/VoxelSpace/images/thumbnails/C18W.png"> <img src="https://s-macke.github.io/VoxelSpace/images/thumbnails/D18.png"></p> <p><a href="https://s-macke.github.io/VoxelSpace/maps/C19W.png">color</a>, <a href="https://s-macke.github.io/VoxelSpace/maps/D19.png">height</a></p> <p><img src="https://s-macke.github.io/VoxelSpace/images/thumbnails/C19W.png"> <img src="https://s-macke.github.io/VoxelSpace/images/thumbnails/D19.png"></p> <p><a href="https://s-macke.github.io/VoxelSpace/maps/C20W.png">color</a>, <a href="https://s-macke.github.io/VoxelSpace/maps/D20.png">height</a></p> <p><img src="https://s-macke.github.io/VoxelSpace/images/thumbnails/C20W.png"> <img src="https://s-macke.github.io/VoxelSpace/images/thumbnails/D20.png"></p> <p><a href="https://s-macke.github.io/VoxelSpace/maps/C21.png">color</a>, <a href="https://s-macke.github.io/VoxelSpace/maps/D21.png">height</a></p> <p><img src="https://s-macke.github.io/VoxelSpace/images/thumbnails/C21.png"> <img src="https://s-macke.github.io/VoxelSpace/images/thumbnails/D21.png"></p> <p><a href="https://s-macke.github.io/VoxelSpace/maps/C22W.png">color</a>, <a href="https://s-macke.github.io/VoxelSpace/maps/D22.png">height</a></p> <p><img src="https://s-macke.github.io/VoxelSpace/images/thumbnails/C22W.png"> <img src="https://s-macke.github.io/VoxelSpace/images/thumbnails/D22.png"></p> <p><a href="https://s-macke.github.io/VoxelSpace/maps/C23W.png">color</a>, <a href="https://s-macke.github.io/VoxelSpace/maps/D21.png">height</a></p> <p><img src="https://s-macke.github.io/VoxelSpace/images/thumbnails/C23W.png"> <img src="https://s-macke.github.io/VoxelSpace/images/thumbnails/D21.png"></p> <p><a href="https://s-macke.github.io/VoxelSpace/maps/C24W.png">color</a>, <a href="https://s-macke.github.io/VoxelSpace/maps/D24.png">height</a></p> <p><img src="https://s-macke.github.io/VoxelSpace/images/thumbnails/C24W.png"> <img src="https://s-macke.github.io/VoxelSpace/images/thumbnails/D24.png"></p> <p><a href="https://s-macke.github.io/VoxelSpace/maps/C25W.png">color</a>, <a href="https://s-macke.github.io/VoxelSpace/maps/D25.png">height</a></p> <p><img src="https://s-macke.github.io/VoxelSpace/images/thumbnails/C25W.png"> <img src="https://s-macke.github.io/VoxelSpace/images/thumbnails/D25.png"></p> <p><a href="https://s-macke.github.io/VoxelSpace/maps/C26W.png">color</a>, <a href="https://s-macke.github.io/VoxelSpace/maps/D18.png">height</a></p> <p><img src="https://s-macke.github.io/VoxelSpace/images/thumbnails/C26W.png"> <img src="https://s-macke.github.io/VoxelSpace/images/thumbnails/D18.png"></p> <p><a href="https://s-macke.github.io/VoxelSpace/maps/C27W.png">color</a>, <a href="https://s-macke.github.io/VoxelSpace/maps/D15.png">height</a></p> <p><img src="https://s-macke.github.io/VoxelSpace/images/thumbnails/C27W.png"> <img src="https://s-macke.github.io/VoxelSpace/images/thumbnails/D15.png"></p> <p><a href="https://s-macke.github.io/VoxelSpace/maps/C28W.png">color</a>, <a href="https://s-macke.github.io/VoxelSpace/maps/D25.png">height</a></p> <p><img src="https://s-macke.github.io/VoxelSpace/images/thumbnails/C28W.png"> <img src="https://s-macke.github.io/VoxelSpace/images/thumbnails/D25.png"></p> <p><a href="https://s-macke.github.io/VoxelSpace/maps/C29W.png">color</a>, <a href="https://s-macke.github.io/VoxelSpace/maps/D16.png">height</a></p> <p><img src="https://s-macke.github.io/VoxelSpace/images/thumbnails/C29W.png"> <img src="https://s-macke.github.io/VoxelSpace/images/thumbnails/D16.png"></p> <h2>License</h2> <p>The software part of the repository is under the MIT license. Please read the license file for more information. Please keep in mind, that the Voxel Space technology might be still <a href="https://patents.justia.com/assignee/novalogic-inc">patented</a> in some countries. The color and height maps are reverse engineered from the game Comanche and are therefore excluded from the license.</p> <div> This site is open source. <a href="https://github.com/s-macke/VoxelSpace/edit/gh-pages/README.md">Improve this page</a>. </div> </div> https://www.lloydslist.com/LL1157327/Hormuz-crisis-side-effect-a-sharp-rise-in-container-shipping-ratesSat, 30 May 2026 18:19:23 +0000https://news.ycombinator.com/item?id=48339180<a href="https://news.ycombinator.com/item?id=48339180">Comments</a><div class="article-body-content" morss_own_score="5.762295081967213" morss_score="19.214386336720064"> <h1>Hormuz crisis side effect: a sharp rise in container shipping rates</h1> <h3><ul> <li>SCFI global composite index has doubled since the war with Iran began and is at its highest point since September 2024, during the Red Sea crisis</li> <li>Bunker fuel costs have jumped by almost 70% and container lines are successfully passing incremental costs along to shippers</li> <li>Shanghai-Los Angeles spot rates are up 59% vs late February, with Shanghai-New York rates up 66%, according to Drewry assessments</li> </ul></h3> <ul> <li> <time>29 May 2026</time> </li> <li> <h6>Analysis</h6> </li> </ul> <p>Spot container freight rates continue their ascent as ocean carriers pass along much higher fuel costs resulting from the effective closure of the Strait of Hormuz. If the strait doesn’t reopen soon, the impact on container market could intensify</p> <aside> <span> FREE TO READ</span> <img src="https://www.lloydslist.com/-/media/lloyds-list/images/containers/2026-new-pictures/msc-zoe-in-piraeus-by-adobe.png?rev=0784eabe25ea4a59bcff9adf942f9386&amp;w=790&amp;hash=DD3DD28E0D7803149198A0C166D55DDC"> <span> Source: aerial-drone - stock.adobe.com </span> <span>Asia-Med rates are still rising. Pictured: MSC Zoe in Piraeus.</span> </aside> <div class="root" morss_own_score="2.9041825095057034" morss_score="141.35755262879687"> <p>IMPORTERS of containerised goods around the globe are paying more for their ocean transport as a result of the Hormuz crisis. </p> <p>In yet another side effect of the Middle East war, container lines are successfully passing along fuel costs inflated by the effective closure of the Strait of Hormuz. </p> <p>The Shanghai Containerized Freight Index global composite rose to 2,572 points in the week ending Friday, up 16% from the week before. It is now double its level in late February, just before the US and Israel attacked Iran. </p> <p>This week’s SCFI global composite reading was the highest since the week of September 6, 2024, during the Red Sea crisis.</p>   <p><strong>Impact of higher bunker fuel costs</strong></p> <p>“Geopolitical tensions in the Middle East are weighing on sentiment, with elevated bunker costs and fuel surcharges adding upward pressure across trade lanes,” said Drewry.</p> <p><a href="https://www.seasearcher.com/company/10498/overview">Maersk</a> chief executive Vincent Clerc said in a conference call that his company is paying around $500m per month in extra fuel costs due to the Hormuz crisis “that we must find a way to pass through”.</p> <p><a href="https://www.seasearcher.com/company/6720/overview">Hapag-Lloyd</a> chief executive Rolf Habben Jansen said that his company is paying €50m-€60m extra per week ($250m-$300m per month) and “rate increases have been roughly in line with the cost increase we have faced”.</p> <p>When importers pay more for ocean freight, it is the same as “when you go to the petrol station and you have to pay a higher price”, said Habben Jansen.</p> <p>Pass-along fuel costs may also be affecting peak season timing, further boosting spot rates.</p> <p>“Demand is being pulled forward into June ahead of the expected July 1 bunker fuel adjustments, supporting stronger shipment flows,” said Drewry, citing “early peak season” trends in both the transpacific and Asia-Europe trades.</p> <p>The average price of very low sulphur fuel at the top 20 bunkering hubs was $856 per tonne on Thursday, up 68% from mid-February, according to data from Ship &amp; Bunker. </p> <p>The average price of high sulphur fuel oil was $736.50 per tonne on Thursday, up 66% versus mid-February.</p>   <p>VLSFO pricing moves in line with Brent crude. The Brent price would decline if there is a peace agreement between the US and Iran, or surge if the Strait of Hormuz remains effectively closed for longer.</p> <p>Neil Chapman, senior vice president of <a href="https://www.seasearcher.com/company/5155/overview">ExxonMobil</a>, issued <a href="https://www.lloydslist.com/LL1157316/Crude-price-spike-from-Hormuz-crisis-is-approaching-warns-ExxonMobil-exec">a blunt public warning on Thursday</a>, asserting that the dated Brent price could spike to $150-$160 per barrel if the strait doesn’t reopen in the next few weeks.</p> <p>If Brent goes higher, bunker costs — and shipper fuel surcharges — would also rise.</p> <p><strong>Disruption helps offset capacity overhang</strong></p> <p>The good news for carriers is that, so far, they have been able to offset fuel costs despite an ongoing flood of newbuilding capacity. </p> <p>Their ability to do so relates, in part, to the Hormuz crisis. </p> <p>Liners’ continued aversion to the Red Sea route amid the war in the Middle East reduces effective capacity by 12%, said Constatin Baack, chief executive of boxship lessor <a href="https://www.seasearcher.com/company/494712/overview">MPC Container Ships</a>, on a quarterly call on Wednesday.</p> <p>Slow steaming due to higher bunker costs has absorbed another 2% of capacity. “With energy prices up sharply, carriers have throttled back fleet speeds,” Baack said.</p> <p>Port congestion takes out another 5% of capacity, bringing the total reduction of effective capacity to 19%.</p> <p>“On paper, supply and demand have been diverging since 2023. The market should be trending toward oversupply,” said Baack. “In reality, rates have been increasing.” </p> <p>According to Peter Sand, chief analyst at Xeneta, “Carriers entered the year facing a potential market collapse as services [were expected to return] to the Red Sea, but have ultimately found themselves able to charge higher and higher rates to shippers across the market.”</p> <p><strong>Asia-Europe spot rates</strong></p> <p>Different spot index providers use different methodologies and come up with different rate assessments, but they all show the same directional trend.</p> <p>The SCFI <a href="https://www.seasearcher.com/place/11182/overview">Shanghai</a>-Mediterranean index was at $7,500 per feu this week, up 63% versus the last week of February, just before the war began. It was the index’s highest reading since January 2025.</p> <p>Drewry’s World Container Index assessed the Shanghai-<a href="https://www.seasearcher.com/place/15521/overview">Genoa</a> spot rate at $4,253 per feu, up 50% versus late February. </p> <p>Xeneta’s daily assessment of average short-term rates on the Asia-Med route was $4,326 per feu on Thursday, up 30% compared to pre-war levels.</p>   <p>The SCFI’s Shanghai-North Europe index was at $4,949 per feu this week, up 74% versus late February to its highest point since January 2025.</p> <p>The WCI Shanghai-<a href="https://www.seasearcher.com/place/1830/overview">Rotterdam</a> index was at $2,861 per feu, up 37% since before the war, and Xeneta’s Asia-North Europe assessment was at $2,880 per feu, up 30%.</p> <p>“As the early peak season approaches and carriers continue to raise FAK rates, we expect rates to rise further in the coming weeks,” said Drewry.</p> <p><strong>Transpacific spot rates</strong></p> <p>US importers are now dealing with two policy decisions of US President Donald Trump: the attack on Iran and tariffs.</p> <p>US importers continue to face steep tariff bills on top of rising freight costs due to fuel, even after the Supreme Court ruled against Trump’s emergency tariffs in February.</p> <p>According to the Budget Lab at Yale, the current average tariff rate paid by US importers is 11.8%, the highest since the 1940s, excluding 2025. That is almost six times the 2% average at the beginning of Trump’s second term.</p> <p>Nevertheless, US import demand remains resilient, supporting recent spot rate gains by carriers.</p> <p>The SCFI Shanghai-US west coast index was at $4,149 per feu this week, up 129% versus late February. The SCFI Shanghai-US east coast index was at $5,333 per feu, up 100%.</p> <p>A year ago, Asia-US spot rates were even higher, as that was the period when Trump gave a temporary tariff reprieve, allowing US importers to frontload.</p>   <p>The WCI assessed Shanghai-<a href="https://www.seasearcher.com/place/14977/overview">Los Angeles</a> rates at $3,473 per feu this week, up 59% from late February, and Shanghai-<a href="https://www.seasearcher.com/place/14572/overview">New York</a> rates at $4,597 per feu, up 66%.</p> <p>“With early peak-season trends emerging and seasonal demand strengthening through June, we expect further upward pressure on [transpacific] rates,” said Drewry.</p> <p>Xeneta’s assessment of average Asia-US west coast spot rates came in at $3,624 per feu on Thursday, up 74% versus late February. Xeneta’s Asia-US east coast assessment was $4,367 per feu, up 65%.</p> <p>“There is no hiding place from this market turmoil,” said Sand. </p> <p>“The June increases on the transpacific were driven mainly by the market mid-low [the midpoint between the low and the average], which are the rates generally paid by the larger-volume shippers who command greater negotiating power.”</p> </div> </div>