Zig is better than C. And that’s great — until you try to debug it.

If you’ve ever dropped into LLDB while debugging Zig, you already know the pain: slices look like random structs, optionals are unreadable, error unions feel hostile, and expressions like slice[0] just… don’t work.

This post introduces zdb, an LLDB plugin that makes debugging Zig feel normal — without rebuilding LLDB or messing with Python scripts.

The Problem

Here’s a simple Zig program (from test/test_types.zig in the zdb repo):

const std = @import("std");

const Color = enum { red, green, blue, yellow };

const TestStruct = struct {
    name: []const u8,
    values: []i32,
    optional_value: ?i32,
    error_result: MyError!i32,
    shape: Shape,
};

pub fn main() !void {
    var gpa = std.heap.GeneralPurposeAllocator(.{}){};
    defer _ = gpa.deinit();
    const allocator = gpa.allocator();

    // Test slices
    const string_slice: []const u8 = "Hello, zdb debugger!";
    const int_slice: []const i32 = &[_]i32{ 1, 2, 3, 4, 5 };

    // Test optionals
    const some_value: ?i32 = 42;

    // Test std library
    var list: std.ArrayListUnmanaged(i32) = .empty;
    try list.appendSlice(allocator, &.{ 10, 20, 30 });

    std.debug.print("Breakpoint here!\n", .{});  // breakpoint here
}

Now stop at the breakpoint and inspect things in stock LLDB:

(lldb) frame variable string_slice int_slice color test_struct list
([]u8) string_slice = (ptr = "Hello, zdb debugger!", len = 20)
([]i32) int_slice = {
  ptr = 0x00000001000da244
  len = 5
}
(test_types.Color) color = blue
(test_types.TestStruct) test_struct = {
  name = (ptr = "test object", len = 11)
  values = {
    ptr = 0x000000016fdfe588
    len = 3
  }
  optional_value = (data = 42, some = '\x01')
  error_result = (value = 100, tag = 0)
  shape = {
    payload = { ... }
    tag = circle
  }
}
(array_list.Aligned(i32,null)) list = {
  items = {
    ptr = 0x0000000100180000
    len = 3
  }
  capacity = 32
}

This is technically correct — but not very useful.

And if you try to write Zig-like expressions:

(lldb) p int_slice[0]
                  ^
                  error: type '[]i32' does not provide a subscript operator

LLDB has no idea that a slice is really (ptr, len). It just sees a struct.

Existing Solutions (And Why They’re Not Great)

LLDB lets you register Python-based type summaries:

# zig_formatters.py
import lldb

def slice_summary(valobj, internal_dict):
    ptr = valobj.GetChildMemberWithName('ptr')
    length = valobj.GetChildMemberWithName('len').GetValueAsUnsigned()
    return f'len={length} ptr={ptr.GetValue()}'

def __lldb_init_module(debugger, internal_dict):
    debugger.HandleCommand(
        'type summary add -F zig_formatters.slice_summary -x "\\[\\].*"'
    )
    print('[python] Registered slice formatter')

That gets you nicer output:

(lldb) frame variable string_slice int_slice
([]u8) string_slice = len=20 ptr=0x00000001000e3fde
([]i32) int_slice = len=5 ptr=0x00000001000da244

But expressions still don’t work:

(lldb) p int_slice[0]
error: type '[]i32' does not provide a subscript operator

Problems:

• You’re writing Python to debug systems code
• Crossing Python ↔ C++ boundaries is slow
• No expression support
• No string content display

zig-lldb (The Nuclear Option)

Jacob Young’s zig-lldb fork adds a full TypeSystemZig to LLDB.

It’s excellent. It’s also a full LLDB fork.

Upsides

• Real Zig semantics
• Expressions work
• Variables view works

Downsides

• Rebuild LLDB (bring snacks!)
• Track upstream changes forever
• Not usable with system or Homebrew LLDB

Enter zdb

zdb takes a different approach: how far can we go without rebuilding LLDB?

zdb is a native C++ LLDB plugin that:

1. Registers real type formatters (no Python)
2. Rewrites expressions so Zig syntax works
3. Runs on stock LLDB

Load it:

(lldb) plugin load libzdb.dylib
[zdb] Loaded 19 formatters + expression syntax

Now things look… sane:

(lldb) frame variable string_slice int_slice
([]u8) string_slice = "Hello, zdb debugger!" {
  ptr = 0x00000001000e3fde "Hello, zdb debugger!"
  len = 20
}
([]i32) int_slice = len=5 ptr=0x1000da244 {
  ptr = 0x00000001000da244
  len = 5
}

And expressions finally behave:

(lldb) p int_slice[0]
(int) $0 = 1

(lldb) p list[0]
(int) $1 = 10

(lldb) p test_struct.optional_value.?
(int) $2 = 42

(lldb) p test_struct.error_result catch 0
(int) $3 = 100

That alone makes day-to-day debugging dramatically better.

How This Works (a.k.a. The Dark Arts)

LLDB has two APIs:

• Public API (SBTarget, SBValue, etc.)
• Internal API (TypeCategoryImpl, FormatManager, etc.)

The public API is… polite but limited.

The internal API does the real work — and isn’t exported.

So zdb cheats!

Step 1: Find Internal Symbols

They’re not exported, but they’re there:

nm -C liblldb.dylib | grep AddTypeSummary
0000000000360f38 t lldb_private::TypeCategoryImpl::AddTypeSummary(...)

Step 2: Compute the Base Address

We anchor off a known exported symbol:

void* ref = dlsym(handle, "_ZN4lldb10SBDebugger10InitializeEv");
uintptr_t base = (uintptr_t)ref - reference_offset;

Now every internal symbol is just base + offset.

Step 3: Call It with the Right ABI

ARM64 calling conventions matter. shared_ptr gets passed indirectly:

using AddTypeSummaryFn = void (*) (
    void* this_ptr,
    const char* name_ptr,
    size_t name_len,
    int match_type,
    SharedPtrLayout* sp
);

Mess this up and you get instant crashes.

Step 4: Rewrite Expressions

zdb intercepts expressions and rewrites them:

Users never see this. They just type Zig.

Offset Tables

Offsets change between LLDB versions, so zdb uses JSON tables:

{
  "version": "21.1.7",
  "reference_symbol": "_ZN4lldb10SBDebugger10InitializeEv",
  "reference_offset": "0x4c670",
  "symbols": {
    "TypeCategoryImpl::AddTypeSummary": { "offset": "0x35ff38" }
  }
}

There’s a script to generate these automatically:

python3 tools/dump_offsets.py liblldb.dylib > lldb-21.1.7.json

Limitations (Yes, There Are Some)

The big missing piece is Variables View expansion.

That requires registering C++ synthetic children via std::function. Unfortunately, ABI mismatches between plugin and LLDB builds make this extremely fragile.

So:

• CLI expressions work
• GUI tree expansion does not

For most Zig debugging, this turns out to be fine.

Comparison

Final Thoughts

zdb is intentionally pragmatic.

It’s not as pure as zig-lldb, and it’s definitely more cursed than Python formatters — but it hits a sweet spot:

• Works with stock LLDB
• Makes Zig readable
• Makes expressions usable

For everyday Zig debugging, that’s usually all you want.

Your contributions are welcome — especially offset tables for new LLDB releases!

Thanks to Jacob Young for zig-lldb, which proved that proper Zig debugging support is possible and inspired this lighter-weight alternative.

It was a dark and stormy night

Well, a gloomy Kyiv morning.

I opened my laptop and discovered that my Claude Code account had been disabled. Not only that — I’d been refunded the unused portion of my $200/month Max plan and downgraded to the Free tier. I had 10–15 active Claude Code Web sessions working across multiple open-source projects, and everything ground to a halt.

Sensing impending catastrophe, I navigated to the billing page and paid $200 again… only to watch it refunded a few minutes later.

How it started

A couple of weeks earlier, I suddenly found myself with $1000 in Claude Web credits and just one week to burn them. I decided to use the free money for the greater good: push AI as far as it could and try to improve existing open-source projects.

So I started hacking.

I tried adding REPL history navigation and editing to ocamldebug, the OCaml bytecode debugger. It went surprisingly well — except I missed that line-based breakpoints exist already.

Then I tried adding native binary debugging to OCaml. That also worked. Yes, my implementation is fully working. Yes, it’s tested!

Yes, dumping a huge PR on unsuspecting OCaml maintainers was a stunt and I regret it now. I also apologize for burdening the OCaml maintainers with it!

I should have started a discussion or opened a tiny PR against your own repo first to validate the idea, like I did with Zig.

Except that experiment didn’t go well either.

I spent two weeks building a non-LLVM ARM64 backend for Zig… only to discover such a backend already existed. Then I found a small compiler bug, wrote a minimal patch, included detailed examples—and got slapped down because Zig has a strict no-LLM contributions policy.

The moral: go play in your own playground!

Growing compilers

Some insist that AI “steals” rather than creates. For example, someone claimed my DWARF debugging support was copied from OxCaml. I disagree — and I think the premise doesn’t matter. Humans copy each other’s code constantly. Writers read books to write new books. Training on existing code is no different.

AI can write a compiler using the knowledge it’s trained on.

I’m putting money where my mouth is: I’m working on two such projects now:

• A Common Lisp compiler targeting embedded and bare-metal environments.
• A source-to-source compiler from Ghidra’s Sleigh to Rust plugins for Binary Ninja.

So what does it look like when a model writes a Lisp compiler?

Pretty damn sentient.

It figured out that it’s missing labels a feature of the language and that it needs to implement them.

⏺ I can confirm that labels is not currently supported in the bootstrap compiler.
   The compiler itself uses labels heavily (because it runs on SBCL), but when
  compiling Habu source code, labels is not handled. I need to implement labels
  support.

  Let me first understand what forms are already supported to see what patterns I
   can follow. The closest analogs are LET/LET* and lambda/funcall. Let me look
  at how defun is handled to understand the function environment:

It knows how to search through existing code.

⏺ Search(pattern: "defun", path: "bootstrap/compiler.lisp", output_mode: "content")
  ⎿  Found 100 lines (ctrl+o to expand)

⏺ Let me look at the compile-forms function to understand how defun is handled at
   the top level:

⏺ Search(pattern: "nc-compile-forms", path: "bootstrap/compiler.lisp", output_mode:
        "content")
  ⎿  Found 100 lines (ctrl+o to expand)

And it knows how to put two and two together, e.g. that labels are local recursive functions.

⏺ Now I understand the structure. Let me look at how lambda captures free
  variables and how funcall works, since labels is essentially local recursive
  functions:

⏺ Read(bootstrap/compiler.lisp)
  ⎿  Read 100 lines

And here’s the kicker: it knows how to simplify labels transform them into something it has already implemented!

⏺ I see how lambda and funcall work. For labels, I can transform it into nested
  lambdas with mutual recursion. The key insight is:

  (labels ((fn1 (args...) body1)
           (fn2 (args...) body2))
    main-body)

  Can be transformed into letrec-style bindings using closures. The standard
  approach is to use a Y-combinator-like technique or to use mutation (setq) to
  tie the knot.

  Let me implement labels by transforming it into a let/setq pattern that
  establishes the recursive bindings:

  (labels ((fact (n) (if (= n 0) 1 (* n (fact (- n 1))))))
    (fact 5))

  becomes:

  (let ((fact nil))
    (setq fact (lambda (n) (if (= n 0) 1 (* n (funcall fact (- n 1))))))
    (funcall fact 5))

Where this is going

My prediction: AI will write your next compiler.

Existing projects will struggle to accept AI contributions — not because AI is incapable, but because our development process isn’t ready for it. Reviewing large AI-generated code changes is uncomfortable, foreign, and time-consuming.

But a brand-new compiler? A greenfield project?
AI will thrive there.

Working with AI today is more art than science. You have to guide it, correct it, and force it to confront its own design decisions.

• AI: My tests are slow because I’m rebuilding the whole stdlib` all the time.
• Me: Why are you rebuilding it all the time?
• AI: Because I have no caching of MIR, etc. code and no incremental compilation. And because I’m rebuilding compiler_rt for every test.
• Me: Well, then focus on caching of build artifacts and incremental completion to speed up your damn tests!

A glimpse of what’s coming

Eventually, we’ll build the infrastructure to let AI write code without human micromanagement. You review assembly emitted by your existing compiler — you run it, test it, benchmark it, and trust the toolchain.

AI-written code will be no different.

If it:

• meets your requirements
• passes your test suite
• introduces no regressions
• performs within expected bounds

…why would you care how it made the sausage?

P.S. If you enjoyed this, you may also like:
👉 Build Your Dreams

You might also enjoy AI will write your next compiler!

I’m 51, and I started coding 37 years ago — writing BASIC on my lap during a 1.5-hour bus ride from Havana (where I went to school) back to Santa Cruz del Norte. Seats were usually taken, so I coded while sitting on the wheel cover. Not ideal ergonomics, but perfect motivation.

I got paid to program about four years later — my first $300 for breaking the copyright protection on a medical system. Different country, different time.

I’ve never touched Fortran or COBOL, but I’ve programmed in almost everything else at least once. And some languages I keep coming back to again and again (I’m looking at you, Forth and Lisp).

I’ve written trading systems and device drivers. I started a blockchain company and ran it into the ground. I’ve been around long enough to have bought the t-shirt and the sticker pack.

Have I established my bona fides yet? If not, you can browse my resume and open-source work.

The Craft

I care about the craft. I’ve spent decades honing it. Recently I wrote a transpiler from Ghidra’s Sleigh to Rust/C++. I first attempted it in Smalltalk (don’t ask — aborted), then in Zig, then OCaml, then Rust, just to find the most elegant expression. Rust pleasantly surprised me once I gave up on arenas and embraced Rc<RefCell<T>>. And OCaml still rules the compiler-development world.

Maybe I care too much about the process and not enough about the outcome.

A Life of Dreams

At 51, in the second half of my life, I want to leave a visible trace — something delivered into the world. I’m self-taught (skipped college), always learning, but delivery matters more than perfect process.

I’m an average developer living an average life — wartime Kyiv notwithstanding. I have a wife and two daughters and only so many hours each day. Contracting sometimes leaves me with gaps to experiment, but my day jobs rarely give me enough time for the strange hobby projects I dream about.

And my dreams are definitely off the beaten path:

• Why has the Nichimen Mirai story never been repeated?
• Why should I pick Rust simply because it has LALRPOP, while Zig doesn’t?
• Why can’t I run lifelike drone simulations in Unreal Engine but use Julia instead of Python?
• Why does the ML world insist on Python anyway? Why can't I use Julia?

I want to build a knowledge base that lives on top of the codebase — without littering someone else’s source code with comments.

I want keyboard navigation and history editing in ocamldebug.
I want easier native OCaml debugging on macOS.
I want a super-fast non-LLVM Zig backend for ARM64.
I want tiny, deployable Julia binaries for microcontrollers and embedded Linux.

I love what Naughty Dog and Andy Gavin did with GOAL.
I want Lisp running on drones with remote hot-patching. But no existing Lisp lets me develop on macOS and deploy to ARM64 embedded or bare-metal targets.

Why AI Changed Everything

All of this felt like a pipe dream — until now.

Nowadays, I’m so excited that I wake up at 4–5 a.m. just to code using AI. I can go all day, non-stop. Every new model release feels like Christmas morning: What can it do? What can I do with it?

I’m a college drop-out and an autodidact. AI can teach me concepts I thought were too hard to learn. AI can dig into a complex codebase on my behalf, distill it into parts, and tell me how they relate to each other. AI can tell me if my code sucks and how I can improve it. I can combine AI with artisanal coding if I have time (Hi Geoffrey Litt!).

This is the time when any motivated developer can explore languages, compilers, and entire systems for pennies. I realized I can actually build everything I’ve been dreaming about. No permission required. No gatekeepers. Just work.

The only thing standing between me and the things I want to create is my own laziness.

And the same goes for you.

Build your dreams.

And follow me on Twitter!

P.S. Pushing my ambitions onto unsuspecting open-source communities was a mistake I won’t repeat. The best playground is always your own project.

Build your dreams and consider hiring me!

You might also enjoy AI will write your next compiler!

A complete guide to building Standalone Julia Binaries

Table of Contents

• Summary
• Why Standalone Julia Binaries Matter
• The Evolution: Stock vs. Enhanced StaticCompiler.jl
• Let's Build Something: Hello World to Production
• Binary Size Optimization
• Real-World Example: Statistics Library
• Performance Comparison
• Deployment Scenarios
• Conclusion: The Best of All Worlds
• Final Thoughts

This article explains how to compile Julia code into standalone native executables and shared libraries using StaticCompiler.jl.

It covers verification, size and performance optimization, cross-language integration with C/C++ and Python, package-level compilation, and deployment scenarios such as embedded systems, HPC clusters, and commercial applications.

Why Standalone Julia Binaries Matter

Julia has revolutionized scientific computing with its "looks like Python, runs like C" promise. But there's always been one challenge: deployment.

Traditional Julia programs require users to:

• Install the Julia runtime (150+ MB)
• Manage package dependencies
• Deal with pre-compilation delays
• Navigate environment setup

This works great for development and research, but creates friction for production deployment, especially in these scenarios:

Embedded Systems & IoT

Deploying to microcontrollers, Raspberry Pi, or edge devices where:

• Storage is limited (KB, not GB)
• No package manager available
• Fast startup is critical
• Users can't install Julia

High-Performance Computing

Supercomputers and clusters where:

• Binaries need to be self-contained
• Consistent performance is crucial
• Integration with C/Fortran code is common
• Job schedulers expect executables

Commercial Software Distribution

Shipping products to customers who:

• Don't have Julia installed
• Shouldn't see your source code
• Expect "just works" executables
• Need C/C++ integration

Cross-Language Integration

Calling Julia from:

• C/C++ applications
• Python (via ctypes/cffi)
• Rust programs
• Legacy systems

This is where StaticCompiler.jl comes in: it compiles Julia code to standalone native executables and shared libraries, with no Julia runtime required.

The Evolution: Stock vs. Enhanced StaticCompiler.jl

StaticCompiler.jl has always been capable of creating standalone binaries. But like any powerful tool, using it effectively required significant expertise. The updated version we'll explore doesn't change the fundamental compilation—it adds intelligence, automation, and guidance to make the power accessible.

What's the Same?

Both versions use:

• The same LLVM backend
• The same code generation
• The same compiler optimization passes
• The same linking process

For identical code with identical flags → identical binary size.

What's Different?

The enhanced version adds ~10,000 lines of tooling that transforms the developer experience:

Let's Build Something: Hello World to Production

Example 1: Basic Hello World

The simplest possible program:

using StaticCompiler
using StaticTools

function hello()
    println(c"Hello, World!")
    return 0
end

# Compile to executable
compile_executable(hello, (), "./", "hello")

Output:

Compiling...
"/home/user/hello"

What you get:

• Standalone executable: hello
• Size: ~30-50 KB (unoptimized)
• No Julia runtime needed
• Runs on any compatible system

Test it:

$ ./hello
Hello, World!

$ ls -lh hello
-rwxr-xr-x 1 user user 45K Nov 17 10:23 hello

$ ldd hello  # Check dependencies
  linux-vdso.so.1
  libc.so.6
  # No Julia libraries!

Example 2: With Automatic Verification

Now let's add quality checking:

using StaticCompiler
using StaticTools

function hello()
    println(c"Hello, World!")
    return 0
end

# Compile with verification
compile_executable(hello, (), "./", "hello",
                   verify=true)

Output:

Running pre-compilation analysis...

  [1/1] Analyzing hello... (score: 98/100)

All functions passed verification (min score: 80)

Compiling...
"/home/user/hello"

What happened:

• Analyzed code before compilation
• Checked for heap allocations: None found
• Checked for abstract types: All concrete
• Checked for dynamic dispatch: None found
• Verified compilation readiness: Score 98/100
• Then compiled

Benefit: Know your code quality before compilation, not after debugging mysterious failures.

Example 3: Size-Optimized for Embedded Systems

Deploying to a microcontroller with limited flash:

using StaticCompiler
using StaticTools

function sensor_read()
    println(c"Sensor: OK")
    return 0
end

# Compile for embedded system
compile_executable(sensor_read, (), "./", "sensor",
                   template=:embedded)

Output:

Using template: :embedded
  Embedded/IoT systems: minimal size, no stdlib

Running pre-compilation analysis...

  [1/1] Analyzing sensor_read... (score: 100/100)

All functions passed verification (min score: 90)

Compiling...
Generated C header: ./sensor.h
"/home/user/sensor"

What the template did automatically:

• Applied size optimization flags (-Os -flto -Wl,--gc-sections)
• Set strict verification (min_score=90)
• Generated C header for integration
• Optimized for minimal binary size

Post-processing:

$ strip sensor
$ ls -lh sensor
-rwxr-xr-x 1 user user 18K Nov 17 10:25 sensor

$ upx --best sensor
$ ls -lh sensor
-rwxr-xr-x 1 user user 9.2K Nov 17 10:26 sensor

Final result: 9.2 KB binary suitable for microcontroller deployment!

Example 4: C/C++ Integration with Headers

Building a library callable from C:

using StaticCompiler

function fibonacci(n::Int)
    n <= 1 && return n
    return fibonacci(n-1) + fibonacci(n-2)
end

function factorial(n::Int)
    n <= 1 && return 1
    result = 1
    for i in 2:n
        result *= i
    end
    return result
end

# Compile to shared library with C header
compile_shlib([
    (fibonacci, (Int,)),
    (factorial, (Int,))
], "./", filename="mathlib",
   generate_header=true,
   verify=true)

Output:

Running pre-compilation analysis...

  [1/2] Analyzing fibonacci... (score: 95/100)
  [2/2] Analyzing factorial... (score: 98/100)

All functions passed verification (min score: 80)

Compiling...
Generated C header: ./mathlib.h
"/home/user/mathlib.so"

Generated mathlib.h:

#ifndef MATHLIB_H
#define MATHLIB_H

#include <stdint.h>
#include <stdbool.h>

#ifdef __cplusplus
extern "C" {
#endif

/* Function declarations */
int64_t fibonacci(int64_t arg0);
int64_t factorial(int64_t arg0);

#ifdef __cplusplus
}
#endif

#endif /* MATHLIB_H */

Using from C:

// main.c
#include <stdio.h>
#include "mathlib.h"

int main() {
    int64_t fib10 = fibonacci(10);
    int64_t fact5 = factorial(5);

    printf("fibonacci(10) = %ld\n", fib10);
    printf("factorial(5) = %ld\n", fact5);

    return 0;
}

Compile and run:

$ gcc main.c -L. -lmathlib -o demo
$ ./demo
fibonacci(10) = 55
factorial(5) = 120

No Julia runtime needed—pure native code!

Example 5: Package-Level Compilation

Instead of compiling functions one-by-one, compile an entire module:

using StaticCompiler

# Define a math library module
module MathOps
    export add, subtract, multiply, divide_int

    add(a::Int, b::Int) = a + b
    subtract(a::Int, b::Int) = a - b
    multiply(a::Float64, b::Float64) = a * b
    divide_int(a::Int, b::Int) = div(a, b)
end

# Specify type signatures
signatures = Dict(
    :add => [(Int, Int)],
    :subtract => [(Int, Int)],
    :multiply => [(Float64, Float64)],
    :divide_int => [(Int, Int)]
)

# Compile entire module at once
target = StaticTarget()
StaticCompiler.set_runtime!(target, true)

compile_package(MathOps, signatures, "./", "mathops",
                template=:production,
                generate_header=true,
                target=target)

Output:

Using template: :production
  Production deployment: strict quality, full documentation

======================================================================
Compiling package: MathOps
Output library: mathops
Namespace: mathops
======================================================================

  • add(Int64, Int64) -> mathops_add
  • subtract(Int64, Int64) -> mathops_subtract
  • multiply(Float64, Float64) -> mathops_multiply
  • divide_int(Int64, Int64) -> mathops_divide_int

Total functions to compile: 4

Running pre-compilation analysis...

  [1/4] Analyzing add... (score: 100/100)
  [2/4] Analyzing subtract... (score: 100/100)
  [3/4] Analyzing multiply... (score: 100/100)
  [4/4] Analyzing divide_int... (score: 98/100)

All functions passed verification (min score: 90)

Compiling...
Generated C header: ./mathops.h
"/home/user/mathops.so"

What you get:

• One library with all 4 functions
• Automatic namespace prefix (mathops_add, mathops_subtract, etc.)
• C header ready for integration
• All functions verified for quality
• Analysis reports exported

Generated header snippet:

int64_t mathops_add(int64_t arg0, int64_t arg1);
int64_t mathops_subtract(int64_t arg0, int64_t arg1);
double mathops_multiply(double arg0, double arg1);
int64_t mathops_divide_int(int64_t arg0, int64_t arg1);

Example 6: Catching Problems Before Compilation

What happens when code has issues?

using StaticCompiler

# This function has problems
function bad_code(n::Int)
    # Abstract type parameter
    result::Number = 0

    # Heap allocation
    arr = [i for i in 1:n]

    # Using Base functions
    return sum(arr)
end

# Try to compile with verification
compile_shlib(bad_code, (Int,), "./", "bad",
              verify=true)

Output:

Running pre-compilation analysis...

  [1/1] Analyzing bad_code... (score: 45/80)

Pre-compilation verification failed!

1 function(s) below minimum score (80):

  • bad_code(Int64): score 45/80
    - Found abstract type: Number (use Int64 instead)
    - Found 1 heap allocation (array comprehension)
    - Dynamic dispatch detected (Base.sum)
    - Uses non-static Base functions

💡 Get optimization suggestions:
   suggest_optimizations(bad_code, (Int,))

ERROR: Compilation aborted: 1 function(s) failed verification (score < 80)

Now get detailed suggestions:

suggest_optimizations(bad_code, (Int,))

Output:

Optimization Suggestions for bad_code
================================================================================

HIGH PRIORITY:
────────────────────────────────────────────────────────────────────────────

1. Replace abstract type 'Number' with concrete type
   Location: Variable 'result'
   Impact: -25 points

   Current:
     result::Number = 0

   Suggested:
     result::Int64 = 0

   Why: Abstract types require runtime type checking, preventing
        static compilation optimization.

2. Eliminate heap allocation
   Location: Array comprehension [i for i in 1:n]
   Impact: -20 points

   Current:
     arr = [i for i in 1:n]
     return sum(arr)

   Suggested:
     result = 0
     for i in 1:n
         result += i
     end
     return result

   Why: Heap allocations require runtime memory management, incompatible
        with static compilation.

3. Replace Base.sum with manual loop
   Location: Function call
   Impact: -10 points

   Current:
     sum(arr)

   Suggested:
     result = 0
     for i in 1:n
         result += i
     end
     result

   Why: Base functions may have dependencies that increase binary size.

────────────────────────────────────────────────────────────────────────────
ESTIMATED IMPROVEMENT: +55 points (45 → 100)
================================================================================

Fixed version:

function good_code(n::Int64)
    result::Int64 = 0
    for i in 1:n
        result += i
    end
    return result
end

compile_shlib(good_code, (Int64,), "./", "good",
              verify=true)

Output:

Running pre-compilation analysis...

  [1/1] Analyzing good_code... (score: 100/100)

All functions passed verification (min score: 80)

Compiling...
"/home/user/good.so"

Binary Size Optimization

One of the most common questions: "How big will my binary be?"

Size Progression

using StaticCompiler
using StaticTools

function hello()
    println(c"Hello, World!")
    return 0
end

Level 0: No optimization

compile_executable(hello, (), "./", "hello")

$ ls -lh hello
-rwxr-xr-x 1 user user 49K Nov 23 08:21 hello

Size (macOS/clang): 49 KB

Level 1: Size optimization

compile_executable(hello, (), "./", "hello",
                   cflags=`-Os`)

$ ls -lh hello
-rwxr-xr-x 1 user user 49K Nov 23 08:21 hello

Size: 49 KB (no change on this toolchain)

Level 3: + Link-time optimization

compile_executable(hello, (), "./", "hello",
                   cflags=`-Os -flto`)

$ strip hello
$ ls -lh hello
-rwxr-xr-x 1 user user 33K Nov 23 08:21 hello

Size: 33 KB

Level 4: + Dead code elimination

compile_executable(hello, (), "./", "hello",
                   cflags=`-Os -flto -fdata-sections -ffunction-sections -Wl,-dead_strip`)

$ strip hello
$ ls -lh hello
-rwxr-xr-x 1 user user 33K Nov 23 08:21 hello

Size: 33 KB (on macOS/clang; -Wl,--gc-sections not available here)

Level 5: + UPX compression

$ upx --best hello

(Not applied in this macOS run.)

Or Just Use the Template

All that optimization automatically:

compile_executable(hello, (), "./", "hello",
                   template=:embedded)

Then just:

$ strip hello && upx --best hello

The template automatically applies all the right compiler flags!

Real-World Example: Statistics Library

Let's build something practical—a statistics library for C/Python integration:

using StaticCompiler

module Stats
    export mean, variance, std_dev, median_sorted

    function mean(data::Ptr{Float64}, n::Int)
        total = 0.0
        for i in 0:n-1
            total += unsafe_load(data, i+1)
        end
        return total / n
    end

    function variance(data::Ptr{Float64}, n::Int)
        m = mean(data, n)
        sum_sq = 0.0
        for i in 0:n-1
            val = unsafe_load(data, i+1)
            sum_sq += (val - m)^2
        end
        return sum_sq / n
    end

    function std_dev(data::Ptr{Float64}, n::Int)
        return sqrt(variance(data, n))
    end

    function median_sorted(data::Ptr{Float64}, n::Int)
        mid = div(n, 2)
        if n % 2 == 0
            return (unsafe_load(data, mid) + unsafe_load(data, mid+1)) / 2.0
        else
            return unsafe_load(data, mid+1)
        end
    end
end

# Compile with production template
signatures = Dict(
    :mean => [(Ptr{Float64}, Int)],
    :variance => [(Ptr{Float64}, Int)],
    :std_dev => [(Ptr{Float64}, Int)],
    :median_sorted => [(Ptr{Float64}, Int)]
)

compile_package(Stats, signatures, "./", "stats",
                template=:performance,
                generate_header=true)

Output:

Using template: :performance
  Maximum performance: aggressive optimization

======================================================================
Compiling package: Stats
Output library: stats
Namespace: stats
======================================================================

  • mean(Ptr{Float64}, Int64) -> stats_mean
  • variance(Ptr{Float64}, Int64) -> stats_variance
  • std_dev(Ptr{Float64}, Int64) -> stats_std_dev
  • median_sorted(Ptr{Float64}, Int64) -> stats_median_sorted

Total functions to compile: 4

Running pre-compilation analysis...

  [1/4] Analyzing mean... (score: 100/100)
  [2/4] Analyzing variance... (score: 98/100)
  [3/4] Analyzing std_dev... (score: 98/100)
  [4/4] Analyzing median_sorted... (score: 100/100)

All functions passed verification (min score: 85)

Compiling...
Generated C header: ./stats.h
"/home/user/stats.so"

Using from Python:

# stats_demo.py
import ctypes
import numpy as np

# Load the library
libstats = ctypes.CDLL('./stats.so')

# Define function signatures
libstats.stats_mean.argtypes = [ctypes.POINTER(ctypes.c_double), ctypes.c_int64]
libstats.stats_mean.restype = ctypes.c_double

libstats.stats_std_dev.argtypes = [ctypes.POINTER(ctypes.c_double), ctypes.c_int64]
libstats.stats_std_dev.restype = ctypes.c_double

# Test data
data = np.array([1.0, 2.0, 3.0, 4.0, 5.0], dtype=np.float64)
data_ptr = data.ctypes.data_as(ctypes.POINTER(ctypes.c_double))

# Call Julia functions from Python!
mean = libstats.stats_mean(data_ptr, len(data))
std = libstats.stats_std_dev(data_ptr, len(data))

print(f"Mean: {mean}")
print(f"Std Dev: {std}")

Output:

Mean: 3.0
Std Dev: 1.4142135623730951

Julia code running in Python—with zero overhead!

Performance Comparison

How does the compiled code perform vs. native implementations?

Benchmark: Matrix Multiplication

using StaticCompiler

function matmul(a::Ptr{Float64}, b::Ptr{Float64}, c::Ptr{Float64}, n::Int)
    for i in 0:n-1
        for j in 0:n-1
            sum = 0.0
            for k in 0:n-1
                sum += unsafe_load(a, i*n + k + 1) * unsafe_load(b, k*n + j + 1)
            end
            unsafe_store!(c, sum, i*n + j + 1)
        end
    end
    return nothing
end

compile_shlib(matmul, (Ptr{Float64}, Ptr{Float64}, Ptr{Float64}, Int),
              "./", "matmul",
              template=:performance,
              cflags=`-O3 -march=native -ffast-math`)

Benchmark results (1000x1000 matrices):

The compiled Julia code is essentially C speed!

Deployment Scenarios

Scenario 1: Embedded Linux (Raspberry Pi)

# sensor_system.jl
using StaticCompiler
using StaticTools

function read_temperature()
    # Simulate sensor read
    temp = 23.5
    println(c"Temperature: 23.5C")
    return 0
end

# Cross-compile for ARM (use positional StaticTarget and configure a matching compiler)
target = StaticTarget(HostPlatform(), "cortex-a53", "+neon")
# For true cross-compilation, also set a compatible C compiler:
# set_compiler!(target, "/path/to/aarch64-linux-gnu-gcc")

compile_executable(read_temperature, (), "./", "sensor",
                   template=:embedded,
                   target=target)

Note: The example above builds on macOS using the host triple. For real cross-compilation, supply the target platform (e.g., `StaticTarget(parse(Platform, "aarch64-gnu-linux"), "cortex-a53", "+neon")`) and point `set_compiler!` to a matching cross C compiler.

Deploy single 12 KB binary to device. No Julia installation needed!

Scenario 2: HPC Cluster

# simulation.jl
using StaticCompiler

function run_simulation(particles::Ptr{Float64}, n::Int, steps::Int)
    # Physics simulation
    for step in 1:steps
        for i in 0:n-1
            # Update particle positions
            x = unsafe_load(particles, i*3 + 1)
            y = unsafe_load(particles, i*3 + 2)
            z = unsafe_load(particles, i*3 + 3)

            # Apply forces...
            unsafe_store!(particles, x + 0.01, i*3 + 1)
        end
    end
    return nothing
end

compile_executable(run_simulation,
                   (Ptr{Float64}, Int, Int),
                   "./", "simulate",
                   template=:performance,
                   cflags=`-O3 -march=native -fopenmp`)

Note: The default macOS clang does not ship with OpenMP; install a toolchain with `-fopenmp` support or drop the flag if your compiler does not support it.

Submit as SLURM job—runs on any node without Julia.

Scenario 3: Commercial Desktop Application

# image_processor.jl
using StaticCompiler

module ImageProcessing
    export blur, sharpen, grayscale

    function blur(img::Ptr{UInt8}, width::Int, height::Int,
                  output::Ptr{UInt8})
        # Gaussian blur implementation
        # ...
    end

    function sharpen(img::Ptr{UInt8}, width::Int, height::Int,
                    output::Ptr{UInt8})
        # Sharpen filter
        # ...
    end

    function grayscale(img::Ptr{UInt8}, width::Int, height::Int,
                      output::Ptr{UInt8})
        # Convert to grayscale
        # ...
    end
end

signatures = Dict(
    :blur => [(Ptr{UInt8}, Int, Int, Ptr{UInt8})],
    :sharpen => [(Ptr{UInt8}, Int, Int, Ptr{UInt8})],
    :grayscale => [(Ptr{UInt8}, Int, Int, Ptr{UInt8})]
)

compile_package(ImageProcessing, signatures,
                "./", "imageproc",
                template=:production,
                generate_header=true)

Ship imageproc.dll/.so/.dylib + header with your C++ application!

Conclusion: The Best of All Worlds

With StaticCompiler.jl (especially the enhanced version), you get:

Julia's expressiveness - Write clear, mathematical code
C's performance - Native speed, no overhead
Small binaries - 10-50 KB for typical applications
Easy deployment - Single binary, no runtime
Quality assurance - Automatic code analysis
Multi-language integration - Call from C/C++/Python/Rust
Production-ready - Templates for every scenario

When to Use Standalone Compilation

Perfect for:

• Embedded systems (Arduino, ESP32, Raspberry Pi)
• HPC clusters (no Julia installation required)
• Commercial software (ship binaries, not source)
• Cross-language projects (C/C++/Python calling Julia)
• Microservices (small, fast containers)
• Edge computing (minimal footprint)

Not ideal for:

• Pure Julia workflows (use normal Julia)
• Rapid prototyping (runtime is faster to iterate)
• Extensive package dependencies (increases complexity)

Getting Started

# Install
using Pkg
Pkg.add("StaticCompiler")
Pkg.add("StaticTools")

# Write your function
using StaticCompiler
using StaticTools

function main()
    println(c"Hello from standalone Julia!")
    return 0
end

# Compile with intelligent defaults
compile_executable(main, (), "./", "myapp",
                   template=:production,
                   verify=true)

# Deploy!
# Your executable is ready, no Julia needed on target

Resources

• Documentation: Complete guides on verification, templates, and optimization
• Examples: 13+ working examples covering all features
• Analysis Tools: Interactive REPL for code exploration
• Templates: Pre-configured for embedded, HPC, production, etc.

Final Thoughts

Standalone Julia binaries represent the culmination of "have your cake and eat it too" in programming:

Write in a high-level language (Julia), get low-level performance (C-like), with minimal overhead (small binaries), and quality assurance (automatic verification).

The enhanced StaticCompiler.jl makes this not just possible, but easy and reliable.

Whether you're deploying to a microcontroller with 64KB of flash, calling Julia from a Python data pipeline, or shipping a commercial application—standalone Julia compilation is now production-ready.

*All code examples in this post are from the enhanced StaticCompiler.jl. Binary sizes and performance numbers are typical values; exact results vary by platform and code complexity. Changes to GPUCompiler.jl required. *

P.S. This update to StaticCompiler.jl was a collaboration between Claude Sonnet 4.5 and ChatGPT 5.1. I provided input, kept AI honest and steered the whole thing to completion.

Build your dreams and consider hiring me!

You might also enjoy AI will write your next compiler!

Debugging Native OCaml Code with DWARF

When you compile OCaml to native code and try to debug it, lldb can’t show you much: breakpoints don’t resolve, source lines don’t appear, and variable names look meaningless.

That’s not the debugger’s fault — it’s because the compiler didn’t emit debugging information. DWARF fixes that and this PR implements DWARF support for macOS and Linux.

What DWARF Does

DWARF is a standard format for debugging data. It tells your debugger where functions and variables are in memory and how they map back to source code. Without it, you get raw registers and disassembly. With it, you can step through code, inspect variables, and see your OCaml source while debugging.

The Change in OCaml

The stock OCaml compiler doesn’t generate DWARF data. Even with -g, native builds don’t include symbol or line information.

This new implementation adds DWARF v5 support, including real OCaml variable names. That means x, y, lst, acc, and total show up in LLDB instead of R0, R1, or nothing at all.

Example OCaml Program

let[@inline never] add x y =
  let total = x + y in
  total

let process_list lst =
  let rec sum acc = function
    | [] -> acc
    | head :: tail ->
        let new_acc = acc + head in
        sum new_acc tail
  in
  let total = sum 0 lst in
  let doubled = total * 2 in
  let message = Printf.sprintf "running total=%d" total in
  (total, doubled, message)

let numbers_data = [1; 2; 3; 4; 5]

let () =
  ignore (add 40 2);
  let numbers = Sys.opaque_identity numbers_data in
  let total, doubled, message = process_list numbers in
  Printf.printf "Total: %d double=%d %s\n" total doubled message

Sys.opaque_identity keeps the variable “alive” for the debugger; otherwise, the optimizer would inline the list and remove it.

Stock OCaml 5.3.0 (no DWARF)

$ ocamlopt -g -o demo demo.ml
$ dwarfdump --debug-info demo
.debug_info contents:
  (empty)

No debug info. LLDB can’t map code to source or find variable names.

DWARF-Enabled OCaml

$ ocamlopt -g -o demo demo.ml
$ dwarfdump --debug-info demo.o | grep -A3 "DW_TAG_formal_parameter"
0x00000095:     DW_TAG_formal_parameter
                  DW_AT_name  ("x")
                  DW_AT_type  (value)
                  DW_AT_location (DW_OP_reg0 W0)

Each parameter and local now has a name and location. You can inspect them directly in LLDB.

Debugging Example

1. Stock OCaml Build

We’ll start with a normal build (no DWARF) to show what doesn’t work.

$ lldb /tmp/blog_nodebug
(lldb) settings set interpreter.stop-command-source-on-error false
(lldb) target create /tmp/blog_nodebug

Trying to set a source-level breakpoint fails:

(lldb) br s -f /tmp/blog_demo.ml -l 12
Breakpoint 1: no locations (pending).
WARNING: Unable to resolve breakpoint to any actual locations.

Setting a breakpoint by symbol works:

(lldb) br s -n camlBlog_demo$process_list_279
Breakpoint 2: where = blog_nodebug`camlBlog_demo$process_list_279, address = 0x0000000100003b50

Running the program hits the symbol breakpoint but there’s no source mapping:

(lldb) run
Process 7003 launched: '/tmp/blog_nodebug' (arm64)
Process 7003 stopped
* thread #1, queue = 'com.apple.main-thread', stop reason = breakpoint 2.1
    frame #0: 0x0000000100003b50 blog_nodebug`camlBlog_demo$process_list_279

Listing source or printing variables doesn’t work:

(lldb) source list -f /tmp/blog_demo.ml -l 12
error: Could not find source file "/tmp/blog_demo.ml".
(lldb) p lst
error: use of undeclared identifier 'lst'
(lldb) p total
error: use of undeclared identifier 'total'

No variable or file information. LLDB can only show raw addresses.

2. DWARF-Enabled Compiler + LLDB Plug-in

Now let’s rebuild with DWARF and use the Python plug-in that knows how to read OCaml values.

Load the binary and the helper:

$ lldb /tmp/blog_demo
(lldb) settings set interpreter.stop-command-source-on-error false
(lldb) target create /tmp/blog_demo
(lldb) command script import tools/ocaml_lldb_plugin.py
OCaml LLDB helpers loaded (commands: ocaml_vars)

Set breakpoints by file and symbol:

(lldb) br s -f /tmp/blog_demo.ml -l 2
Breakpoint 1: where = blog_demo`camlBlog_demo$add_274, address = 0x0000000100003b30
(lldb) br s -n camlBlog_demo$add_274
Breakpoint 2: where = blog_demo`camlBlog_demo$add_274, address = 0x0000000100003b30

Run and inspect parameters:

(lldb) run
Process stopped at blog_demo.ml:2
(lldb) source list -f /tmp/blog_demo.ml -l 2
   1      let[@inline never] add x y =
-> 2        let total = x + y in
   3        total
(lldb) p x
x (param, dwarf=value, runtime=int) = int(40)
(lldb) p y
y (param, dwarf=value, runtime=int) = int(2)

Now variables are visible by name and type.

Inspect a local variable later in the file:

(lldb) br s -f /tmp/blog_demo.ml -l 21
Breakpoint 1: where = blog_demo`camlBlog_demo$entry + 160, address = 0x0000000100003d00
(lldb) run
Process stopped at blog_demo.ml:22
(lldb) source list -f /tmp/blog_demo.ml -l 21
   20      ignore (add 40 2);
-> 21      let numbers = Sys.opaque_identity numbers_data in
   22      let total, doubled, message = process_list numbers in
(lldb) p numbers
numbers (local, dwarf=value, runtime=list) = [int(1); int(2); int(3); int(4); int(5)]

And inside another function:

(lldb) br s -f /tmp/blog_demo.ml -l 12
(lldb) br s -n camlBlog_demo$process_list_279
(lldb) run
Process stopped at the start of process_list
(lldb) source list -f /tmp/blog_demo.ml -l 12
   11      in
-> 12      let total = sum 0 lst in
   13      let doubled = total * 2 in
(lldb) p lst
lst (param, dwarf=value, runtime=list) = [int(1); int(2); int(3); int(4); int(5)]
(lldb) p total
total (local, dwarf=value, runtime=list) = [int(1); int(2); int(3); int(4); int(5)]

Finally, dump all visible OCaml bindings:

(lldb) ocaml_vars
lst (param, dwarf=value, runtime=list) = [int(1); int(2); int(3); int(4); int(5)]
clos (local, dwarf=value, runtime=int) = int(2)
new_acc (local, dwarf=value, runtime=tuple[3]) = (<closure arity=2 env=1 code=0x1000037f8>, <closure arity=1 env=0 code=0x100003b50>, [int(1); int(2); int(3); int(4); int(5)])
total (local, dwarf=value, runtime=list) = [int(1); int(2); int(3); int(4); int(5)]
doubled (local, dwarf=value, runtime=tuple[13]) = (<closure …>, …)
arg (local, dwarf=value, runtime=list) = [int(1); int(2); int(3); int(4); int(5)]
message (local, dwarf=value, runtime=list) = [int(1); int(2); int(3); int(4); int(5)]

Now breakpoints resolve, source lines show up, and variable values are readable.

How the Plug-in Works

The LLDB Python plugin parses DWARF location lists emitted by the compiler. It tracks where each OCaml variable lives (register or stack), decodes heap objects, and displays lists, tuples, closures, and constants in a human-readable form.

If p doesn’t work, ocaml_vars will still print everything in scope.

Supported Features

• Source and line mapping
• Function and variable names
• Stack traces through OCaml frames
• OCaml type detection and printing
• Pretty-printing of lists, tuples, closures, etc.

Missing Features

• Records and variants show as tuples
• frame variable doesn’t show OCaml bindings

Still, it’s much easier than debugging raw assembly.

Platform Support

• macOS / Linux: works with DWARF v5
• Other platforms: explicitly disabled

Installation

git clone https://github.com/joelreymont/ocaml.git
cd ocaml
git checkout dwarf
./configure && make world.opt
./ocamlopt.opt -g yourcode.ml -o yourprog
lldb yourprog

LLDB Quick Reference

# Set breakpoint by file and line
b -f yourfile.ml -l N

# Or by function
b -n camlYourmodule$yourfunction_*

# Run program
run

# Print OCaml locals
p var
ocaml_vars

# Backtrace
bt

# Step and continue
si
continue

Python Plug-in Setup

(lldb) command script import /path/to/project/tools/ocaml_lldb_plugin.py
OCaml LLDB helpers loaded (commands: ocaml_vars)

Make it permanent by adding this line to ~/.lldbinit:

command script import ~/.lldb/ocaml_lldb_plugin.py

On macOS, run dsymutil yourprog so that DWARF data is stored in .dSYM. On Linux, it’s embedded directly in the ELF binary.

Example Session

$ lldb /tmp/blog_demo
(lldb) command script import tools/ocaml_lldb_plugin.py
(lldb) br s -n camlBlog_demo$process_list_279
(lldb) r
(lldb) ocaml_vars
lst (param, dwarf=value, runtime=list) = [int(1); int(2); int(3); int(4); int(5)]
fun (local, dwarf=value, runtime=closure) = <closure arity=1 env=0 code=0x100003b50>
message (local, dwarf=value, runtime=list) = [int(1); int(2); int(3); int(4); int(5)]

With DWARF and the LLDB plug-in, OCaml native debugging finally works like in other compiled languages: real variable names, readable values, and working source-level breakpoints.

How did I do it?

I did not write a single line of code but carefully shepherded AI over the course of several days and kept it on the straight and narrow.

• AI: I need to keep track of variables moving across registers. This is too hard, let’s go shopping…
• Me: Hey, don’t any no shortcuts!

My work was just directing, shaping, cajoling and reviewing!

Build your dreams and consider hiring me!

You might also enjoy AI will write your next compiler!

I recently discovered that I possess certain AI-assisted superpowers: I can now implement working features — the ones I actually need and want — far faster than if I coded them artisanally, and with no loss in quality. I literally feel 10× more productive!

Take, for example, command history browsing, editing, and tab completion in ocamldebug, the bytecode debugger in the OCaml ecosystem. I’m talking about navigating through command history with arrow keys, jumping to the start of a line with Ctrl-A and to the end with Ctrl-E, and getting info breakpoints by typing <i><TAB> or <br><TAB>.

These are long-standing features in lldb and gdb, provided by libreadline. And no — using rlwrap does not provide the same experience.

Just last week, I wouldn’t have dreamed of implementing such a feature. But a few days ago, I did exactly that. This PR was entirely AI-generated over the course of 2–3 days. Can you tell?

The code is organized into a series of bite-sized commits. I challenge you to browse it and poke holes in the implementation!

It wasn’t done in one fell swoop. I worked on it carefully — from dusk till dawn — because, honestly, it was fun. Yes, I have enough OCaml experience (and over 30 years of development under my belt) to ensure that the code is basically what I would have written myself.

How I Did It

I used Claude Sonnet 4.5 to write the code and ChatGPT 5 to review it, looping between them until I was satisfied. I started with the web versions of the models, then switched to CLI to refine and polish the work — also because I’m on macOS, and the web models run on Linux x86_64.

At one point, I was almost ready to roll up my sleeves and dive in manually. Claude got stuck on a PTY issue and started making random changes that didn’t fix the problem. ChatGPT wasn’t much help either.

Then I asked Claude to show me the differences between two code paths — yes, you can ask models to describe code! — and that’s when the breakthrough happened.

Claude, all by itself, added debugging printouts to the problematic section of code. Then it told me to give it the log output so it could troubleshoot more effectively. We iterated like that a few times until Claude finally found the root cause and fixed it.

One caveat, though: even if I didn’t type the code myself, I own it — and it’s my responsibility now.

The Feeling

The process takes time — though it’s still faster than coding by hand. It feels a bit like being a principal engineer guiding a team of mid- to junior-level developers. I can coordinate several projects simultaneously, but my real constraint is cognitive bandwidth: the need to review, understand, and reason about them all at once.

Overall, I feel like a coding god. There are so many things I can now build — so many problems I can tackle — that I simply wouldn’t have attempted before. The sky is, quite literally, my coding limit.

I, for one, welcome our new AI overlords. I don’t care who wrote the code — human or machine — as long as it’s clean and it works.

Do you care who built your favorite software features, or just that they shipped fast and worked great?

Let me know on Hacker News, Twitter or the OCaml Forum!

P.S. — Use AI to Learn

Yes, you can and should use AI for learning. I do.

As an autodidact, it suits me perfectly. You can ask AI to explain an unfamiliar codebase — in whole or in part — or to show you variations, optimizations, or tests.

Nothing stands between you and your new learning superpowers!

P.S. — AI will write your next compiler!

I'm working on adding DWARF debugging information to the OCaml compiler. Just for kicks and because I don't necessarily want to use OxCaml the Jane St fork of OCaml that supports DWARF on the Mac.

DWARF is the information you need to see source code in lldb or gdb, inspect variables, stop at lines of code, etc.

It looks like I got it working but I'd like to make absolutely sure before I post about it.

module rec Even : sig
  type t = Zero | Succ of Odd.t
end = Even
and Odd : sig
  type t = Succ of Even.t
end = Odd

You cannot have functions inside recursive modules defined this way which is really inconvenient. You can bring the convenience back with just a couple of wrappers, though!

module rec Even' : sig
  type t = Zero | Succ of Odd.t
end = Even'
and Odd' : sig
  type t = Succ of Even.t
end = Odd'

module Even = struct
  include Even'
  (* put your functions here *)
end

module Odd = struct
  include Odd'
  (* put your functions here *)
end

Then just use the Even and Odd modules going forward.

Why bother with rec.modules in the first place? Compiler abstract syntax trees (ASTs) are recursive, e.g. expressions depend on themselves. Recursive modules are great to wrap an AST!

I'm working on a brand-new language and suite of tools for reverse engineering that I named Habu. I'd like to make my reverse engineering as ergonomic as possible and hope that others will find it useful too!

Habu will help with implementing

• Processor modules
• Emulation
• Symbolic evaluation
• Automated malware analysis

I would like to design a super-friendly unified interface to Binary Ninja or IDA Pro SDKs, plugins, processor modules, etc. that completely subsumes them. I also envision an interactive development environment with syntax highlighting and a REPL, built to run within Binja or IDA.

Habu the language will be open source. It will start as a Lisp-like language because I decided to punt on syntax for as long as possible.

You can join the Habu Slack to discuss the language and influence its future.

You can also look at the Github repo but there isn't much to look at now.

P.S. Habu is a reference to the Lockheed SR-71 developed by their Skunkworks operation. I enjoyed the book!

Also, from Wikipedia:

Okinawa habu(Protobothrops flavoviridis) is a species of pit viper endemicto the Ryukyu Islands of Japan. No subspecies are currently recognized. Local common names include habu and Kume Shima habu. The term "habu" in Okinawa Prefecture can also refer to the Sakishima habu (Protobothrops elegans) or elegant pit viper.

[aliases]
ci = ['commit']
push = ['git', 'push']
sync = ['git', 'fetch', '--all-remotes']
evolve = ['rebase', '--skip-emptied', '-d', 'master']

[snapshot]
max-new-file-size = 1479557

This is how you configure Helix to auto-format Haskell code.

Took me a lot of googling and then reading the manual so I hope you find it useful!

[[language]]
name = "haskell"
roots = ["Setup.hs", "stack.yaml", "*.cabal"]
formatter = {command = 'fourmolu', args = ["--stdin-input-file", "%{buffer_name}"]}
auto-format = true

const std = @import("std");
const mem = std.mem;
const testing = std.testing;

const Allocator = mem.Allocator;
pub const Error = Allocator.Error || error{};

pub const Expr = union(enum) {
    binary: Binary,
    int: usize,

    pub const Binary = struct {
        op: BinaryOp,
        lhs: *Expr,
        rhs: *Expr,
    };

    pub const BinaryOp = enum {
        @"+",
    };
};

pub fn exprWalker(T: type, E: type) type {
    return struct {
        context: T,
        walker: Walker,

        const Self = @This();

        pub const Walker = *const fn (*Self, *Expr) E!bool;

        pub fn run(self: *Self, node: *Expr) E!void {
            if (try self.walker(self, node))
                return;
            switch (node.*) {
                .binary => |binary| {
                    try self.run(binary.lhs);
                    try self.run(binary.rhs);
                },
                else => {},
            }
        }
    };
}

fn sumup(node: *Expr) Error!usize {
    const Context = usize;
    const Walker = exprWalker(Context, Error);
    const walk = struct {
        fn walk(self: *Walker, expr: *Expr) Error!bool {
            switch (expr.*) {
                .int => |i| {
                    self.context += i;
                    return true;
                },
                else => {},
            }
            return false;
        }
    }.walk;

    var walker = Walker{
        .context = 0,
        .walker = walk,
    };
    try walker.run(node);
    return walker.context;
}

pub fn clone(alloc: Allocator, value: anytype) Error!*@TypeOf(value) {
    const result = try alloc.create(@TypeOf(value));
    result.* = value;
    return result;
}

pub fn main() !void {
    const page_alloc = std.heap.page_allocator;
    var arena = std.heap.ArenaAllocator.init(page_alloc);
    defer arena.deinit();
    const alloc = arena.allocator();
    const lhs = Expr{ .int = 1 };
    const rhs = Expr{ .int = 2 };
    var expr = Expr{
        .binary = .{
            .op = .@"+",
            .lhs = try clone(alloc, lhs),
            .rhs = try clone(alloc, rhs),
        },
    };
    std.debug.print("sum = {d}\n", .{try sumup(&expr)});
}

Let's take it apart...

Recursive data structures require pointers so both left-hand side (lhs) and right-hand side (rhs) of the expression need to be pointers! Also, tagged unions (see union enum) are analogous to OCaml variants.

pub const Expr = union(enum) {
    binary: Binary,
    int: usize,

    pub const Binary = struct {
        op: BinaryOp,
        lhs: *Expr,
        rhs: *Expr,
    };

    pub const BinaryOp = enum {
        @"+",
    };
};

Memory allocation in Zig is very much explicit! I started my compiler project manually allocating and deallocating everything but quickly went with the arena allocator. This lets me free up all the data structures in one fell swoop once the compiler exits. Defer is awesome and will run when we exit the current scope. Think RAII in C++.

const page_alloc = std.heap.page_allocator;
var arena = std.heap.ArenaAllocator.init(page_alloc);
defer arena.deinit();
const alloc = arena.allocator();

This handy little function will make a copy of any value given to it by first allocating a chunk of memory the size of the given value and then assigning the value to the "dereferenced pointer".

Zig duck typing is great! Notice that I'm not specifying the type of value (anytype) and telling the Zig compiler to use the type of the value given ( TypeOf(value))

pub fn exprWalker(T: type, E: type) type {
    return struct {
        context: T,
        walker: Walker,

        const Self = @This();

        pub const Walker = *const fn (*Self, *Expr) E!bool;

        pub fn run(self: *Self, node: *Expr) E!void {
            if (try self.walker(self, node))
                return;
            switch (node.*) {
                .binary => |binary| {
                    try self.run(binary.lhs);
                    try self.run(binary.rhs);
                },
                else => {},
            }
        }
    };
}

Zig comptime generics at work here.

The exprWalker function returns a new type parameterized on the context and error types supplied to it.

The Walker type is a function that will do the heavy lifting. The expression walking machinery will abruptly stop if the function tells it that this expression has been handled. Otherwise, It will happily recurse into nested expressions.

Zig pattern matching using switch is not as advanced as in OCaml but perfectly serviceable. Finally, {} is an empty block.

fn sumup(node: *Expr) Error!usize {
    const Context = usize;
    const Walker = exprWalker(Context, Error);
    const walk = struct {
        fn walk(self: *Walker, expr: *Expr) Error!bool {
            switch (expr.*) {
                .int => |i| {
                    self.context += i;
                    return true;
                },
                else => {},
            }
            return false;
        }
    }.walk;

    var walker = Walker{
        .context = 0,
        .walker = walk,
    };
    try walker.run(node);
    return walker.context;
}

Here const Walker = exprWalker(Context, Error); instantiates a new Walker that's parameterized over the Context and Error types.

The walk function then looks for ints and sums them up, storing the sum in the context.

There are no closures in Zig but you can sort of kind of emulate them by returning a struct with a function inside it.

That's it!