Linux Dev on Rust, OSS and Rewriting SQLite

Rust’s future in the Linux kernel hinges less on a generational “attrition” plan and more on whether Rust can prove itself in the hardest, most failure-prone parts of the system—especially drivers—while the community figures out what “good Rust-in-kernel” looks like. Globber, CEO of Turso and a longtime Linux core contributor, describes the current Rust-for-Linux friction as a lack of shared expectations: whether Rust should live inside core kernel modules or act as a boundary layer, whether patches must keep Rust builds green, and how much churn is acceptable. That ambiguity has fueled confusion, harsh mailing-list debates, and resignations—yet he argues the chaos is also familiar to Linux, where organic evolution often beats top-down planning.

In his view, Linux’s culture is both the problem and the reason Rust can succeed. The kernel community runs on intense scrutiny: patches get hammered by thousands of eyes, and maintainers often demand sweeping changes rather than accepting “small” submissions. That directness can be exhausting and drives some contributors away, but it also functions like a brutal continuous integration system—bugs get found quickly, and ideas that survive the conflict tend to be genuinely useful. He compares the current Rust debate to past “viscerally opposed” directions in Linux that later became mainstream, citing virtualization and async system calls as examples of ideas that looked unacceptable at first but eventually won acceptance once they demonstrated value.

Rust’s strategic opening, he says, is not to rewrite everything immediately, but to improve the margins where C code quality is weakest: device drivers. Drivers often lack the kind of real-world testing that core subsystems receive, because only small numbers of people run those hardware paths. That environment can leave “substandard” code to persist. Rust-for-Linux contributors, in his telling, are aiming to use Rust’s safety properties to raise the baseline in those areas—starting where memory safety matters most and where incremental wins can accumulate.

The conversation then pivots to Turso’s work rewriting SQLite into Rust (Limbo) and how that effort mirrors the Linux community’s creative model. Globber criticizes SQLite’s development model as “open source but not open contribution,” maintained by a small group with a proprietary test suite that limits external verification. Turso forked SQLite (LibSQL) to enable community contributions, but the fork’s architecture and testing constraints made deeper changes hard. By December 2024, the rewrite could read SQLite databases correctly, and the project’s public momentum accelerated sharply: thousands of GitHub stars and dozens of contributors, with people joining specifically for the “blank canvas” of a full rewrite.

Quality is the central requirement, and the rewrite’s differentiator is deterministic simulation testing. Instead of relying on a traditional monolithic test suite, the approach uses a simulator plus fuzzing to control nondeterminism (timing, IO, interrupts) and reproduce failures exactly. Property testing checks invariants like database integrity; when corruption appears, the simulator’s determinism lets developers trace the precise sequence of faulty IO interactions that caused it. He argues this can replace the “mythical” SQLite test suite by making rare, timing-dependent bugs reproducible and fixable quickly.

Finally, he connects this engineering philosophy to LLMs: LLMs can accelerate boring or laborious coding tasks and help with ideation, but maintainers must still scrutinize outputs. The best use is asking an LLM to generate code for a specific task while humans remain responsible for correctness, architecture, and testing—much like Linux maintainers do when reviewing contributions from the broader world.