Project Ceylon Development Log — October 4, 2026: Slow, Boring, and Exactly What We Need

A couple of days ago I put Project Ceylon on a hard hold on new development.

That does not mean work has stopped.

It means forward development has stopped.

There is an important difference.

For the next couple of days, the goal is to test, appraise, repair, and retest what is already there until we are as close as we can reasonably get to a known-good platform.

That is the point I want to resume coding from.

Not "mostly working."

Not "we think this path is okay."

Not "the logs looked healthy last time."

The closest thing to a known-good system we can actually prove.

We are finding things

The testing is doing exactly what it is supposed to do.

We are finding issues.

Some are ordinary bugs. Some are incomplete implementations. Some are places where two parts of the system each make sense by themselves but do not quite agree once they have to work together.

That is why the hold exists.

If we find a real problem now, I would much rather stop and fix it correctly than carry it forward underneath another three layers of code.

That is slower in the short term.

It is much faster than discovering later that a new feature was built on top of an assumption that was never actually true.

This phase is not especially exciting to watch.

There may be a few development logs over the next several days that amount to little more than:

still testing, still appraising, still repairing.

That is fine.

I am not going to manufacture a dramatic milestone every evening just to make the journal look busy.

The project is busy enough on its own.

The goal is a trustworthy starting point

What I want at the end of this pass is a baseline we understand.

I want to know which parts of Ceylon are genuinely solid, which parts are fragile, which assumptions have survived contact with integrated testing, and which ones need to be removed before they become permanent architecture.

That means looking at the machine from more than one angle.

Individual subsystems still have to prove their own behavior, but we are also continuing to test the paths between them and the complete behavior of the system when those pieces are connected together.

We have already learned the hard way that a green local test can coexist with a broken computer.

So this is not about collecting more green boxes.

It is about understanding what those green boxes actually prove.

Advancement is on hold

I have made this a hard rule for the current tranche:

no new implementation work until this qualification and repair pass is complete.

That includes application work.

There are several things waiting in the wings that I would very much like to start building against the system.

They can wait.

If Ceylon is going to host applications, development tools, media software, games, and eventually more serious workloads, then the platform under all of that has to be the part we trust first.

The temptation to move ahead is real.

It is especially real when a new idea looks more interesting than another hour of testing restart behavior.

But "interesting" is not a release criterion.

The planning work has not stopped

The implementation hold does not mean I have stopped thinking about what comes next.

Quite the opposite.

Some of the time that would normally go into coding has gone into tightening the specifications for work we already know is coming.

We put together a much more serious plan for a Ceylon SDK and application toolchain.

The initial idea is straightforward: start with a Linux-hosted development path that can build, package, deploy, launch, diagnose, rebuild, and replace a Ceylon application through supported system interfaces.

The important part is what does not count as success.

A program linking on Linux is not enough.

A host-side simulation is not enough.

A build artifact existing is not enough.

The application eventually has to run inside Ceylon through the actual runtime and service contracts.

That specification work is useful now because it gives us something concrete to build toward later without pretending we are ready to start that implementation today.

And, eventually, Rust on Ceylon

That SDK discussion naturally led to another question:

if Ceylon is eventually supposed to be a real development environment, should Linux remain the permanent place where serious software gets built?

Probably not.

So we also started looking at what it would actually take to run a Rust compiler and linker natively on Ceylon.

Again, this is planning, not implementation.

There is a fairly large gap between "we want Rust on Ceylon" and "the compiler runs locally."

A native compiler needs filesystem behavior, process or job control, memory management, synchronization, timing, executable loading, diagnostics, and enough host support that we are not quietly outsourcing the hard parts to another machine.

That work comes later.

But defining the problem now is useful.

It is much better than discovering halfway through a toolchain port that the operating system is missing three services the compiler quietly assumed every desktop had.

NuDOS and NuBASIC got the same treatment

We also spent time tightening the specifications for NuDOS and NuBASIC.

Both already had substantial material behind them.

That was not the problem.

The problem was making sure that "substantial" also means coherent, implementable, testable, and consistent with the Ceylon that exists now.

NuDOS needed a more serious requirements pass around command parsing, file operations, application launch, session behavior, restart handling, diagnostics, and end-to-end qualification.

NuBASIC had an even larger existing language corpus, but it still needed the surrounding platform assumptions reconciled with the current architecture.

Things like files, graphics, audio, timing, sessions, resource lifetime, and service failure cannot just be vaguely implied because the language syntax is well specified.

The goal with both of these is simple:

when implementation resumes, I do not want the developer—human or otherwise—to have to invent architecture while writing code.

The specification should already tell us what the thing is supposed to do, how it fits into Ceylon, and how we will know when it is actually finished.

Scope creep is still circling the building

There have also been some discussions about future work.

Some of those are useful.

Some of them are clearly scope creep wearing a fake mustache.

I will resist.

Probably.

The important part is that discussion is not implementation.

Ideas can be written down.

Architectural questions can be researched.

Specifications can be cleaned up.

But the source tree stays on hold until the current qualification pass is done.

That boundary matters.

Otherwise a "temporary pause for testing" turns into three new subsystems and a completely different roadmap by Thursday.

I know how this works.

Then comes cleanup

Assuming this qualification pass does what I want it to do, the next likely step is not immediately another feature sprint.

'Tis the season for a refactor and optimization tranche.

By then we should have a much clearer picture of where the awkward seams are, where duplicated logic has accumulated, which assumptions need to be simplified, and which parts are worth optimizing because measurement says they need it.

That is the right time to clean the platform up.

After we have tested it thoroughly enough to understand its behavior.

Before we start stacking another layer of applications and services on top.

Refactoring a known-good system is one thing.

Refactoring a system while simultaneously wondering whether the old behavior ever worked correctly is quite another.

I prefer the first option.

So, not much to report

That may be the shape of the journal for a little while.

If we find something genuinely interesting during testing, I will write about it.

If a failure teaches us something useful about the architecture, that is worth documenting too.

But some days may simply end with:

the testing continued,

a few things were repaired,

and the hold remains in place.

That is not a lack of progress.

Right now, that is the progress.

When coding resumes—probably in a couple of days—I want it to resume from the closest thing to a known-good Ceylon platform we can produce.

Then we clean it up.

Then we optimize what actually needs optimizing.

Then we move forward.

In that order.

For once.