During my career in software I built many systems that needed custom data structures to reach the efficiency we were after. Those were for multi-server setups with many cores and they had to be rock solid too: a 99.999% uptime is not easily reached.
Loft was, from the start, a way to get the lessons of that career somewhere more people can make use of them. The data structures I hand-crafted under Java had a common theme that could be generalised into a language as an in-memory database.
The best use I could imagine for it was games with a dynamic world model.
C++ is still the most common language for published games, and in my opinion it is not very helpful for them. A lot of constructs in it can crash a game, and being one of the most efficient languages around still doesn’t help against the actual reasons games get slow.
Those reasons are:
I cannot really help with the first one. The other two can be helped, though that road is not short or simple.
Iteration speed. Change the code while the game runs, instead of compiling, restarting and playing back to where you were. Loft can already swap an edited function into a running program, and a compile error leaves the old version running. Changing the shape of the data is the next step I still have to add.
Save games and mods. The data in memory and on disk is one representation: a store saved to disk is the same bytes the program held. When the code changes, added and removed fields are carried over, and a save that no longer fits is refused rather than misread. Data can be read straight from a web server or handed to another process without translation overhead.
One source, every target. The same program runs compiled to native code, in WebAssembly, and as a single HTML page playable in the browser — Brick Buster is one file of loft. Windows, Linux and macOS are fully supported.
Running inside an engine. C# or Lua inside an engine can stop functioning for many reasons, and the engine then has to step in, keep the rendering running and restart the embedded runtime, losing what it held. In loft, a fault in a calculation gives an empty value and the game carries on. The game’s data lives in stores, not inside a script’s runtime. We take the state so seriously that the whole program can be switched for a more optimised build while the game keeps running.
Small teams and indies, who cannot afford to work around C++’s problems.
Speed matters, but not because every algorithm in a game needs the same speed. Without speed comparable to Rust or C++ there will always be a reason to reach for those instead, and to give up code that is readable for as many people as possible. Rust is already more readable than C++ in many cases, but even it has many constructions that baffle a curious reader without years of experience. That is not a slight against Rust; it is a complex language. Loft tries to prevent that as much as possible.
The same goes for the libraries: a slow routine is work for the compiler, never a hand-written Rust shortcut, so nobody has to read Rust to read a library. For example, a matrix multiplication in the 3D library started forty times slower than its Rust twin but ended up faster, without any change to the library. The compiler learned to keep a temporary result off the heap altogether, and every program with the same shape got the same gain.
I am convinced loft will be useful in the end. I am not claiming it is useful today.
Getting there is a hard but reachable goal. Once it is reached, a whole class of problems that can halt a project is solved. Loft and its libraries take on the hard work so developers don’t have to.
To be useful, loft needs speed and stability. Compiled loft is already a quick language: about twice the time of the same routine in Rust, down from nearly three times at the start of October. “Slower than Python” is true only of the interpreter, and even there the gap is now small on most tests. The interpreter is not how the games run, nor how most code runs during development. It is there for turnaround: an instant start, editing while the game runs, the debugger.
Stability has two sides. The meaning of a program is close to locked in: written down as formal rules, nearly all of them with a test by now. But the code the compiler generates is still very much under construction, to make it faster. So I will not call loft stable until most of the planned optimisations are in.
Implementation changes are very hard to stabilise. A routine that worked fine yesterday can suddenly stop working because the optimiser chose another implementation for it, with new bugs.
The end goal here is that every working program will keep on working. That is a promise for the future, and it can only be judged after the fact.
Loft is open source: github.com/loft-lang/loft.
]]>They are eager: they never sleep and will happily take on anything you point them at. They are inexperienced: they take no time to find where a problem really comes from, so they fix exactly the problem in front of them and miss the fix that was actually needed. And they google a lot: they know a great deal about programming in theory and nothing about my language unless already documented.
None of this is new. Every team lead has managed such people. What is new here is having them available for the price of a subscription. This post is about what that has meant for loft, the programming language I am building to ease the creation of games.
Loft had been in development for eight years before any AI was involved. The agents did not invent it; they inherited it and built it out.
What changed is not only the development speed: the language has also become much more complete, because it is now quick to compare loft against other languages like Julia, OCaml or Python. What those languages can express is turned into tests, and each failing test forces a decision: is this a missing feature, a language bug, or something we do not want to implement at all?
I write very little of the code myself now. My work is steering: guiding the agents around problems and devising ways of working that enhance what they are good at while covering for what they tend to overlook.
Their strengths are easy to list: they are fast, they do not tire, they know a lot, and they follow a written method faithfully once they have read it. Their blind spots are just as clear: they remember nothing between sessions, they rush to a fix, they trust their own explanation, and they apply what is true in general where it is not true here.
So most of my effort goes into how the project works rather than into its code. I find the blind spots through frustration: when the AI makes the same mistake several times, that is one. Each is then investigated and turned into a document, skill or tool that makes it less of a risk.
An agent starts every session without memory. Everything that needs to be remembered has to be in the project itself: the bugs, the features, the rules, the design decisions, each tagged so it can be found and tested again. The documentation is not a nice extra; it is the team’s memory.
That memory goes stale, just like a person’s. Almost anything written in a document might be true on the day it is written, and is certainly wrong a month later. So documents should hold as few facts that can go stale as possible, and be easy to check.
None of this is unique to AI. A team of people needs the same discipline. Individual people just hide the problem by vaguely remembering things. Agents cannot, so the gaps show up immediately. It is the same as when experienced team members leave and new ones replace them — except that with agents, it happens every session.
This is where inexperience shows most. An agent finds a bug, finds a change that makes the failing case pass, and stops. The exact problem is fixed, but the place it came from is not, and the same mistake keeps living elsewhere. Over time you get many slightly different copies of the same logic, each patched for its own bug, with no design holding them together.
Optimisation shows it even more clearly. The profiler points at a slow line, and the tempting fix is a special shortcut for exactly that line. It works, and it helps nothing else. Looking for the source usually finds something different, and fixes every program that has the same shape. That is why loft treats a slow library routine as work for the compiler, never as a place for a hand-written shortcut.
Two things help. The first is making it cheaper to look than not to: before fixing anything non-trivial, each agent has to map out the cases around the bug. Only when both the working and the failing cases are mapped can it be sure it has found the real boundary. For a person that would be slow, but an AI does it quickly, and it is still small next to the time the fix and its tests take.
The second is a set of formal rules: precise statements of how the language must behave. The rules come first, and code that disagrees with them is what gets fixed. When a bug comes in, the rules usually already say what the right answer is, so there is much less guessing. But the rules only help if they are checked again and again. They are also the way to find duplicated code and the errors in it: when two pieces of code implement the same rule independently, one can be right and the other wrong, and the rule shows where to merge them.
Agents write a lot of tests. That is good in itself, but the tests become a system of their own that needs managing: how long they take, how much memory they use, how much disk space they fill when several agents run them beside each other on the same machine.
And a test that cannot fail is worse than no test, because it makes you feel safe. So each new test is checked against the old, broken version of the code, to prove it would have caught the bug it was written for. Eager programmers write a lot of tests; some process has to check that the tests are actually testing something.
With all those challenges, why do it? Because the result is worth it.
Let the AI fix a couple of bugs. See where it fails, takes the wrong turn, invents things on its own that do not fit your plan. Those problems are not inherent to AI; they show the gaps in your setup: designs that are hard to find, old bugs nobody can learn from, a project that is too much of a mess. And yes, left alone, an AI will make that mess for you.
This is not really advice about AI. It is advice about leading a team. The AI just makes it impossible to skip.
Loft is open source: github.com/loft-lang/loft. The rules, the working methods and the record behind everything in this post are in the repository.
]]>