arya dradjica’s blog

updated September 04, 2026

I like writing about the work I’m doing and the crazy ideas I have. Most of the material is already organized by topic, but this page provides an index of posts organized by date. You can follow along via the Atom feed.

designing a query system

on August 03, 2026; by arya dradjica

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.

the RustNL internship

on July 10, 2026; by arya dradjica

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.

`offset_of!` slices

on June 18, 2026; by arya dradjica

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.

verifying `/proc`

on June 07, 2026; by arya dradjica

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.

omitting spans

on May 30, 2026; by arya dradjica

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.

modeling

on May 25, 2026; by arya dradjica

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

parsing in 2025

on May 24, 2026; by arya dradjica

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.

oops, cubic exponential macro!

on May 03, 2026; by arya dradjica

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.

identifier interning in 2025

on April 20, 2026; by arya dradjica

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.

a year of krabby

on April 12, 2026; by arya dradjica

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.

hi zulip! also, licenses

on April 11, 2026; by arya dradjica

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.

making nice things

on February 26, 2026; by arya dradjica

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.

see you at rustweek!

on February 17, 2026; by arya dradjica

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.

overhauling my website

on November 27, 2025; by arya dradjica

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.

introducing `takeaway`

on August 11, 2025; by arya dradjica

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.

for context

on June 01, 2025; by arya dradjica

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.

a proof of concept

on May 17, 2025; by arya dradjica

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.

the architecture

on April 27, 2025; by arya dradjica

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.

making an AST

on April 19, 2025; by arya dradjica

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.

trying out parent ptrs

on April 12, 2025; by arya dradjica

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.

krabby: motivations

on April 05, 2025; by arya dradjica

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!

keeping secrets

on September 21, 2024; by arya dradjica

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.

playing with uniqueness

on August 31, 2024; by arya dradjica

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.

I am—

on July 27, 2024; by arya dradjica

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—”

true macro recursion in C

on April 26, 2023; by arya dradjica

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.