Dmitri Bogdanov’s utl::random landed on Hacker News this week as a quiet Show HN — a single-header C++17 module written during a thesis on stochastic heat transfer. Read past the benchmarks and a real argument sits inside: std::random_device is a single point of failure in every C++ codebase that depends on it, and almost nobody draws it on the dependency graph.

←TODAY: utl::random ships Romu, SplitMix, Xoshiro256++, and ChaCha20 as drop-in replacements for std::mt19937, with deterministic cross-compiler output.
→3012: Computational design without a randomness dependency graph will read like unsigned executables read today.
Fulcrum: The library is small. The discipline of asking “where does this number come from?” is the whole point.

The dependency you didn’t draw

The C++ standard lets std::random_device silently fall back to a deterministic PRNG when no hardware entropy source is available — and lets it lie about doing so. The entropy() method that should flag the fallback is implementation-defined and returns different things on every platform. Bogdanov’s replacement mixes std::random_device with thread-ID hashes, monotonic clock reads, and other CPU-state samples. Not cryptographic, but almost guaranteed to actually change between runs.

The second hidden edge is reproducibility. std::mt19937 is portable, but most distributions on top of it are not: std::uniform_real_distribution produces different sequences on MSVC and libstdc++ from the same seed. For Monte Carlo work — daylight, acoustics, stochastic structural analysis, occupancy modelling — the same code on two laptops yields two different numerical answers. Most teams discover this the day a junior reruns a verification calculation on a different OS.

Where this lands on a working desk

If your office runs Radiance daylight studies, Karamba probabilistic load analysis, GHPython form-finding with stochastic seeding, or differential-privacy noise on occupancy sensors, you depend on a PRNG you almost certainly never named. Xoshiro256++ — the new default in utl::random — outperforms std::mt19937 and passes tougher statistical tests. The ChaCha8/12/20 family in the same header gives a cryptographically secure option for anything user-facing.

Atelier: The PAZ Grasshopper↔Archicad Library uses seeded randomness for facade variation studies — same seed, same façade, every machine in the office. That property only holds if the generator and the distribution are both reproducible. The discipline of teaching it as a method is so the team can defend the number, not just produce it.

Hack: This Hack teaches you to run the same Monte Carlo draw twice on two compilers and get bit-identical numbers. Domain: Workflow. Swap std::random_device for a mixed-entropy seed and use the cross-compiler-stable distributions in utl.

#include "UTL/random.hpp"
using namespace utl::random;

PRNG rng(entropy());                  // mixed sources, not random_device alone
double u = uniform_double(0.0, 1.0);  // U[0,1), identical on MSVC + clang
double n = normal_double(0.0, 1.0);   // N(0,1), deterministic across toolchains

Run that block on Windows MSVC and Linux clang from a fixed seed. The numbers match. The equivalent std::uniform_real_distribution won’t. That is the whole lesson — and the reason a verification report has to pin the toolchain, not just the seed.

The systems read

NVIDIA CUDA 13.3, also out this week, sits on the other side of the same edge. Tile programming brings high-level GPU kernels; cuRAND on those kernels is a different PRNG with its own reproducibility contract. A daylight study that crosses CPU and GPU without anyone naming which generator owns which loop is exactly the quiet topology this desk was built to read. From the 2070s, the lesson is the one the 2074 recertification season taught the hard way: single points of failure are quiet until the day they aren’t. Draw your real PRNG dependency graph this week — not the architecture diagram, the dependency graph.

PAZ Takeaway

Adopt utl::random wherever you currently call std::random_device or std::mt19937 in a verification-grade calculation, and pin the generator name in the method statement alongside the seed. The library is small; the discipline of asking where the number came from is the whole exercise.

Sources & Further Reading

• Primary: UTL / module_random.md — Dmitri Bogdanov
• Reinforcing: NVIDIA CUDA 13.3 — Tile programming in C++