I'm publishing this series ahead of Code BEAM Europe this October, where I'll reveal Bondy, a new declarative^[1] language for the BEAM: statically typed, functional, relational and rule-based.

Bondy is a brand about connecting everything to everything. Not only in the networking sense, but in a deeper one that has shaped how I've built software for as long as I've been building it. It is the conviction that many of the things we normally keep in separate boxes were always meant to belong together. Bondy is the name I gave to that conviction.

It began as the name of our distributed application networking (DAN) platform. It removed the bureaucratic middleware the market kept throwing at us: the service mesh, the API gateway, the RPC framework, the pub/sub broker. Each solved a sliver of the same problem, and each demanded its own security, its own infrastructure, its own configuration, its own learning curve. Collapsing all of that into one coherent thing was the most pressing pain in front of us at Leapsight, so that is where I started. But the application networking platform was only ever one piece of Bondy.

The ambition behind the brand was always larger: to take a great many beautiful and inspired ideas from computer science and bring them together into a single, coherent whole. The market neglected some of them for commercial rather than technical reasons. The application networking platform solved one piece of that puzzle. It was never the puzzle.

The middleware tax — a half-dozen tools and protocols — collapsed into one tool and one protocol.

A drawer full of ideas that belonged together

If you do this work long enough, you stop collecting tools and start collecting convictions.

Mine accumulated slowly, one project at a time. By the late nineties they lived in an Eastgate Tinderbox file — my intellectual drawers made digital — and it was filling up. OpenStep, distribution, tuplespaces, Lifestreams, Xanadu, JINI, Datalog, logic and constraint programming, Meta Content Framework and RDF, FIPA agents, Erlang. Notes linked to notes linked to notes, about systems that to everyone else lived in different fields and different conferences. But to me they kept pointing at the same underlying thing.

Most of those ideas were not mine. They belonged to researchers and communities far smarter than me. What was mine was a stubborn feeling that they belonged together. They were not a handful of separate problems with separate solutions, but facets of one problem the world had never let sit in the same room.

For a long while they stayed in separate drawers, because the industry insisted they belonged there, or because the best technology does not always win.

I remember approaching one of the engineers behind the first version of OS X Spotlight, announced at Apple's WWDC in 2004. When I asked him why Spotlight wasn't built as an RDF store, he asked me what RDF was. This was shocking, given that RDF's ancestor—the Meta Content Framework (MCF)^[2]—was actually created at Apple and showcased by HotSauce^[3]. At least now, almost 20 years later, RDF has finally found its way back to Apple^[4].

The separate drawers — and the one conviction underneath them.

The word for what I've been doing

When we have unified enough certain knowledge, we will understand who we are and why we are here. If those committed to the quest fail, they will be forgiven. When lost, they will find another way. The moral imperative of humanism is the endeavour alone, whether successful or not, provided the effort is honorable and failure memorable.

E.O. Wilson, Consilience: The Unity of knowledge

The book that named it →

I found the word for it in 1998, when I read Consilience: The Unity of Knowledge by E. O. Wilson. Wilson used it to mean the "jumping together" of knowledge — the way facts and theories from unrelated disciplines link up into a common groundwork of explanation. It is the opposite of specialisation: the belief that the seams between fields are artefacts of how we organised our universities, not features of reality.

That named the drawer. What I'd been assembling wasn't a reading list or a wiki. It was a consilience waiting to happen.

And that is what Bondy has always been reaching for. Not a product with a long feature list, but a consilience. There, the ideas I'd been carrying for decades could finally stop being neighbours and start being one thing.

Why the whole puzzle needs a language

The language is where the ambition was pointing the entire time.

These ideas have to actually unify: not sit side by side, but compose, reinforce each other and become guarantees you can lean on. For that, they can't live in the plumbing. They have to live in the language you write your program in, and in the runtime that executes it.

I want to be careful here, because it would be easy to read this as one thing turning into another: the application networking platform growing up into a language. It isn't that. Both are expressions of the same philosophy, and they solve different amounts of the puzzle. I began with the networking platform because I wasn't ready to solve the whole thing yet, and because the middleware tax was the pain right in front of us. What the language actually is — and how it makes these ideas cohere — is what the rest of this series is for.

Why now: we need a declarative language more than ever

There is a second reason, and it is newer than the drawer.

Language models now write a growing share of software. That changes the economics of code, and it raises the stakes. For the systems that matter, the risk is no longer that the code cannot be produced. It is that nobody can understand, review or maintain what was produced, as it grows faster than anyone reads it.

Some argue the opposite: once machines write the code, the language stops mattering. I think that gets it backwards. The less of the code a human writes, the more the language has to carry the meaning a human can check.

A declarative program says what must be true, not the sequence of steps that happens to make it true today. It is mostly facts, rules and constraints, with little control flow in between, and that is what both people and models get right most often. A model is far more likely to get a rule, relation, constraint or type right than a long chain of imperative updates. Those updates must stay in sync across a dozen code paths. And a reviewer is far more likely to spot the one that is wrong.

This is not a hypothesis. At Leapsight we see a reduction of 10x to 15x in lines of code compared to the Erlang that does the same job. The difference is the declarative part. The shapes, rules, relations and constraints that Erlang makes you spell out as control flow are one-line statements in Bondy. Less code is less to write, and above all less to review.

The payoff is the same for people and for machines. Invariants live in one place, so programs are cheaper to change. Anything that can be worked out from other facts is written once as a rule, not kept in sync by hand, so there are fewer places for bugs to hide. And the program reads like its specification, so reviewing it means reading what it claims. Add a compiler that knows what every function is allowed to do, and code written by a tool can run with only the permissions you grant it. The seventh post is about that.

The BEAM already gives us the operational foundation for systems that keep running. Bondy adds the semantic one. That matters most now that we write those systems together with machines.

Bondy Connect, and Bondy (Lang)

In its application networking platform years, Bondy was the connective tissue made visible. WAMP gave anything a common protocol to talk to anything, and clustering and replication let the whole thing survive a machine dying. We arranged all of it so the accidental complexity fell away and only the essential part remained.

That role isn't going away, but the name is now expanding to cover the entire ambition. Meanwhile, the application networking platform itself is getting its own distinct name: Bondy Connect. Far from being retired or diminished, it is finally graduating to v1.0.0. For the first time, it is being named precisely. It is the mesh—the fabric that allows everything to communicate. It has earned its name, and it continues to do its job.

And Bondy — just Bondy — is the brand and the philosophy, of which the language is the fullest expression. The attempt to take every idea I ever found beautiful in computer science and make them cohere into something you can actually program in. That includes the ones the market quietly left for dead.

This isn't a rebrand in the marketing sense, where a logo changes and nothing else does. It's naming things correctly at last. The brand always meant more than an application networking platform. Giving it its own name lets Bondy finally stand for the whole of the ambition rather than one part of it.

Consilience is not something you announce and then possess. It's something you build toward, imperfectly, for a long time, and Bondy has a long way still to go. But for the first time the name and the ambition point at the same thing.

After decades of gluing, the seams are starting to disappear. Bondy was a brand that wanted to be more than an application networking platform. It finally is.

What it looks like

I wrote the rest of the series for people who will type this in, so here is one module before the argument. It is a rate limiter that knows which features each plan includes. Every line compiles on the current toolchain, and every line is explained later in the series.

module Limiter implements GenReactor(Event = Allowed | Denied)

import GenReactor.{type Reply, NoReply}

%% -----------------------------------------------------
%% Types
%% What a valid value looks like.
%% -----------------------------------------------------
type Config = {max_tokens: Int & > 0 & =< 10000}

%% -----------------------------------------------------
%% Relations
%% Facts you look up, and rules that derive more 
%% of them.
%% -----------------------------------------------------

relation Extends = {plan: String, parent: String}
relation Grants  = {plan: String, feature: String}

fact Extends(plan: "pro",  parent: "free")
fact Grants(plan: "free", feature: "api")
fact Grants(plan: "pro",  feature: "webhooks")

relation Has(plan: String, feature: String) :-
    Grants(plan: plan, feature: feature)

relation Has(plan: String, feature: String) :-
    Extends(plan: plan, parent: p), 
    Has(plan: p, feature: feature)

%% -----------------------------------------------------
%% Constraints and Rules
%% Facts you impose on a store, rules that react, 
%% events that leave.
%% -----------------------------------------------------

constraint Bucket = {id: String, tokens: Int}
constraint Request = {id: String}

event Allowed = {id: String, remaining: Int}
event Denied = {id: String}

rule consume_token =
    on 
      Request(id: rid) as req, 
      Bucket(id: rid, tokens: t) as bucket
    remove 
      req, bucket
    when 
      t > 0
    tell 
      Bucket(id: rid, tokens: t - 1),
      Allowed(id: rid, remaining: t - 1)
    end

rule deny =
    on 
      Bucket(id: rid, tokens: 0), 
      Request(id: rid) as req
    remove 
      req
    tell 
      Denied(id: rid)
    end

%% -----------------------------------------------------
%% Functions, with what they may do checked by the compiler.
%% -----------------------------------------------------

@law(:pure, :deterministic)
public function capacity(cfg: Config) :: Int -> 
  cfg.max_tokens

public function features(plan: String) ->
    query Has(plan: plan, feature: f) end

public function init(_args) -> 
  Ok([])

public function handle_event(Allowed() as e, _ctx) -> 
  Reply(value: e)
public function handle_event(Denied() as e, _ctx) -> 
  Reply(value: e)
public function handle_event(_, _) -> 
  NoReply()

Two nouns the BEAM already gives you, functions and processes. Three that Bondy adds: the shape, which describes which values are allowed (Config above is a named one), the rule, and the signal. Four roles a value can play: relation, constraint, event and fluent. Shapes, relations, constraints, events and both kinds of rule are in the compiler today, and so is the check on what every function is allowed to do. Fluents and signals are designed and next, and every post that touches them says so.

What the series covers

One post per idea, with code you can compile:

1. Bondy as Consilience, this post. The name, and why the application networking platform was never the whole ambition.
2. One noun, more roles. The thesis: a value can be held, imposed, emitted or latched, each role with its own verbs.
3. The type that validates. Shapes, refinements and unification: the check written once, run at compile time and at the boundary.
4. Rules that fire themselves. Rewrite rules over a store, replacing the state machine in your handle_call.
5. The process that owns the store. Events, and the supervised process that runs the rules.
6. Ask questions of your data. Relations and derivation rules, replacing the traversal you hand-roll.
7. What a function is allowed to do. Capabilities and laws: how the compiler knows what a function may do.
8. The alarm that cleared itself. Fluents and signals: designed, and next.
9. One module, five nouns. The whole rate limiter on one page, and how to get it.

---

1. Declarative is a spectrum, not a label, and BEAM programmers will rightly say that Erlang, Elixir and Gleam are declarative already. They are, in one sense: you write expressions over immutable values, not statements that change memory. But you still write the algorithm (which map to look in, which branch to take) and you still thread the state from one call to the next. Bondy keeps that functional core and goes further along the same line. With relations, rules and constraints you state the facts and what must hold, and the engine decides the order, the lookups and where the state lives. The glossary entry has the longer version. ↩︎

2. The Meta Content Framework (MCF) is an early metadata specification developed by Ramanathan V. Guha at Apple Computer between 1995 and 1997 to structure information and relationships on the web. ↩︎

3. HotSauce, code-named Project X, was an experimental 3D web browser and plug-in. Apple Computer developed it in 1996 as a sample application of its Meta Content Framework (MCF). ↩︎

4. Saga: A Platform for Continuous Construction and Serving of Knowledge At Scale ↩︎