Geblang - I built my own programming language

💡 I wouldn't normally feel the need to say this, but because this post is about a project that was build with AI coding tools as a core part of the workflow, I just want to make it clear I don't use AI to write my blog posts. Not a word. The text of this page is entirely authored by me, a living, breathing human.

Introduction

Programming's a funny thing. You can solve so many problems in so many different ways that if you were to ask any number of developers what their ideal programming language would look like and how it would work, you'd probably get as many different answers as people you asked.

Any programming language I've worked with in my life, I've felt has been great for some things and lacking in others. Java I wish was less verbose, more flexible, more user friendly. Python I wish had a real typing system instead of erased syntax left to community tooling. PHP I wish could support operator overloading, generics and native async/await behaviour (and I don't mean the Fibers API).

But there are many things about these languages and others that I love. When it comes to PHP and Python in particular, I love a lot of the ergonomics and ease and simplicity of development they give you, right out the box. The rich standard libraries, PHP's Java-inspired OOP models, Python's elegant syntax and support for aspect-oriented programming.

I've always dreamed of creating my own programming language that I could use to write programs the way I want to and manifest that concept of what my ideal language would look like.

But I'm not an expert on building compilers or interpreters. I have some theoretical knowledge on that subject, mostly from a book I read many years ago, it's not something I ever thought was realistic for me to achieve, at least in a real sense - a sense of a working, feature-complete language that goes beyond a basic learning exercise. Something you could actually use for real projects.

Then we entered the era of cutting-edge coding models, which have moved on from intelligent autocomplete in the IDE to (with a lot of caveats, of course), full agentic development systems.

I wanted to push what I could do, leveraging these tools, to its limits. Could I actually build a real, fully functional programming language, not in 2-3 years, but in a couple of months?

Thus Geblang was conceived, and later born.

Why does Geblang exist?

Fun, interest, curiosity and learning.

The name, of course, is a pun on how Go is commonly known as Golang. My name's Gebler, so Geblang seemed an obvious choice. G++ would have been more than a little confusing.

I wanted to learn Go (I knew a little bit about Go, but not much), I wanted to learn more of Go in a way that was fun and exciting to work on. I wanted to learn more about how a programming language is built. And as I mentioned above, I wanted to see just how far I could push the latest coding models to help me achieve these goals.

Geblang is predominantly inspired by PHP and Python, but also some of Go itself, in which the reference implementation is written.

So the aim, going back to my conception of an ideal language, was to offer the same benefits of PHP and Python in terms of ease, simplicity, low entry barrier and developer experience, but with the benefits those dynamic languages have historically struggled to offer and now are caught trying to play catch-up. My main goals to that end were full static typing and type safety (but with the option to break out into more dynamic structures), with static analysis built into the engine at runtime, a reified generics system that can be checked and enforced at runtime, and cooperative async programming as a day one, native feature.

Finally, all of this needed to be wrapped in something that was plausibly useful for real-world development. In other words, not painstakingly slow, not just a toy.

Matching CPython and PHP's performance is not a goal (and with PHP's JIT, it wouldn't be a realistic goal), I was just aiming for...fast enough, for an interpreted language. So I knew from the start I'd want a VM with bytecode compilation and caching and I figured I could always design it so we fall back to an interpreter if the VM can't support something yet (which is exactly what Geblang 1.0 does).

So it was vibe coded? This is a vibe coding project? AI Slop?

Depends what you mean by vibe coding. This is a term that conventionally (by which I mean about 12 months ago, when it was first invented) referred to a style of development where you just start coding without any planning or design, maybe without any knowledge of programming at all, don't look at the code, don't understand the code, don't tweak the code. Just throw a prompt at an LLM and say "one programming language please" and then plead with it to fix any issues until the result kind of appears to work.

If that's what you mean by vibe coding, then no, this is not a vibe coded project.

On the other hand, some people today use vibe coding to mean any project where the actual code was, in whole or in part, written by AI coding models.

In the case of Geblang, I absolutely did use a heavily AI agent oriented workflow. But I also had control every step of the way not just in designing the specification of the language I wanted, but in architecture, in form, in function, all the things that really matter. I relied on the models to do the heavy lifting of writing Go code, much faster and probably much better than I can, and to present me with options and recommendations about various things along the way for me to evaluate and feedback on. I audited the outputs, tested the output, course-corrected, changed direction when I felt the models weren't getting it right.

If that's your definition of vibe coding, then yes it is a vibe coded project. But if that's your definition of vibe coding, I would contend vibe coding is not a bad thing. It's best case a good thing and worst case a neutral thing.

But hey, I get it. Some people vehemently detest AI to the extent they automatically won't use and won't consider any software where AI has been involved. If you fall into that category, that's fine, Geblang's not for you.

Of course, I am not claiming the architecture I designed, or the software produced by it, is good. Hell, it might be terrible, but if it is that's not AI's fault, that's my fault as the designer, architect and decision maker for giving the AI bad decisions. The tools I used were just tools, used to generate code quickly according to a spec. This is my first foray into building an interpreter, I'm not saying I did a great job.

I've no doubt it has plenty of bugs, as do programming language implementations written by countless people more qualified than me in that discipline.

Regardless, I'm not putting Geblang out there as a masterpiece, proudly announcing that I've built the next Rust-killer or something. It's a project that exists for learning and fun. You should use it for learning and fun.

Whatever your opinion on AI coding tools, the Go source for Geblang is open source and available on GitHub, so you can check it out and see for yourself how it was built, how it works, and what it's like.

Development process

Geblang was built in a series of phases and I used a mix of OpenAI, Anthropic and local models. Plus, believe it or not, some manual coding and code editing.

First part, obviously, was I defined and designed the language spec I wanted (the first draft of it, anyway). I shaped what I wanted a typical Geblang program to look like, what features I wanted, shape of the syntax, core functional requirements.

I designed an initial architecture sketch, for the lexer, parser, AST, evaluator, bytecode compiler and VM. I designed some of the initial standard library and the specification for a REPL tool.

I wanted to test as I went along, both with automated tests and real-world Geblang script examples, so I ensured I provided the models with clear guidelines for test requirements, with examples to base on.

From there, it was an iterative process. I tried to follow a mini, one-man Agile philosophy, working software at each individual increment.

I read more about compiler and interpreter design and Go, so I could feedback ideas to the models to guide the development direction the way I wanted. As you'd expect with an agentic workflow, there were countless occasions I had to catch mistakes, tell the models to take a different approach, etc.

But the more the code evolved and the more I was able to refine agent bootstrap and memory, the easier the models found it to work with and build on top of what was already there, to stick to conventions and to optimise where code I'd written or a design I'd proposed had their shortcomings.

I am sincerely blown away by how far coding models have come in just the space of a couple of years. I first tried Github Copilot in 2023, when it was the height of sophistication in this field and not much more than an intelligent autocomplete. The first truly generative models that I tried produced code that was often completely unusable, and even when it was usable, riddled with bugs and security issues.

I understand why so many people have the reservations they do about AI coding tools, but I also think these days they have incredible potential, provided they are used responsibly. Building Geblang is the largest AI-driven undertaking I've ever done. I've learned a lot more Go, I've learned things about interpreter design I didn't know and I'm happy with that as an outcome.

How Geblang bridges the PHP/Python gaps

I've gone into this in more detail in the docs, but in a nutshell, Geblang is:

• Single inheritance, multiple interfaces
• Static typing with optional type inference, plus a special any type for dynamic values.
• Reified generics with runtime checks and enforcement, and full runtime introspection/reflection.
• Cooperative async programming with async functions and await expressions.
• Operator overloading with Python-style dunder methods.
• Aspect-oriented programming with Python-style decorators.
• Pattern matching with match statements and destructuring.
• A decent (kind of decent?) "batteries included" standard library, with extra focus on web tooling.
• A bytecode VM with an interpreter fallback for unsupported constructs, and on-disk bytecode caching.
• A REPL, a built-in HTTP server, and a test runner with support for test tags.
• Built-in static analysis, linting, formatting, LSP and DAP.
• A syntax inspired by Python, but with some of the more familiar constructs from PHP and Go, like curly braces and semicolons.
• Many more features that I won't list here but you can find in the docs.

From the docs, here is a short example of a Geblang script using a variety of typical features: (forgive the lack of syntax highlighting, I should probably vibe code a plugin for my blog to support Geblang)

import io;
import collections;

interface Scored {
    func score(): int;
}

@immutable
class Player implements Scored {
    string name;
    int rating;

    func Player(string name, int rating) {
        this.name = name;
        this.rating = rating;
    }

    func score(): int {
        return this.rating;
    }
}

func topBy<T implements Scored>(list<T> items): T {
    return collections.maxBy(items, func(T x): int { return x.score(); });
}

let players = [Player("Ada", 10), Player("Grace", 12), Player("Linus", 7)];
io.println(topBy(players).name);   # Grace

Try it out

If you're curious, you can get up and running with Geblang in 5 minutes. All you need is either Go (1.26.3) installed on your machine, or Docker.

Geblang includes a VS Code extension out of the box for syntax highlighting, code completion and step debugging (these require the Geblang binary to have been built first).

I also included some really simple benchmark tests that can be run against Python and PHP (make bench-docker). They only test a few simple things - looped integer arithmetic, recursion and list iteration. Obviously take these with a pinch of salt as to how informative they are, but as I say, Geblang never aimed to beat PHP at any of these things. If anything I'm pleasantly surprised at how far I've managed to optimise the performance - early benchmark results were much further apart than they are now!

There are docs including typical example code in the Github repo, I also have a published docs site acting as a reference manual which you can find below.

• Geblang Reference Manual
• Geblang Github Repository