About epsilon86
Two decades of building software. A conviction that the craft deserves better tools.
Origins
epsilon86 grew out of more than twenty years of hands-on engineering, starting with a voracious appetite for learning and the potential to control what a computer actually does. I taught myself Visual Basic in the late 90s, then moved on to C, C++, Perl, PHP, C#, Kotlin, and x86/x64 assembly — each one chosen because the problem at hand demanded it.
I worked in the industry as a software engineer prior to pursuing an education in Computer Science, and what I found at the university level was dismaying. There was so little focus on practicality and technique in the real world — most students had no idea how to debug their own code. I dropped out after realizing the value of the education I was receiving was vastly overshadowed by the costs. Thus began a long stretch of building production systems in domains where failure wasn’t an option.
As an example, one project was creating a handheld barcode scanner app for an e-ticketing company, built on Windows CE. It was still running a decade later without a single reported failure. The architecture was unconventional enough that nobody who inherited it could quite trace the thinking. Not because it was complex, but because it solved the problem in ways they hadn’t considered.
I founded epsilon86 to bring that same approach to consulting: go deep on the problem, question assumptions, and build systems that last.
The Name
In mathematics, epsilon typically denotes an infinitesimal — a quantity so small it approaches zero but never quite reaches it.
The name is a statement of intent: we pay attention to the smallest details. The ones everyone else overlooks. The ones that determine whether a system is merely functional or truly reliable.
What We Believe
Computers, from a user perspective, have barely gotten faster. If anything, things are slower today than they were in the late 90s. Everything is System V and ABIs and dependencies and package managers. Layer upon layer of abstraction and compatibility hacks, all because nobody wants to innovate without backwards compatibility.
Modern hardware is insanely powerful. Every machine has multiple physical cores. And yet we run the same execution models, the same C function call conventions, the same fundamental patterns that existed decades ago. Nobody is taking a serious look at alternate models of languages, execution, or system architecture.
We think the right response is to step back and re-examine what is actually possible with what we have. The current way is not the only way.
Code is a form of art, and thus it should be elegant and refined. Programming languages should serve their authors, not the other way around. We believe artists should be as unconstrained as possible, and we aim to help make that happen.
What We Know
Our primary domains are Kin, Kotlin, C++, C#, and x64 assembly. We have deep familiarity across a variety of platforms and use cases too: DirectX 9 & 11, Windows Media Foundation, .NET and JVM platform internals, processor architecture, and multi-threaded systems that don’t break at runtime.
We gravitate toward problems where performance is the constraint. One of our most rewarding projects was a custom lossless 16-bit grayscale image compression system. It required a bespoke bit-packing algorithm with hand-tuned AVX2 assembly for both compression and decompression. We used Intel's VTune and IACA to profile and got the core loop to ~9 clock cycles per iteration, decoding at 2 GB/sec on an older Intel laptop. That kind of work — where the math, the architecture, and the hardware all have to come together — is where we do our best.
Our typical engagement starts with a generalized specification or a loose direction from someone with a vision. We work alongside them to refine the problem space and arrive at a working, efficient solution. We assume as little as possible and let the problem dictate the approach.
Kin
Every language has hard boundary limitations. In the JVM world, it’s type erasure for generics. Metaprogramming is virtually nonexistent in most languages, let alone done well. When a C# project demanded extreme performance, the path went from code generators via T4 templates, to C++/CLI, to hand-written AVX2 assembly. The language kept getting in the way.
Kin is the answer to that frustration. A programming language built from first principles, drawing on category theory and type theory — not to produce another academic exercise, but to make something real and functional and practical. It is the embodiment of everything epsilon86 stands for.
Kin is an open source project, and it always will be. epsilon86 is positioned to be the leader in building robust, world-class production systems in Kin. But we want to enable everyone else to do the same. We offer a wide variety of services to help you get started with Kin, including consulting, training, and support.