Skip to content
Orbit

Foundation

How far less can go

The hypothesis is simple to state and awkward to prove: a server shouldn't need so much energy to be fast. I'm testing it, and this page is what I'm testing.

01

Why this exists

Data centres used about 415 TWh in 2024, around 1.5% of global electricity. Demand has grown about 12% a year since 2017. That growth is the reason a language that compiles fast and needs little at runtime is worth building at all.

IEA Energy and AI. It's context for the project, not a measurement of Orbit. I'm not claiming a causal link between the two.

Orbit is not an ecological project that happens to make a language. It's an engineering project whose natural result is ecological. The engineering has to hold up first, or the rest is decoration.

02

What I think is clumsy

Scaling by adding consumption is clumsy

Adding machines, compute, or parameters just because it's possible is bad engineering. It hides the cost instead of paying it.

Software is physical

Digital doesn't mean clean. Every request costs energy, usually drawn from sources that aren't renewable.

Comfort is philosophical

If starting a server needs a tree of dependencies, it isn't elegant, even when it's fast. I wanted a toolchain I could read end to end.

Doing more with less is respect

For the machine, for the energy, and for the people who don't have exceptional hardware to work on.

I have no interest in claiming Orbit beats a named language. Plenty of languages optimise for peak benchmark power, and that often needs more memory and energy to stay fast.

03

How I measure

The method is written down before the numbers, so I can't quietly change one to suit the other.

  1. 01

    Name the machine

    Processor, cores, memory, and whether the box is shared. Run to run noise is expected on a shared machine, so medians of repeats get reported.

  2. 02

    Bracket every pair

    Before and after runs alternate rather than measuring A fully and then B. A shared box drifts, and bracketing keeps the comparison honest.

  3. 03

    Report the failures

    Attempts that didn't pay off get published too, with the reason. A document that only lists wins isn't a measurement.

  4. 04

    Never fake energy

    CPU time is not joules. Without a hardware sensor, energy stays a proxy, labelled as one. No universal conversion factor gets applied.

04

How it's built

The compiler is written in Orbit and compiles itself. That wasn't chosen for the logo. A toolchain you can't read is a toolchain you can't fix.

Orbit compiles to C, and your platform's C compiler produces the executable. One file per service, no runtime to install beside it. That's what "needs little" has to mean in practice, or it means nothing.

The project runs on one modest PC, with no team behind it. Every performance claim here has to survive that constraint, because it's the reason the project exists.

What I'm testing next

The honest next step isn't another transform. It's measuring the accept, parse, and send path on a machine I can account for, then deciding whether Superluminal is worth continuing at all. If the answer is no, I'll say so here and in the repository.

To follow that, the roadmap and dated status pages are the two places I update honestly, including the parts that didn't work.