Introduction

Welcome to The Flint Book, the official guide to the Flint programming language.

Flint is a systems programming language that starts where most languages give up: on a microcontroller with limited RAM, no operating system, and no safety net. If your code works there, it should not fall apart the moment you move to a different board, a different chip family, or eventually a Linux target. That is the standard Flint is trying to meet.

use micro/gpio
use std/time

const LED_PIN: u32 = 25

fn main() -> never {
    let mut led = gpio.pin(LED_PIN).into_output()

    loop {
        led.toggle()
        time.sleep_ms(1000)
    }
}

That is a complete, working blink program for a Raspberry Pi Pico. No linker scripts. No C runtime setup. No GCC, no LLVM, no Makefiles. Just flint build and a UF2 file ready to drop on your board.

Why Flint Exists

The practical problem is simple: embedded development still makes ordinary work harder than it should be.

In MCU land, developer struggle is treated as normal. You fight an SDK before you touch your application logic. You inherit a vendor IDE because that is the only path someone tested. You switch chips and suddenly half your mental model no longer transfers. The language might be familiar, but the actual experience is not portable. The tools are not coherent. The abstractions do not line up. A lot of the work is not building firmware, it is surviving the environment around it.

Flint exists to fix that.

The goal is a language and toolchain that take embedded constraints seriously without making developers miserable in the process. Safe by default. Fast enough for real firmware. Small enough for MCUs. Pleasant enough that writing a blink program does not feel like an initiation ritual.

How We Got Here

Flint did not appear because there was a gap in the market and someone decided to fill it. It came out of the same frustration most embedded developers eventually hit: too much incidental pain, too much fragmented tooling, too much time spent learning the preferences of a build system or a vendor SDK instead of working on the device in front of you.

That backstory matters because it shaped the project from the start. Flint is not trying to be clever for its own sake. It is trying to remove classes of friction that developers have been told to accept for years.

The name matters too. A small piece of flint can kindle a fire. Fire is not only heat and force, it is also something cozy that brings people together. That is the idea here too: a language simple enough to pick up for a small project, capable enough to carry real firmware without collapsing under its own weight, and grounded enough to become a shared tool people gather around and improve together. Small is not the opposite of serious. A tool can be compact, sharp, and still do real work.

What Flint Optimizes For

Several ideas shape every decision in the language, the compiler, and the standard library:

MCU-first design. Flint starts from the hardest environment first: bare-metal systems with tight memory, no OS, and no room for hand-wavy abstractions.
A self-contained toolchain. flint parses, checks, formats, generates code, and packages the final image. There is no hidden external compiler story underneath.
Memory safety without ceremony. Ownership is real. Lifetime annotations are not part of the user-facing language.
A language you can hold in your head. Flint is deliberately narrow. No macros, no user-defined generics, no async/await, no operator overloading.
One official library stack. The standard library, MCU APIs, HALs, and board packages are meant to grow together in one place.

This is also why developer experience is a first-day concern, not a someday concern. Flint is still young, but the specification is already solid enough to keep the compiler, documentation, syntax highlighting, and language server moving in lockstep. LSP support, autocomplete, diagnostics, formatting, and editor integrations are part of the foundation because a new language still has to feel good to use while it is becoming real.

For Us, By Us

Flint is not a product from a company. It is a language for the people actually building things with microcontrollers: hobbyists, professionals, tinkerers, and anyone else tired of being told that bad tooling is just part of embedded work.

The whole stack is open source. The compiler, the standard library, the HAL, the board packages, the language server, the editor extensions, the docs. All of it. If a driver is missing, the answer should be that the community can add it. If board support is incomplete, the path to fixing it should be clear. If the editor story is rough, that is part of the product, not an optional extra.

That is the point of the project. The people closest to the hardware should be able to improve the actual language and ecosystem they use, not maintain a pile of side projects around it forever.

How This Book Is Organized

Getting Started: install the compiler, write your first program, and learn the core CLI workflow.
Language Reference: types, ownership, error handling, pattern matching, traits, and the rest of the language surface.
HAL and Micro Library: GPIO, UART, ADC, PWM, I2C, SPI, DMA, and PIO through Flint’s official MCU packages.
Standard Library: core/* and std/*, the cross-target facilities that work everywhere Flint runs.
Targets and Boards: supported targets, support tiers, and board overlays.
Compiler Internals: how the pipeline works for readers who want the implementation story.
Tools and Editor Support: the language server, editor integrations, and the real-time developer workflow.

What Flint Is Not

Flint is not trying to be everything.

It is not a maximalist language with a feature for every taste. It is not a scripting language. It is not a borrow-checker-heavy research project. It is a focused language for writing clean, safe, fast firmware, with a clear path toward broader systems targets later.

That narrowness is deliberate. The aim is not to win every language argument. It is to build a tool that makes embedded development feel sane.

Flint is still under active development. The rp2040 target is the current primary platform and is real and usable today. The language surface, tooling, and target support will keep expanding from there.

Keyboard shortcuts