DEV Community: ~K'

How do you feel seeing this diagnosis at 3:27 AM (compiler written in Zig)?

~K' — Sun, 29 Mar 2026 11:49:18 +0000

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

~K' — Wed, 11 Mar 2026 13:16:37 +0000

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.

Canonical Repository: https://codeberg.org/lucaas-d3v/flint
GitHub Mirror: https://github.com/lucaas-d3v/flint

Zemit — minimal release tool for Zig projects

~K' — Fri, 27 Feb 2026 22:49:09 +0000

Repo: https://codeberg.org/lucaas-d3v/zemit
Docs: https://codeberg.org/lucaas-d3v/zemit/src/branch/main/docs/
License: https://codeberg.org/lucaas-d3v/zemit/src/branch/main/docs/LICENSE

What it is
Zemit is a small, opinionated CLI to build and prepare multi-target releases for Zig projects.
The focus is on:

deterministic, reproducible outputs
human-friendly config (TOML subset)
explicit error messages
safe defaults (no partial publishes)
simple artifact layout (by-target / flat) with checksums

Key features (v0.2.x)

full config surface: [build], [release], [dist] (dir, layout, name_template)
checksums support (sha256 / sha512)
strict template validation (unknown variables = error)
deterministic CLI flow

Current status

v0.2.x: config parsing and validation are stable
v0.2.5: polishing done — stronger validation, safer outputs, clearer logs
v0.3.x (at the moment): porting Zemit from Zig 0.13.0 to 0.15.2
v0.4.x (planned): provider APIs (GitHub, GitLab, Codeberg)
v0.5.x (planned): optional parallel build mode

Why it exists
A lot of projects ship messy release scripts.
Zemit tries to replace that with a small, auditable tool that keeps things predictable and simple for maintainers.

How to try

git clone https://codeberg.org/lucaas-d3v/zemit

Read the quickstart: https://codeberg.org/lucaas-d3v/zemit/src/branch/main/docs/README.md#quick-start
Everything about the configuration file: https://codeberg.org/lucaas-d3v/zemit/src/branch/main/docs/config.md

Looking for

feedback on config ergonomics (TOML subset — does it feel intuitive?)
CI integration ideas (GitHub Actions, GitLab CI)
testers for Windows / Linux / macOS builds
help implementing provider adapters

I can also post a short demo run output or share a small binary if that helps.

Ambiguity Scales Worse Than Verbosity

~K' — Thu, 22 Jan 2026 19:04:26 +0000

When designing small scripts or short-lived software, implicit behavior often feels productive.

The language guesses your intent.
Defaults kick in.
Short syntax saves keystrokes.

Everything looks fine.
Until the system grows.

The illusion of productivity

Implicit behavior is often sold as convenience.
And in small contexts, it is.

But convenience scales poorly.

As systems grow, implicit behavior becomes:

silent assumptions

hidden contracts

multiple interpretations of the same construct

At that point, what once felt productive starts turning into:

bugs that are hard to reproduce

behavior that depends on context instead of intent

systems that are fragile by design

The problem is not verbosity.
The problem is ambiguity.

Ambiguity is not a syntax issue

Ambiguity is often treated as a stylistic choice.

It’s not.

It’s a design failure.

When a language allows:

implicit type conversions

inferred intent without explicit declaration

multiple meanings for the same construct

behavior that changes silently across contexts

It is no longer helping the developer —
it is guessing.

And guessing does not scale.

Why verbosity is not the enemy

Verbosity is visible.
Ambiguity is invisible.

You can refactor verbosity.
You can’t refactor assumptions you don’t know exist.

In long-lived systems, clarity is cheaper than cleverness.

Explicit code:

documents intent

exposes boundaries

survives team changes

survives time

Treating ambiguity as a design error

This perspective led me to work on Klar, an experimental programming language that takes a hard stance:

no implicit behavior

no inferred intent

no ambiguous constructs

no hidden boundaries between languages or contexts

If something matters, it must be stated explicitly.
If behavior is important, it must be written.

The language should not guess.

This is not about being beginner-friendly

Strictness is often confused with hostility.

Klar does not try to be friendly at first glance.
It optimizes for:

clarity

predictability

long-term stability

polyglot system boundaries

Learning curves are temporary.
Ambiguity debt is permanent.

Final thought

Implicit behavior feels fast — until it isn’t.
Verbosity feels slow — until you need to understand a system years later.

When designing languages or systems meant to live long,
ambiguity is more dangerous than verbosity.

If you’re curious, the project and its manifesto live 👉 here 👈

Designing Better Compiler Diagnostics — Lessons from building Klar

~K' — Mon, 19 Jan 2026 16:51:32 +0000

I’m building a small experimental language called Klar (formerly Klang) as a way to explore explicit semantics, strict diagnostics, and polyglot tooling. This is not a production-ready language — it’s a design exercise — but along the way I’ve been obsessing over one concrete problem: what makes a compiler error actually useful?

Below is a real example of how Klar currently reports an unresolved symbol error (trimmed for brevity). I’d love feedback on whether this format is too verbose, just right, or missing something important.

Example diagnostic (what the user sees):

[K:E217] UnresolvedSymbol
ERROR (SEMANTIC)
at undefinedVariableExceptionTest.kl:10:12

 8 |     }
 9 |
10 |     println(total);
   |             ^

Cause:
  The variable 'total' does not exist

Fix:
  Remove it or create it

The source that produced it (Klar .kl):

@Use("java")
public void main(){
    integer count = 10;
    integer iterator = 0;

    while (iterator < count){
        iterator = iterator + 1;
    }

    println(total);

    return null;
}

Design notes (short):

Diagnostics are structured as data first (error code + metadata) and rendered as readable text.

Short summary → precise location (file:line:col + caret) → human explanation → actionable fix.

I aim to avoid playful/friendly language in favor of clarity and predictability.

Suggestions should be conservative — “did you mean X?” only when the confidence is reasonable.

Questions for the community

When you evaluate a diagnostic, what matters most: precision, minimalism, or actionable fixes?

Do you prefer a single-line summary first (then details) or a single readable paragraph?

Are there diagnostic patterns you’ve seen that consistently confuse users?

I’m specifically interested in how diagnostics trade off between noise and helpfulness. If you want to see more examples (type mismatches, missing returns, magic-number warnings), I’ll paste them in the comments.

— ~K' (building Klar)