Fast and Hard Code

Armin Ronacher News

Summary

The article discusses how LLMs are reducing friction in programming language choice, leading developers to adopt performance-oriented languages like Rust and Zig for fast, small software and enabling work with complex technologies previously considered difficult.

<p>One of the memes on Twitter is that &#8220;programming is solved now.&#8221; I&#8217;m not sure to what degree it is, but one thing is pretty clear: the act of familiarizing yourself with a language no longer matters and some of the friction that mattered for humans does not matter for agents.</p> <p>As a result, LLMs make language choice much less consequential than it used to be. If you don&#8217;t like the choice, you can seemingly rewrite it in another language and you can make it pick a language that you, as a programmer, are entirely unfamiliar with.</p> <p>Which in turn means that people can, and do, choose based on the marketing of languages much more. As a long-term Rust programmer I found it quite fascinating to see people now ship Rust code who previously might not have chosen it. I attribute at least one part of this to two recent vibe shifts: there is a lot more talk about wanting fast software, and about LLMs being exceptional at optimizing code without regressing behavior.</p> <p>Folks like Mitchell Hashimoto, Charlie Marsh, Jarred Sumner, Daniel Lemire and quite a few others always carried a certain level of obsession with fast and performant software and they also all happen to be receptive to agents writing code. Maybe as a result, or unrelated others are now joining in. That&#8217;s because with things like <a href="https://github.com/davebcn87/pi-autoresearch">autoresearch</a> you don&#8217;t even necessarily need to know all the tricks: you just need to put an agent on it — though knowledge greatly helps!</p> <p>If you look around, there are plenty of projects that want to be fast and small, and they increasingly pick &#8220;hard languages&#8221;. And it&#8217;s not just Rust that is benefiting. Even Zig — despite the fact that the creators and parts of the core community are pretty negative on the whole AI thing — is too. For instance Cloudflare&#8217;s new <a href="https://blog.cloudflare.com/artifacts-git-for-agents-beta/">Artifacts</a> service uses a pure-Zig Git-protocol engine, compiled to a roughly 100 KB WebAssembly module and Vercel released <a href="https://github.com/vercel-labs/fx">fx</a>, a Zig coding agent advertised to be small and fast. From what I can tell, all these projects are largely LLM-assisted.</p> <p>But it&#8217;s not just people picking less common languages but also that they are increasingly working with &#8220;much harder&#8221; technologies. All of a sudden I have seen people do some really impressive stuff with DWARF files, eBPF, custom network drivers, custom crypto and really old computing hardware. Many of these things were previously off-limits for lots of developers. In some cases (eg: crypto) you were even pushed away because those things were intentionally gatekept by the people in the know.</p> <p>So maybe the world will have more slop, but it might also have more developers in it, that want things to be fast and small.</p>
Original Article
View Cached Full Text

Cached at: 08/23/26, 03:38 AM

# Fast and Hard Code Source: [https://lucumr.pocoo.org/2026/8/22/fast-hard-code/](https://lucumr.pocoo.org/2026/8/22/fast-hard-code/) written on August 22, 2026 One of the memes on Twitter is that “programming is solved now\.” I’m not sure to what degree it is, but one thing is pretty clear: the act of familiarizing yourself with a language no longer matters and some of the friction that mattered for humans does not matter for agents\. As a result, LLMs make language choice much less consequential than it used to be\. If you don’t like the choice, you can seemingly rewrite it in another language and you can make it pick a language that you, as a programmer, are entirely unfamiliar with\. Which in turn means that people can, and do, choose based on the marketing of languages much more\. As a long\-term Rust programmer I found it quite fascinating to see people now ship Rust code who previously might not have chosen it\. I attribute at least one part of this to two recent vibe shifts: there is a lot more talk about wanting fast software, and about LLMs being exceptional at optimizing code without regressing behavior\. Folks like Mitchell Hashimoto, Charlie Marsh, Jarred Sumner, Daniel Lemire and quite a few others always carried a certain level of obsession with fast and performant software and they also all happen to be receptive to agents writing code\. Maybe as a result, or unrelated others are now joining in\. That’s because with things like[autoresearch](https://github.com/davebcn87/pi-autoresearch)you don’t even necessarily need to know all the tricks: you just need to put an agent on it — though knowledge greatly helps\! If you look around, there are plenty of projects that want to be fast and small, and they increasingly pick “hard languages”\. And it’s not just Rust that is benefiting\. Even Zig — despite the fact that the creators and parts of the core community are pretty negative on the whole AI thing — is too\. For instance Cloudflare’s new[Artifacts](https://blog.cloudflare.com/artifacts-git-for-agents-beta/)service uses a pure\-Zig Git\-protocol engine, compiled to a roughly 100 KB WebAssembly module and Vercel released[fx](https://github.com/vercel-labs/fx), a Zig coding agent advertised to be small and fast\. From what I can tell, all these projects are largely LLM\-assisted\. But it’s not just people picking less common languages but also that they are increasingly working with “much harder” technologies\. All of a sudden I have seen people do some really impressive stuff with DWARF files, eBPF, custom network drivers, custom crypto and really old computing hardware\. Many of these things were previously off\-limits for lots of developers\. In some cases \(eg: crypto\) you were even pushed away because those things were intentionally gatekept by the people in the know\. So maybe the world will have more slop, but it might also have more developers in it, that want things to be fast and small\. This entry was tagged[ai](https://lucumr.pocoo.org/tags/ai/),[programming](https://lucumr.pocoo.org/tags/programming/)and[thoughts](https://lucumr.pocoo.org/tags/thoughts/) [copy as](https://lucumr.pocoo.org/2026/8/22/fast-hard-code.md)/[view](https://lucumr.pocoo.org/2026/8/22/fast-hard-code.md)markdown

Similar Articles

There's no reason for software to be slow anymore

Hacker News Top

The article argues that LLMs and AI tools are lowering the barrier for software performance optimizations, enabling custom adaptations like JIT compilers and regex engines that were previously too costly to implement.

2x, not 10x: coding with LLMs in 2026

Hacker News Top

The author argues that LLMs currently provide about a 2x productivity boost for coding due to their ability to handle easily verifiable tasks, but fundamental limitations prevent a 10x improvement; further gains will come from retooling around existing capabilities rather than model improvements.

JIT Compiling Code in 5μs

Hacker News Top

The article discusses how AI assistance has simplified the creation of fast JIT compilers with sub-microsecond compile times, demonstrated through a Rust-based regular expression engine example.

Writing a Fast Compiler

Lobsters Hottest

The article describes various tricks and strategies for writing fast compilers, focusing on minimizing code execution, reducing memory usage, and optimizing common paths to achieve compilation speeds of over 500,000 lines of code per second.

Use Boring Languages with LLMs

Hacker News Top

An opinion piece arguing that LLMs perform better with boring, consistent languages and ecosystems (like Ruby on Rails) because the training corpus has lower variance, leading to more reliable agentic output, while fragmented ecosystems (like JavaScript) produce poor results.