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/rf...