https://bal-e.org/blog/arya dradjicahttps://bal-e.org/jcue8qere0vasrv0@bal-e.org2026-09-05T00:00:00ZCopyright (c) 2026 arya dradjicahttps://bal-e.org/speed/krabby/2026/query-system-design/2026-08-03T00:00:00Z2026-08-03T00:00:00Z

From the start of this year, I have slowly been going about designing a query system for Krabby. It took five months of sitting still and thinking really hard, but I believe I have a clear grasp of the design now. I'm going to explain why Krabby needs a query system (because I thought it wouldn't for a while), the special features I wanted, and how everything fits together.

https://bal-e.org/speed/krabby/2026/rustnl-internship/2026-07-10T00:00:00Z2026-07-10T00:00:00Z

I'm ecstatic to announce that, from July 22, I will be paid to work on rustc and Krabby for one day a week. This is an internship at RustNL (as part of The Rust Maintainers Team) enabled by my employer NLnet Labs, which will last up to a year. I'm immensely grateful to everyone involved in making this happen! In this post, I'm going to lay out how I will spend this time.

https://bal-e.org/blog/2026/offset-of-slices/2026-06-18T00:00:00Z2026-06-27T00:00:00Z

std::mem::offset_of! is a helpful little macro that lets you compute the offset of a particular field of a struct at compile time. I haven't had much use for it myself, but a friend has been using it for a cool JIT'ed scripting language for Rust, so it's come up occasionally.It has a few quirks, though: you can't use it for unsized fields (e.g. b in Foo { a: u8, b: [u8] }). This isn't too common, but if you're doing weird enough things that you need to compute byte offsets of fields, you are probably familiar with (and happy to (ab)use) dynamically sized types. Like all frustrating things, there's a reason beneath the surface: in Rust, types that implement Sized have a fixed size and alignment, while others do not. With a type like Bar { a: u8, b: dyn Debug }, b could have an arbitrary type, thus an arbitrary alignment, thus an arbitrary offset.

https://bal-e.org/blog/2026/verifying-proc/2026-06-07T00:00:00Z2026-06-07T00:00:00Z

I think it's fairly obvious that I'm a perfectionist. Sometimes that drags me into the land of Linux system APIs — I once wrote a 300 line C program to replace the classic "run date every 60 seconds" loop you might find in your status bar. My goal was to use all the cool system calls I could find, be as efficient as possible, and update the date exactly on time. It was a lot of fun! I ran into a similar rabbit hole while trying to build a file system watcher, and the results were cool enough to deserve their own blog post.

https://bal-e.org/speed/krabby/2026/omitting-spans/2026-05-30T00:00:00Z2026-06-04T00:00:00Z

I have a large backlog of posts to write, but I quickly wanted to share a fun idea I explored on Thursday. I've been thinking about how incremental compilation should work in Krabby, and a major sticking point there is spans. But I think I have a plan.

https://bal-e.org/blog/2026/modeling/2026-05-25T00:00:00Z2026-05-25T00:00:00Z

Venting about the state of the world, in the shape of a poem.

https://bal-e.org/speed/krabby/2026/parsing-in-2025/2026-05-24T00:00:00Z2026-05-24T00:00:00Z

To recap: it's November 2025 and I've spent the last two-ish months working on identifier interning. My plans to implement name resolution by the end of the year were screwed, but I still wanted to spend substantial time on it.To be honest, I think my foray into identifier interning was really to avoid implementing parsing. Parsing is just really, really hard. The Rust syntax is deeply complicated, it varies (in subtle ways) across editions, and you need to design an AST to parse into. I had already put a lot of effort into designing my own token stream format, which meant I couldn't use existing parsers.

https://bal-e.org/blog/2026/oops-cubic-macro/2026-05-03T00:00:00Z2026-05-11T00:00:00Z

Last week, I happened to glance at the codebase for rust-analyzer. I realized that r-a and Krabby (my very-very-WIP Rust compiler) have a lot in common; r-a re-implements a lot of rustc and has benchmarks and tests to compare it to rustc. While Krabby has different high-level goals, it needs exactly the same infrastructure.One component that stuck out to me was macro expansion. I've previously heard that r-a puts a lot of effort into macro expansion, partly to offer interesting LSP functionality (e.g. "expand this macro") and partly because macros complicate normal LSP functionality (e.g. "goto definition", if the definition is generated by a macro). While r-a sometimes re-uses code from rustc, a quick peek around the codebase revealed that most of r-a's macro handling code is written from scratch. It also appears to be much simpler; I'm not sure whether that's because it has been written more concisely (with hindsight from rustc), because it is less concerned with diagnostics, or because it differs from rustc in some edge cases.

https://bal-e.org/speed/krabby/2026/interning-in-2025/2026-04-20T00:00:00Z2026-04-20T00:00:00Z

Name resolution requires storing lots of identifiers and comparing them to each other very rapidly. While you could store identifiers as Strings and compare them using basic string equality, this is quite inefficient. A nearly universal approach is interning — assigning every identifier a unique numeric ID, and representing and comparing them by ID. Interning uses a hash table to deduplicate identifiers and ensure that distinct IDs refer to distinct identifiers.

https://bal-e.org/speed/krabby/2026/a-year/2026-04-12T00:00:00Z2026-04-20T00:00:00Z

Precisely one year and one week ago, on April 05, 2025, I introduced Krabby. It all started because I had too many ideas about compiler architecture and they stopped fitting in my head. Ever since, Krabby has been the primary focus of my spare time. It's my favorite thing to do; I'm incredibly grateful to have the time for it, and I'm incredibly proud of what I've achieved.

https://bal-e.org/speed/krabby/2026/hi-zulip-also-licenses/2026-04-11T00:00:00Z2026-04-11T00:00:00Z

Krabby appeared on Lobste.rs last week, and I've since received e-mails from people interested in contributing! I've created a Zulip chat for discussions; feel free to join it whether you want to observe what's happening or participate yourself. If you're interested but unsure what you can help with, perhaps take a look at the list of open issues.Some of those e-mails asked whether Krabby is still being actively developed. I will strongly affirm that; yes, Krabby continues, and I'm as motivated as ever (if not more now!). While it's still incredibly limited in functionality, I have a lot of plans, and I'm really excited. Let me give you a quick status update.

https://bal-e.org/blog/2026/making-nice-things/2026-02-26T00:00:00Z2026-02-26T00:00:00Z

I wake up on time to a quiet morning before dawn. I move through the steps of my daily routines, picking out my clothes and throwing open the curtains. I stare out to the gradual morning light, listening for birdsong. As I set myself some breakfast, I contemplate what I will do with the two hours before I start work: programming a concurrent memory reclaimer.While the project has sat in my head for a while, I started writing the API and implementation yesterday. I trace the branches of the dimly-lit trees on my window, and I remember how astonishingly simple the code seems. I think about the underlying ring buffer, its structure as delicate as the little basil plant I am watering. I think about supporting MIRI and loom. I smile as I remember how proud I am of the name I picked – housekeeping. I think about the projects I need it for, and where they will lead. And I return to a familiar feeling, the throughline of all my work: the utter joy of and drive for making nice things.

https://bal-e.org/blog/2026/see-you-at-rustweek/2026-02-17T00:00:00Z2026-02-17T00:00:00Z

I'm incredibly excited to announce that I'll be giving a talk at RustWeek 2026! On May 20, I'll talk about phonebook, my attempt to build the fastest identifier interner possible. My goal is to explain my process of optimization, particularly at a low level, and to show how fun it can be. I hope to give you the tools, knowledge, and inspiration to try optimizing your own projects in the same way.

https://bal-e.org/blog/2025/website-overhaul/2025-11-27T00:00:00Z2025-11-27T00:00:00Z

As of yesterday, my website looks a little different. I added a navigation bar to every page and polished the visuals. But that was the trivial bit — in the background, I completely overhauled the website infrastructure. This blog is now powered by Typst! If you manage your website like me, you might find my new approach interesting.

https://bal-e.org/speed/krabby/2025/takeaway/2025-08-11T00:00:00Z2025-08-11T00:00:00Z

I've written a work-stealing task queue system for high-performance, CPU-bound applications, called takeaway. It provides an intuitive high-level API and its internal architecture allows it to provide some unique features. I wrote it because the only popular work-stealing library for Rust, crossbeam-deque, does not support task prioritization, a feature I need for my very-very-WIP Rust compiler (krabby).It's taken 2 months of work, but I'm really happy with the current state of takeaway. I've released v0.1.0 as the first "stable" release; I expect to make some (minor) breaking changes in the future, but I think it's ready for public use. If you're writing a high-performance, task-based application like me, please check it out! It offers competitive (and often better) performance than crossbeam-deque, with a nicer API and more features. Over here, I'm going to expand on takeaway's design and the process of implementing it.

https://bal-e.org/speed/krabby/2025/for-context/2025-06-01T00:00:00Z2025-06-01T00:00:00Z

Continuing on from the proof of concept, I'm making good progress on Krabby! There are three major steps I've accomplished in the last two weeks: a faster TOML parser, a custom lexer, and most importantly, the completion of the task architecture. I will need all of this infrastructure before I can tackle name resolution, and it's coming together very well.

https://bal-e.org/speed/krabby/2025/proof-of-concept/2025-05-17T00:00:00Z2025-05-17T00:00:00Z

This week has been incredibly productive. I was one of the volunteers for RustWeek, which was a massive event with ~800 attendants and the first All-Hands (gathering of all Rust contributors) in over 6 years. I met so many amazing figures in the Rust community, and I had really interesting conversations with them about compiler performance and Krabby. I'm incredibly gratified to have received confirmation that I'm on the right track with this work, and I'm incredibly excited to see where I can take Krabby in the future.

https://bal-e.org/speed/krabby/2025/the-architecture/2025-04-27T00:00:00Z2025-04-27T00:00:00Z

I felt a bit stuck this week. While I have developed an interesting AST to experiment on, going any further with it is difficult. The next major step is name resolution, and that will require the ASTs of different files to interact with each other. My current testing / benchmarking setup, while good for executing things per file, can't deal with that. Now that I know these memory layout techniques will be effective, I decided to start over with a focus on krabby's high-level architecture.

https://bal-e.org/speed/krabby/2025/making-an-ast/2025-04-19T00:00:00Z2025-04-19T00:00:00Z

In my previous post about krabby, I made a "scope tree" data structure with which I performed local name resolution. It was incredibly efficient compared to syn's AST, but I wanted a more realistic comparison of this memory layout style to syn. So I spent most of this week building a whole AST from scratch.

https://bal-e.org/speed/krabby/2025/trying-out-parent-ptrs/2025-04-12T00:00:00Z2025-04-12T00:00:00Z

I was planning to write a post about the overall architecture I envision for krabby, but there are some complicated bits (regarding macro expansion) that don't feel resolved yet. Maybe that'll come next week.In the meantime, I decided to tackle the first non-trivial (but relatively simple) compilation stage I could think of: local name resolution. This doesn't try to resolve imports or references to items (e.g. functions), but rather only the variables defined within a function body. While my code certainly isn't perfect, it was a great experiment, and it's helped me figure out parts of the compiler infrastructure that will be crucial as we go on.

https://bal-e.org/speed/krabby/2025/motivations/2025-04-05T00:00:00Z2025-04-05T00:00:00Z

A couple of friends got together and, waddaya know, a new programming language project was born. We have no idea where it's going, or how feasible it is, but we're all pretty excited. We wanted to see where we could go from Rust, and there's some pretty wild ideas being thrown about. It's really fun!

https://bal-e.org/crypto/keeping-secrets/2024-09-21T00:00:00Z2024-09-21T00:00:00Z

My online identity comprises a number of accounts spread across dozens of websites and systems. They have different means of identity (e.g. usernames and e-mail addresses) and different modes of authentication (2FA, PIN codes, SSH keys, and traditional passwords). I've been using the pass tool to store the passwords for these. It's a simple tool that follows the UNIX philosophy, storing every password in a separate GPG-encrypted file. It's easy to understand and work with, and it comes with a number of useful integrations. However, I've been concerned about the fact that it doesn't protect usernames or e-mail addresses—if an attacker can observe the password store, they can locate my accounts.

https://bal-e.org/crypto/uniqueness/2024-08-31T00:00:00Z2024-09-08T00:00:00Z

Daniel J. Bernstein has created a vast number of high-quality cryptographic primitives that have been accepted as state of the art, especially in pre-quantum cryptography. I was reading about the Ed25519 signature scheme when I noticed something interesting.Ed25519 relies on a per-signature secret nonce, which is deterministically derived from the signer's key and the message being signed. The rationale for not using a randomly generated nonce is that any collision (the signing of two different messages with the same nonce) will immediately reveal the secret key and compromise the system. Rather than trying to avoid this property, I'd like to examine it as a feature: there is at most one message for every nonce.

https://bal-e.org/blog/2024/i-am-/2024-07-27T00:00:00Z2024-07-27T00:00:00Z

Those three words are so hard to say.I remember the first time. My heart was pounding so hard, I couldn't hear her talking. I mumbled something about needing to tell her something important. I have no doubt she could hear the fear in my voice. I was looking down at my lap because I didn't want her to see the terror in my eyes too."I am—"

https://bal-e.org/blog/2023/true-macro-recursion/2023-04-26T00:00:00Z2023-04-26T00:00:00Z

Macros are a very useful feature of the C preprocessor for reducing boilerplate. It is well known that they have limited processing power; most importantly, they cannot recurse, and cannot iterate over lists. Libraries for meta-programming (e.g. Boost.Preprocessor and metalang99) work around this, but are only capable of executing a limited number of iterations, and have complex implementations. However, an obscure GCC feature can be abused to allow for "true" recursion in macros in a relatively elegant manner, allowing more complex and useful macros to be implemented.