Back to browse
Flint – A compiled, pipeline-oriented language for CLI tooling

Flint – A compiled, pipeline-oriented language for CLI tooling

by lucaas-d3v·Mar 15, 2026·1 point·2 comments

AI Analysis

●●SolidBig BrainNiche Gem

Zero malloc churn via 4GB mmap arena—clever, but adoption is the real battle.

Strengths
  • Pipeline operator (~>) maps functional composition directly to C without nesting.
  • Zero-copy string operations via fat pointers eliminate allocation overhead.
  • Transpiles to dependency-free C99 binaries that boot in milliseconds.
Weaknesses
  • Another scripting language competing against Bash, Python, and Starlark.
  • Only 3 GitHub stars suggests limited community traction so far.
Target Audience

DevOps engineers, SREs, infrastructure developers

Similar To

Starlark · Just · Task

Post Description

Hi HN, I'm Lucas.

I write a lot of infrastructure tooling and got frustrated with the usual trilemma: Bash gets unmaintainable past 50 lines, Python's interpreter startup/bloat feels too heavy for fast pipeline tasks, and Rust/Go can be too verbose for simple OS-level scripting.

So I built Flint. It’s an experimental, statically-typed language written in Zig that transpiles directly to C99, compiling down to a dependency-free native binary. It is strictly designed for DevOps, SRE, and CLI automation.

Some of the core engineering decisions:

1. The Pipeline Operator (~>): Data flows forward. No nested function hell. It’s functional composition mapped to C. 2. Memory Model: Zero garbage collection and zero `malloc` churn. It uses a 4GB virtual arena via `mmap(MAP_NORESERVE)`. Scripts boot instantly and die cleanly. 3. Zero-Copy Strings: Strings are fat pointers (ptr + len). Operations like `split()` or `lines()` are just memory slicing, which drastically speeds up parsing large logs or JSONs. 4. OS-Level I/O: We bypass User Space bottlenecks where possible. The `copy()` function delegates directly to the `sendfile` syscall. Process orchestration uses `posix_spawnp` instead of expensive `fork()` cloning. 5. Explicit Errors: Inspired by Zig, I/O operations require an explicit `catch |err|` block. No silent Bash failures.

A quick example of what a log parser looks like: ```flint const raw_logs = read_file("server_access.log") catch |err| { exit(1); };

raw_logs ~> to_str() ~> lines() ~> grep("403 FORBIDDEN") ~> join("\n") ~> write_file("threat_report.log") catch |err| { exit(1); };

```

Trade-offs & Current State (v1.7.1): It is NOT a general-purpose language. It lacks a garbage collector by design (long-running daemons will eventually exhaust the arena). I'm currently working on a deep-walk semantic analyzer to enforce proper namespace isolation for the upcoming v1.7.2.

I would love brutal feedback on the architecture, specifically the Zig-to-C99 transpilation pipeline and the arena implementation in the C runtime.

Repo: https://codeberg.org/lucaas-d3v/flint Mirror: https://github.com/lucaas-d3v/flint

Similar Projects

Developer Tools●●Solid

Lockstep – A data-oriented programming language

Compiler-enforced branchless SIMD execution guarantees vector saturation without runtime checks.

Big BrainNiche Gem
goosethe
863mo ago
Developer Tools●●Solid

Lumina – a statically typed web-native language for JavaScript and WASM

Built-in reactive runtime and dual JS/WASM targets challenge React and TypeScript dominance.

WizardryBold Bet
light_ideas
202mo ago

A New Programming Language

Endianness in the type system is clever, but another language in a saturated field.

Niche Gem
kvthweatt
403mo ago