The eight year anniversary of Writing An Interpreter In Go is coming up. This year again, just like every time I look back to November 2016, I find myself thinking: man, I’m glad I used Go for these books.
Look:
$ wget 'https://interpreterbook.com/waiig_code_1.0.zip'
$ unzip waiig_code_1.0.zip
$ cd waiig_code_1.0/code/04/src/monkey/
$ GO111MODULE=off go run .
Hello thorstenball! This is the Monkey programming language!
Feel free to type in commands
>>
Contained in that waiig_code_1.0.zip
is the code from the very first release of Writing An Interpreter In Go. Code written in 2016 using Go 1.7, frozen in time — compiling and running today, using Go 1.23. No warnings, no errors.
Just as impressive, I think: the code in the books has barely changed since then. I had to fix some typos and bugs over the years, but really the only change I had to do in order to keep the code up to date was to drop a three line go.mod
in there, so that users with G 1.13 or later don’t have to use the GO111MODULE=off
environment variable. I added the go.mod
in 2020, four years ago and four years after the original release.
I had a hunch that Go would be good choice. Here’s what I wrote in an introduction section called Why Go?:
I’d bet that you can follow this book along even if you’ve never written a single line of Go in your life.
Or about the Go tooling:
The focus of this book is the interpreter we are writing - the ideas and concepts behind it and its implementation. With Go’s universal formatting style thanks to
gofmt
and a testing framework built-in, we can concentrate on our interpreter and not worry about 3rd party libraries, tools and dependencies. We won’t be using any other tools in this book other than the ones provided by the Go programming language.
I also made the bet that the “Go code presented in this book maps closely to other and possibly more low-level languages”, adding:
Maybe the reason for this is Go itself, with its focus on simplicity, its stripped-down charm and lack of programming language constructs that are absent in other languages and hard to translate. Or maybe it’s because of the way I chose to write Go for this book.
My predictions for the future of technology aren’t always great (in 2013 I said that no one will ever use a mobile phone to do anything serious on the internet, like shopping), but I think using Go for this book (and its sequel, Writing A Compiler In Go) was a bet I won.
The code is still idiomatic. If I run golangci-lint
over it, the few warnings I get are the same ones it would’ve returned in 2016. It’s still how I would write Go today.
It’s still formatted just like any other Go code. go fmt
hasn’t changed, it still has no knobs to turn.
As for the suspicion that Go is easy to understand and to translate — I think I now have the evidence to prove it.
In the first few years of the books being released, people asked whether they need to know Go to understand the books. Cautious about being judged in a contest I didn’t enter, I said: well, you should know some Go, at least work through the tour before you start reading.
But then, over time, more and more readers told me: hey, I’ve never done any Go before, I don’t know Go, but I read the books, enjoyed them, and translated the code into my favorite language.
Take a look at monkeylang.org: readers have written Monkey interpreters in Rust, Elixir, C++, TypeScript, Dart, Python, Java, V, C, PHP, Kotlin, Crystal, Scala, Lua, OCaml, Julia, Swift, F#, Elm — and others. Quite a few of these implementations — I know because their authors told me — were made on the fly, while reading the books, without typing out the Go code before.
Code that’s easy to understand and translate for readers that don’t know the language and that has shelf life that’s hard to believe, tooling that’s easy to install and use for newcomers and that also didn’t change in eight years, the ability to let you write an interpreter and bytecode compiler without using any third party dependencies — I know and love many other languages than Go, but I’m not sure which one would fit the bill quite like Go does.
Like I said: glad I used Go.
Congratulations on the anniversary of the book! I don't think I knew any go when I started to read the book. I might have tried out the playground but nothing serious. I just did it on the fly. I chose to write the code in C because that way I challenged myself to actually think about what I am doing, instead of copying the code as it is, which turned out to be a good call.
I am a 66-year-old retired programmer.
I just finished this month of reading and coding along with reading your remarkable book, which gave me moments of real joy.
I rediscovered the joy of this job, which I had kind of lost after many years of backend programming in C#.
At the same time, the book helped me to learn more about the GO language, which I can now say that I have fallen in love with.
I'm ready to "attack" your other book "Write a Compiler in GO".
Thank you.