Why Building a Compiler Makes You Better at Building Compilers
There’s a counterintuitive truth I’ve discovered while building Prove’s self-hosted compiler: starting from zero isn’t slower than starting with a head start. It’s faster.
Not immediately, of course. The first months were brutal. Every bump in the road felt like fighting the machine. But then something shifted. Problems that would have stumped me a year ago now resolve in minutes. Not because I’m smarter — but because I’ve trained myself to think in a different dimension.
The Problem With Borrowed Solutions
When you build on top of existing infrastructure, you’re constrained by the decisions others made. LLVM is incredible, but it comes with assumptions. GCC is powerful, but it’s shaped by decades of legacy. These tools optimize for what came before — and what came before wasn’t designed for what you’re trying to do next.
I started Prove with a clear vision: an intent-first language where code can’t lie. But as I moved toward self-hosting, I hit walls. The existing compiler infrastructure wasn’t built for what I needed. Every workaround felt like technical debt accumulating in real-time.
So I built from scratch. And slow but predictable, every problem I solved became a tool I could reuse.
The Feedback Loop
When you write code from scratch, you get a unique feedback mechanism. The compiler is the product, but it’s also the proof of concept. Every limitation you hit is a signal — this needs to be simpler, more expressive, more powerful.
This is similar to how self-hosting compilers have driven innovation in languages like C, Rust, and Go.
Let me give you a concrete example. Early in development, I needed to parse type annotations. The first implementation took a long time and so much thought put in, edge case handling, and debugging. When I finally got it working, I thought: “There has to be a better way.”
And there was. The problem I’d just solved taught me exactly what the language needed to express this elegantly. I added syntax that made type parsing trivial — and that same syntax made everything else easier too. What took three weeks the first time took three hours the second.
First types where simple, only the builtin types and my aim was to keep it as simple as possible. The pain of adding notations to every single thing is a very real burden for developers in strongly typed languages. This was my first “there got to be a better way” moment, lets make format command do it! If I have the types added somewhere in the chain that is parseable! Hence var = function() became var as String = function() when formatted and I just add a Info to the linter.
That’s the acceleration loop in action.
Problems as Opportunities
Here’s the mindset shift that changed everything: every problem isn’t a setback. It’s an opportunity to invent something new.
When you’re building something truly novel, you *will* hit problems that nobody has solved before. Most people see this as a sign to give up or pivot. I see it as the gift.
the next obstacle I ran into where how to manage IO and still keep as much as possible “pure”, the common way of doing this is (in my opinion) not meant for human eyes! This is when it hit me, “what” am I trying to do. Transform, Read, Create, Output, Input. AHA! Why do ugly things like adding `@annotation` to something called fn or function? It’s not like I don’t know what it is Im writing?! The only reason for those wasteful statements are not for humans, they are for the compiler to understand what it is!
This gave me the answer that no Stack Overflow/LLM answer could: deep, visceral understanding of the problem space. And now, whenever I encounter anything that can be simpler, I see solutions where I earlier would see obstacles.
The Compound Interest of Problem-Solving
Think of your brain as a compounding investment. Every problem you solve adds to your capital. The returns aren’t linear — they’re exponential. Early on, you have to build your foundation. But once you have enough context, new problems become variations on themes you’ve already mastered.
This is why I believe so strongly in starting from scratch when you’re building something genuinely new. The borrowed shortcuts might save time in the short term, but they rob you of the deep understanding that pays dividends forever. Of course this doesn’t mean every single thing needs to be novel. But spend a moment and think outside the box, its very rewarding!
What This Means for Prove
As Prove’s self-hosted compiler grows, I’m watching this acceleration happen in real-time. Features that would have taken months now take weeks. Weeks become days. The compiler eats its own tail — improving itself while also being improved by its own improvements.
The goal isn’t just a working compiler. It’s a compiler that makes building code easier and less bound to the big tech companies that own your compute time. Each iteration doesn’t just fix problems — it raises the floor for what problems are even possible to solve.
And that’s the real insight: starting from zero doesn’t mean starting from nothing. It means starting from first principles. It means every solution is genuinely yours, tailored to your specific needs, optimized for your particular vision.
The mainstream tools were built by brilliant people solving different problems than the ones we face today. Their solutions are generic by necessity. Yours can be precise by design. And if the glove fits for more people that is sugar to the cake!
—
If you’re building something new and feel stuck on whether to build on existing infrastructure or start from scratch — my advice: start from scratch. The learning curve is steeper, but the compound interest is worth it.
For more on why I started building Prove from scratch, see Why I Built My Own Programming Language.
And if you want to follow Prove’s journey as it builds itself, head over to prove.botwork.se. The acceleration is just beginning.
Leave a Reply