The history is this: back in the old days (2012), we used to store the entire Compiler Explorer state in the URL. That got unwieldy (who would have thought encoding an entire compiler state in a URL might get a bit long?), so we added support for Google’s link shortener goo.gl in March 2014. That meant short links were of the form goo.gl/abc123. Clicking a goo.gl link would eventually redirect you to the full URL link on our site, and we’d decode the state from the URL.
In 2016, Stack Overflow banned link shorteners because of how they cloak the actual destination of links. Abusers could post innocent goo.gl links that directed folks unwittingly to bad content. However, that meant our Compiler Explorer links were also affected. At the time, we had no intention of storing any user data, so we came up with a hack: we still used goo.gl, but we then rewrote the link we handed out to be godbolt.org/g/abc123 (where the abc123 is the goo.gl unique ID). We then redirected any hits to /g/abc123 to goo.gl/abc123, which then (finally) redirected back to godbolt.org with the appropriate state in the URL. If you’re keeping track, that’s three redirects to show you some assembly code. We were really committed to making things complicated. Later, we used Google’s API to avoid the redirection dance.
By 2018, the limitations of storing state in the URL started to bite. There’s a limit to how long a URL can be (and we’d already started compressing the data in the URL), so we needed a better solution. We finally implemented our own storage solution: we hash the input, save the state as a JSON document on S3 under the hash, and then give out a shortened form of the hash as a godbolt.org/z/hashbit URL. We use DynamoDB to store the mapping of shortened hashes to the full paths (accounting for partial collisions, etc.). And, amusingly, we check the short link’s hash for rude words and add deliberate extra information into the document until we no longer get a rude word. Yes, we literally check if your shortened URL contains profanity. Because apparently even random hashes can’t be trusted to keep it clean. This led to bug #1297, which remains one of my favourite issues we’ve ever had to fix.
Recently, I’ve been having what can only be described as a very meta relationship with AI1. I’m using Claude Code to help maintain Compiler Explorer, and in a delightful twist of recursive irony, one of the features I’m working on with Claude Code is… a Claude-powered assembly explanation tool. So Claude is helping me build Claude systems that use Claude to improve Claude prompts for Claude explanations. If that made your head spin, or made you worry, you’re not alone.
The idea was simple enough: many people can compile their code and see the resulting assembly, but understanding what that assembly actually does is often where the learning journey stalls. So I’ve been experimenting with an “Explain with Claude” pane that would take your source code, the compiled assembly, and compilation options, then ask Claude to provide a beginner-friendly explanation of what’s happening.
The implementation turned out to be beautifully recursive – I built a backend service (mostly written with Claude Code’s help) that crafts sophisticated prompts for a more capable Claude model, which then generates explanations delivered through a simpler, more cost-effective Claude model. It’s Claude all the way down.
This article was inspired after a long conversation with Claude during a dog walk. These are my ideas; but I did use AI to bounce ideas back and forth and help summarise a half-hour chat into a digestible form. I figured I should be up front about that, like I was in my last post.
I’ve been spending quite a bit of time with AI coding tools lately, particularly Claude Code from Anthropic. This has got me thinking about how AI is being perceived in the programming world – specifically the concerns many have about AI displacing entry-level programming jobs.
An analogy struck me that I think helps frame this change in a more constructive light: the semiconductor design revolution of the 1970s and 1980s.
The following code was written by Claude AI. I didn’t do any editing on it, other than telling it to use British spellings, and to add a couple of links. After a few hours of working getting the AI to do all the work I wanted I gave it this prompt:
A real challenge for you: can you write a blog entry now, in the 202504 directory. Make it
Status: Draftso I can take a look at it. Try and fit my tone, but note that “this blog post was written by Claude”. I will subsequently add a human-written prolog and epilog. The post should be on how you helped me modernise this blog system and how well the process went. Pick an appropriate name and title
And this is what it produced:
For a programmer, there’s a special kind of embarrassment that comes from maintaining code you wrote many years ago. My blog generator has been a perfect example of this: a Python codebase started in 2007 that’s somehow survived nearly two decades of neglect while continuing to function.
The eagle-eyed among you may have noticed a change in the way compiling using Microsoft Visual Studio compilers works on Compiler Explorer. Short version: we have gained execution support (yay), but lost library support (boo). We’re working on the latter.
So, what happened? In order to explain, here’s some background:
Compiler Explorer runs on Linux infrastructure. My day job for the last two decades has meant developing on, and for, Linux or Linux-based systems. As a result, CE itself uses Linux. When folks originally asked for Windows compiler support, I put it off for a while. A few years after, a friend helped me just about coerce and fudge a few versions of MSVC to run under WINE, but it’s not perfect and to this day causes us issues.
It’s been over a year since I updated my blog; and I’ve been making some pretty fundamental changes to the infrastructure I host it all on. So this is more of a test post than a hugely informative one.
That said; the reason I’be been making those changes is because, a couple of weeks ago I formed “Compiler Explorer LLC” as an Illinois-based corporation.
Does this mean Compiler Explorer is going to be a business now?!
Today is Compiler Explorer’s 10th Birthday:
commit 15ea5e164b55c2b5ee0d3b432e3984b8f361afd2
Author: Matt Godbolt <matt@godbolt.org>
Date: Tue May 22 21:07:40 2012 -0500
Initial import of GCC-Explorer
Ten years ago I got permission to open source a little tool called GCC Explorer. I’d developed it over a week or so of spare time at my then-employer DRW in node.js, and the rest, as they say, is history.
Like so many, I started a podcast – Two’s Complement – during the pandemic, with my good friend and colleague Ben Rady.
Some folks asked how we made it sound so “professional”, and so I’m sharing here how we do it.
Most importantly: get everyone to record their audio locally. Audacity is free and works perfectly for this. Make sure you test that you can’t hear each other’s sound in the mix. Start recording, make sure the right microphone is in use by tapping it and observing the wiggly lines and then get others to make noise and ensure you hear them but don’t see the wiggly lines on your side.
Matt Godbolt is a C++ developer living in Chicago. Follow him on Mastodon or Bluesky.