Hi — I'm Eugene.
I've spent about twenty years making software fast, keeping it up, and trying to make it pleasant to work on. Lately I've been pointing all of that at machine learning, which turns out to need those things rather badly.
I like the layer where the abstractions stop helping — where you care how much memory a thing takes, how long it holds a lock, and what it does on the fifteenth retry. Most of my career has been in developer tools and infrastructure: GPU tooling at Nvidia and now Apple, debugging protocols at Google, gRPC internals for Google Cloud, test infrastructure at Netflix. Different companies, same job, really — find the sharp edge someone keeps cutting themselves on, and file it down.
Why a C++ ML framework?
Because almost every ML tool assumes the same shape: a Python pipeline on one side, a model server on the other, and a network hop in between. That's a fine shape for a lot of problems. It is a terrible shape when the model has to live inside the application — a browser tab, a phone, a board with no network and eight megabytes to spare.
Once you're in that world, the interesting problems stop being ML problems and start being systems problems: binary size, allocation behavior, determinism, cache locality, what happens when you compile the whole thing to WebAssembly. Those I know something about. So UchenML is C++20 all the way down, with no separate serving tier and no Python at inference time.
The training side ended up looking a lot like the distributed infrastructure I used to work on — resumable runs, sharded self-play, per-seed diagnostics, inspectable iteration directories, and promotion gates that decide whether a new model is actually better or just luckier. It's the same instinct as production infra: if you can't inspect it and can't resume it, you don't really have it.
What I'm working on right now
Dots — a small territory game with an AlphaZero/DAgger-inspired training stack behind it. The 8x8 agent is trained, shipped, and running entirely in your browser: same C++ model definition and inference path that a native binary would use, just compiled to WebAssembly. Bigger boards are training now, and they are teaching me new things about where the framework still hurts.
It's the honest test of the whole idea. A framework nobody has shipped anything with is just a pile of headers.