I built a compiled language to replace Bash and Python for CLI tools (and skipped malloc entirely)

#zig #devops #cli #showdev

If you write infrastructure tooling, CI/CD scripts, or general CLI utilities, you are probably trapped in a miserable trilemma:

Bash is great until line 50. After that, it becomes a minefield of silent failures, whitespace explosions, and string-parsing nightmares.
Python and Node.js have great standard libraries, but bootstrapping an entire VM/Interpreter just to parse a JSON payload or spawn a process adds unacceptable latency to fast workflows.
Go and Rust are incredibly powerful, but writing a quick 20-line script in them often requires massive boilerplate for basic I/O and process execution.

I wanted the functional ergonomics of data pipelines, but I wanted it strictly typed, AOT-compiled, and dependency-free.

So I built Flint.

The Architecture: Zig to C99
Flint is a transpiler written in Zig.
It reads .fl scripts, generates highly optimized pure C99 code, and links it via Clang into a standalone native executable.

But the real engineering decision was the runtime memory model.

Skipping the Garbage Collector (and malloc)
CLI tools have a very specific lifecycle: they boot, process data, and exit. Traditional Garbage Collection (GC) or manual malloc/free churn introduces unnecessary overhead for this specific use case.

Instead, the Flint C runtime boots by requesting a massive 4GB virtual address space directly from the Linux kernel using mmap(MAP_NORESERVE | MAP_ANONYMOUS).

Because no physical RAM is actually allocated at boot, this operation is practically instantaneous.

From there, every memory allocation in Flint is just a branchless pointer bump (arena_offset += size). The OS lazily pages in physical RAM via page faults only when the memory is touched.
When the script finishes, we don't bother freeing anything. The OS instantly reaps the entire memory mapping.

Result: Zero memory fragmentation, zero GC pauses, and startup times in the sub-10ms range.

The Syntax: Pipeline Operator
To make data processing intuitive, Flint uses the pipeline operator (~>). Data flows forward, eliminating nested function hell.

Under the hood, the compiler resolves a ~> b(c) into b(a, c) at compile time, meaning zero runtime overhead.

const username = env("USER");

# Execute a shell command and process the output natively
exec("ps aux")
    ~> lines()
    ~> grep(username)
    ~> join("\n")
    ~> write_file("user_procs.log");

AOT Structs vs Dynamic JSON Parsing
Parsing JSON dynamically in interpreted languages is slow due to hashmap lookups and reflection. Flint relies on Ahead-Of-Time (AOT) Struct Mapping.

When you define a struct, the Emitter generates a specialized, static C function that maps JSON keys directly to physical memory offsets.

struct GithubUser {
    login: string,
    id: int,
    hireable: bool
}

Native HTTP fetch with zero-cost inline error handling

const payload = fetch("https://api.github.com/users/lucaas-d3v") catch |err| {
    print("Network failure intercepted.");
    exit(1);
};

Zero-copy, AOT-compiled mapping from JSON to native C struct

const user = parse_json_as(GithubUser, to_str(payload));

print(concat("Developer: ", user.login));

Zero-Copy Strings

Strings in Flint are "fat pointers" (a pointer to the data and a length size_t). Slicing a string, reading a file, or splitting text doesn't copy the underlying bytes. It merely creates a new slice pointing to the original memory arena, making text processing operations O(1) in memory.

Try it out
Flint is experimental but highly optimized for its core use cases. The compiler source code is open, and I'd love to hear feedback from other systems engineers, compiler nerds, and DevOps folks.