Boo

Boo is what happens when someone looks at the .NET platform in 2003, decides that C# is too much typing and Python is too little type-checking, and refuses to accept that those are the only two options. Rodrigo Barreto de Oliveira’s answer was a statically typed, object-oriented language for the Common Language Infrastructure that looks like Python — significant indentation, no semicolons, no curly braces, minimal ceremony — while compiling to ordinary verifiable CIL assemblies that any other .NET language can consume without knowing Boo exists.

That description makes it sound like a syntax skin, and for the first few pages of any Boo program it essentially is. The interesting part is underneath. Boo was designed from the manifesto onward as a language you were expected to modify: it exposes its abstract syntax tree, lets you register your own transformations into the compilation pipeline, and gives you syntactic macros and attributes that can invent new language constructs. Most languages treat the compiler as a fixed appliance. Boo treats it as a library.

History and Origins

De Oliveira — reportedly “bamboo” online, which is said to be where the language’s name comes from — started Boo in 2003 out of straightforward frustration. He wanted Python’s syntax and expressiveness but also wanted static type checking and clean, non-second-class access to the .NET Framework. Python on .NET existed in various forms, but those projects were pursuing CPython compatibility, which meant inheriting CPython’s dynamism as a requirement rather than an option. C# was well integrated with the platform and, in the pre-var, pre-lambda C# 1.x era, extraordinarily verbose.

So he built a third thing, and made a specific bet about which trade-off mattered. Boo defaults to static typing and infers most of it, so x = 5 gives you an int with no annotation and full compile-time checking, not a dynamically dispatched name lookup. Dynamism is available on request, per variable, via the duck type. The design ethos borrows from Python for surface syntax, from C# for platform semantics, and — de Oliveira has said — from Ruby for a general willingness to let the programmer bend the language.

Boo lived at CodeHaus for its first several years, moved to GitHub around 2010, and picked up an unlikely commercial patron along the way: Unity Technologies hired de Oliveira, and Boo became one of the three languages you could write Unity games in, alongside C# and the JavaScript dialect universally called UnityScript. For a small BSD-licensed language written by one person, shipping inside one of the most widely used game engines in the world is about as good an outcome as the genre offers.

Design Philosophy

Static typing should be inferred, not announced. Boo’s central ergonomic claim is that most type annotations are the compiler asking you to tell it something it already knows. Local variables, iteration variables, method return types, closure parameters and generator element types are all inferred. What you write reads like a dynamic language; what the compiler checks is fully static.

Dynamism is a type, not a mode. Rather than choosing between static and dynamic dispatch language-wide, Boo makes duck a type you apply where you need it. A duck-typed expression defers member resolution to run time; everything else stays checked. This landed in Boo years before C# added dynamic in C# 4.0, and it is the same idea, arrived at independently and from the opposite direction.

The compiler is part of the language. This is the manifesto’s real content. Syntactic attributes are compiler-recognised attribute classes that transform the AST of the thing they decorate — [property(Name)] on a field generates the whole property. Syntactic macros go further and add new constructs to the grammar. Because macros are just CLI objects implementing a compiler interface, they can be written in Boo, C#, or any other .NET language, and the pipeline itself can have steps added, removed or reordered by the program doing the compiling.

Small programs should not need scaffolding. A Boo file can be a bare sequence of statements — no class, no namespace, no Main. The compiler wraps it for you. print "Hello, World!" in a file is a complete, compilable program.

Interoperate, don’t replace. Boo was never positioned as a C# competitor for whole systems. It compiles to standard assemblies, consumes standard assemblies, and was pitched as the language you reach for when a particular part of a system — a configuration layer, a build script, a rules engine, a set of views — is better expressed in something more malleable.

Key Features

Python-shaped syntax with static semantics.

import System

class Person:
    [property(Name)]
    _name as string

    [property(Age)]
    _age as int

    def constructor(name as string, age as int):
        _name = name
        _age = age

    def Describe() as string:
        return "${_name} is ${_age}"

people = [Person("Ada", 36), Person("Grace", 45)]
for p in people:
    print p.Describe()

Note ${} string interpolation, the inferred type of people (a typed list), the inferred loop variable, and [property(...)] generating a full CLR property from a private field at compile time.

Type inference with escape hatches. x = 5 infers int; x as double = 5 states it; x as duck = GetSomething() opts into run-time dispatch. Casting comes in two flavours — cast for a hard cast that throws, and as for a soft cast that yields null.

Duck typing and IQuackFu. Beyond the duck type, Boo lets a class implement IQuackFu to intercept member access and method invocation it does not statically define — the same territory as Ruby’s method_missing or Python’s __getattr__, which makes it easy to write proxies, dynamic XML/JSON wrappers and mock objects.

Syntactic macros with quasi-quotation. New constructs are ordinary compiler-invoked classes, and later versions let you build the generated AST with quasi-quotation syntax rather than by hand:

macro unless(condition as Expression):
    yield [|
        if not $condition:
            $(unless.Body)
    |]

unless a > b:
    print "b wins"

[| ... |] is a literal chunk of syntax tree; $ splices values into it. This is the machinery Brail, Binsor and Rhino DSL are all built on.

Functional conveniences. First-class functions and closures, list comprehensions and generator expressions, generators via yield, currying, slicing, and multimethods (dispatch across argument types) were all present well before comparable features were common on the CLR.

booish. An interactive REPL shipped with the compiler, which for a statically typed compiled language of that era was unusual, and made Boo pleasant to explore.

Evolution

The arc is unusually legible. Boo’s technical peak and its popular peak did not coincide. The version numbers never reached 1.0 — a fact frequently held against it in “should I use this?” discussions, somewhat unfairly, since 0.9.x was a stable, production-used compiler. Meanwhile the language’s actual influence flowed through two channels that had nothing to do with the version number: Unity, which put Boo in front of an enormous number of game developers who mostly chose C# anyway; and the Castle/Ayende corner of the .NET world, where Boo became the default answer to “how do I build a DSL on the CLR?”

Two things then eroded the case for Boo simultaneously. C# absorbed much of what made Boo attractive — var and lambdas in C# 3.0 (2007), dynamic in C# 4.0 (2010) — narrowing the syntax gap that motivated the language in the first place. And Unity, the one platform putting Boo in front of a mass audience, walked away in stages between 2014 and 2018. De Oliveira moved on; Mason Wheeler picked up maintenance and kept the project going for several more years, but the most recent commit dates from around 2022.

Current Relevance

Boo is dormant. The repository at boo-lang/boo is open, unarchived, BSD-3-Clause licensed and sitting at roughly 900 stars, but nothing has been committed since 2022, the last numbered release is from 2013, and the CI-produced “unstable” builds are the newest artefacts on offer. Its compiler and standard tooling target the .NET Framework and Mono era; do not assume a modern .NET Core / .NET 5+ workflow works without investigation, because that transition is exactly the kind of maintenance the project stopped doing.

Nobody should start a new production system in Boo in 2026. What Boo is still genuinely good for:

• Reading a compiler that was designed to be opened. Boo’s pipeline, AST attributes and macro system are unusually clear implementations of ideas that most languages either lack or bury. It is a small enough codebase to actually study.
• Understanding where a lot of .NET DSL practice came from. If you have ever written a fluent configuration API in C# and wished the syntax could go further, Boo and DSLs in Boo are the prior art.
• Unity archaeology. There are Unity projects from 2008–2015 with .boo files in them. Modern Unity cannot compile them, and knowing what the language was is a prerequisite to porting them.
• Language-design study. Static-by-default with inference plus opt-in dynamic typing is now a mainstream position — TypeScript’s any, C#’s dynamic, Python’s gradual typing. Boo argued for it in 2003 and implemented it coherently.

Why It Matters

Boo’s importance is not proportional to its user count, which was always small. It matters because it got two significant design calls right well ahead of the industry, and because it demonstrated a third idea that the industry still has not fully adopted.

The first call was inference-heavy static typing with a Python-like surface. In 2003 the received wisdom was that terse, indentation-based, annotation-free code implied a dynamic language, and that static safety implied C#/Java verbosity. Boo simply refused the dichotomy, and the modern consensus — Kotlin, Swift, Scala, TypeScript, and C# itself post-var — is exactly where Boo already was.

The second was dynamism as an opt-in type rather than a language-wide mode. duck in Boo and dynamic in C# 4.0 are the same insight, and Boo shipped it years earlier.

The third, and the one that has aged best, is the openly extensible compiler. Boo’s position was that a language should let ordinary programmers add constructs, and that the compilation pipeline should be a manipulable object rather than a black box. That belief produced Brail, Binsor and a small ecosystem of production DSLs on a platform whose mainstream language offered nothing comparable. Rust’s procedural macros, Scala’s macros, C#’s source generators and Roslyn analysers, and Lisp’s much older tradition are all working the same seam — and Boo’s version, invocable from any CLI language with AST quasi-quotation for building the output, remains a notably clean take on it.

There is also a plainer lesson in Boo’s decline. A one-person language with a corporate patron looks secure right up until the patron’s usage statistics come in. Unity gave Boo a decade of visibility and then, entirely reasonably, removed it after reporting that only a fraction of a percent of projects contained a .boo file. Boo did not fail because it was badly designed; it failed because the mainstream language it was reacting against kept absorbing its best ideas, and because the one distribution channel that could have sustained it decided the maintenance cost was not worth it. Both are ordinary fates. Neither makes the design less worth reading.