Micron: a high performance C++23 (re)implementation of Libc and the STL
Howdy HN, I've been working on micron for quite some time now, and I've finally gotten it to a state where I'm ready to share it with other people. I've really been pruning and testing it quite heavily for the past few weeks looking to flush out any bugs/inconsistencies. micron is a header-only C++23 core systems library that runs on Linux without libc, without libm, without the STL, and without any external dependencies at all. Fully freestanding. To my knowledge this is probably the only project of this kind, and the only libc implementation not in C. There _might_ be some Rust libc…
What it does
In the maker’s words, at launch
Howdy HN, I've been working on micron for quite some time now, and I've finally gotten it to a state where I'm ready to share it with other people. I've really been pruning and testing it quite heavily for the past few weeks looking to flush out any bugs/inconsistencies. micron is a header-only C++23 core systems library that runs on Linux without libc, without libm, without the STL, and without any external dependencies at all. Fully freestanding. To my knowledge this is probably the only project of this kind, and the only libc implementation not in C. There _might_ be some Rust libc variant out there but I couldn't find any. Why does this exist? The STL makes a lot of decisions I disagree with; favoring generality over performance, safety theater that doesn't actually help anyone, ABI stability over bringing novel features to the language (regex, filesystem && company), and generally either being outdated compared to standard libraries of other languages or shipping solutions that are low performance (usually both). I wanted a library that treats the developer as the expert and makes development genuinely _simple and fun_. Every container in micron was written with that in mind. Most algorithms have hand-rolled SIMD loops wherever the math allows it, across amd64 (up to avx512), AArch64, and ARMv7 NEON. The other reason is hard determinism and portability sanity. glibc is _obscenely_ bloated, making it painful to compile quickly, painful to port, and painful to reason about. Half of Linux distros don't properly ship cross-arch libc; the ones that do are often missing static versions; and just getting a truly static binary out of glibc is a battle all its own (Fedora doesn't even _ship_ static libc properly in their official repos because security). Cross-compiling for ARM32 on an amd64 host is a special kind of misery if you're depending on the system libc. micron eliminates that entire class of problem. There's a single flat source, header only, and you're done; same code, same behavior, whether you're targeting a server or a microcontroller-class Linux board. Performance wise _most_ implementations in this library are either on par with the Standard Library (for things that can't be meaningfully sped up like container accesses) or greatly faster, near bleeding edge of what is out there. (one little side note is that right now most math kernel implementation code is more or less hardcoded for avx2 chips, there's no avx512/avx10 layer, so if you have a super modern cpu you won't get maximal performance over there). As of right now, the library is _almost_ feature complete (at least to the point where I'd like to have it). There's a full linux sys layer (maps more or less all syscalls, the ones that aren't you have a full syscall table so you can call them whenever ie. syscall(SYS_*, ...)), full math implementation, containers (contiguous, maps, trees, sets, heaps, queues), strings, a full simd layer port (for amd64 + arm neon), concurrency (mutexes, atomics, threading), io, functional programming primitives, a semi complete gfx layer (OpenGL/Vulkan)... micron also ships with a full memory allocator inlined, so you don't need to depend on anything externally. micron currently supports amd64/i386/aarch64/arm32 ONLY and is Linux ONLY. It might run on macOS, but no guarantees on that since too many things right now are effectively Linux hardcoded. Oh and you probably want at least kernel 5.0+ (5.11+ for certain fns) just to be safe. Didn't test it on anything older. A true final note is that this isn't really as polished or professional as glibc _yet_. I'm still working on ironing out any defects, the library is generally stable but you _might_ run into edge case issues especially around cross-arch code or the less tested paths. source: https://github.com/rfgplk/micron.cpp Happy to answer questions about any of the internals. Thanks!
Does the same job
all alternatives →
- MMMicro-mitten – Research language with compile-time memory management2020 · github.com · ▲236
I've been working on implementing the compile-time approach to memory management described in this thesis (https://www.cl.cam.ac.uk/techreports/UCAM-CL-TR-908.pdf) for some time now - some of the performance results look promising! (Although some less so...) I think it would be great to see this taken further and built into a more complete functional language.
- MMMy microkernel-based OS built from scratch now has basic Unix commands2024 · github.com · ▲69
This project contains no code from Linux, BSD, Minix, or any other OS. Everything up until this point is written entirely from scratch, including a pure microkernel (that only implements multiprocessor priority scheduling, memory management, and interprocess communication), a work-in-progress implementation of the standard C library, and a variety of servers that provide drivers and other essential OS functionality. At the time of writing this post, the servers provide drivers for the keyboard, NVMe SSDs (that works on real hardware), a Unix-like virtual file system (with a single root…
- FRFast Random Library for C++172025 · github.com · ▲52
Morning HN. Random number generation feels is a somewhat underrepresented topic in the C++ realm. There is a lot of questionable info about it found online and even the standard library is quite behind the times in terms of it's algorithms. It suffers from trying to accommodate sometimes impractical standard requirements and has several ways of getting significantly bad statistical results. This leaves a lot easily achievable performance & quality on the table. So, being a mathematician who mostly works with stochastic models and wants these models to run fast and well, I embarked on a…
- CACoros – A Modern C++ Library for Task Parallelism2024 · github.com · ▲129
Hello Hacker News. I’m Martin, a graduate student from Prague, and I’ve been working on Coros, a C++ library for task-based parallelism. After spending some time with OpenMP and oneTBB, I wanted to try building a library using modern features from the C++ standard library. I’ve used coroutines for task encapsulation and C++23 expected for exception handling, while trying to maintain good performance. Additionally, I’ve implemented monadic-like behavior to allow easy chaining of tasks, similar to the monadic operations in std::expected. You can check out the project here:…
- IBI built a minimal Forth-like stack interpreter library in CSep 2025 · ▲47
This weekend I created stacklib.h - a single-header library that brings Forth-style stack operations to C. It implements a basic interpreter with: - Stack operations (push/pop/dup/swap/over/drop) - Arithmetic (+, -, *, /) - Output (., emit, cr) - Stack inspection (.s, depth) Example usage: Stack s; stack_init(&s); dict_init(); exec(&s, "10 20 + ."); // Prints "30" exec(&s, "1 2 3 4 .s"); // Shows stack contents The library is self-contained, requires no dependencies, and handles basic error checking. It was inspired by wanting to understand…
More dev tools this month
the category →
Open-source GTM skills for technical founders
Dev tools · 29d ago · gtmcofounder.com
OpenTrailPaper is open-source bike computer firmware for the LilyGO T5S3 4.7" E-Paper PRO. It supports offline maps, GPX routes, FIT recording and Bluetooth sensors.
Dev tools · 2d ago · opentrailpaper.com
Launched alongside, June 2026
the whole month →
Fundraisly▲1,544AI fundraising agent that finds investors and books meetings
AI · Jun 2026 · fundraisly.com
- H6Homebrew 6.0.0▲1,481
Today, I’m proud to announce Homebrew 6.0.0. The most significant changes since 5.1.0 are a new tap trust security mechanism, the new faster, smaller, default internal Homebrew JSON API, sandboxing on Linux, better defaults informed by our user survey, many brew bundle improvements, improved performance and initial support for macOS 27 (Golden Gate). Happy to discuss any questions here!
Dev tools · Jun 2026 · brew.sh
- PU
hope you enjoy
Life & fun · Jun 2026 · vorpus.github.io
- IM
Life & fun · Jun 2026 · hackernewstrends.com