Building a Go Compiler in Go

One of the biggest design decisions we made with erGo™ was the decision to write the compiler itself in the Go language. It’s had a huge impact on every level of our development process. In the end, we believe that we absolutely made the right decision. On the other hand, we completely understand why the original Go team didn’t do it that way. It would’ve been close to impossible. The only reason we were able to do it is because their compiler tools were already so stable and solid. Even so, it was a difficult process. We were facing the dual challenge of developing a major software product in a language we had no experience in and doing it for a platform for which a compiler didn’t exist. We began this project literally within weeks of Go’s launch (Go was announced on November 10th; we were coding by Thanksgiving). At the time, the MinGW port hadn’t even been started, much less become stable enough for us to use.

So why did we decide to do it that way? A few things pushed us over the edge. First of all, we knew it would be a really important thing for the Go language. It’s a bold statement: this language is strong enough to write a full fledged compiler in. Since no compiler existed for Windows, we knew that the only way a compiler for Go could get on Windows is if it compiled itself, so it would make a bold statement about erGo™ as well. Second, it would demonstrate our own faith in the language. If we believe the language is that good (and we do), it would be much easier to convince users of that. Finally, it would give us a very large code base of a “real” project to use as a test case for the compiler. erGo™ itself exercises a pretty broad portion of the language, and the standard packages we rely on (which erGo™ had to compile before it could compile itself) only add to that. It gave us a very useful validation tool.

How did we do it? With a very unusual (and at times irritating) development setup. We run on Windows machines with Ubuntu running inside a VM. Then we used shared directories (via networking) so that we can access files from both sides. We run a two step makefile process. First, we use 6g to compile a version of erGo™ that runs as a Linux binary. That compiler is then used to compile a Windows binary on the Windows side of the box, and we build our test suites using that.

Read more: The erGo™ Blog

Posted via email from .NET Info