Going Public: The Unglamorous Work of Being Usable

The language had an identity — a name, a metaphor, a manifesto in four letters. It did not yet have a public existence. Having a name is not the same as being available, and closing that gap is a body of work with almost no language design in it: a license, a continuous-integration setup, documentation someone else can follow, a switch of the working language to English, an organization to live under, a way to show up as a language rather than a folder of files. This closing episode of the part is about that unglamorous work, and about the fact that doing it properly is what respect for a stranger who might try the thing actually looks like.

Tiering the launch

The pre-release work was organized the way the language itself is built: minimal-honest-version first, everything else deferred. The tasks were sorted into three tiers — can’t ship without, big effect on first impression, and fine to defer — which is just the ship-the-necessary discipline turned on the release instead of the code.

The must-haves were the things whose absence would make publishing irresponsible rather than merely rough. A license, so that anyone reading the code knows what they are permitted to do with it. Continuous integration, so the claim that it builds and passes its tests is a thing a visitor can verify rather than take on trust. Documentation brought current across every page — the tutorial, the references, the changelog — because docs that lie about the current state are worse than none. And a switch to English, because an open-source project addresses a mostly-English-reading world, so the working language of the docs moved to English with the Japanese kept as translations rather than left as the master.

The first-impression tier was the organization and the act of making the repository public — real, but survivable if rushed. And the deferred tier is the more interesting one, because of what it refused to build.

What was deliberately not built

A striking omission from the launch was a package manager. It is the sort of thing a language “should” have, and it was pointedly left out, for a reason that is the ship-the-necessary discipline stated plainly: there was no adoption yet for a package manager to serve, so building one would be building infrastructure for users who don’t exist. The honest stopgap — depend on the standard library and import by git URL when you must — costs almost nothing and can be replaced the moment real demand appears. Building the package manager first would be speculating with effort; deferring it is admitting you don’t yet know the shape of the need.

The same restraint applied to syntax highlighting. Getting a new language properly recognized — its own color scheme in editors and on the code host — is not something you can simply declare; the platforms that recognize languages have thresholds a language crosses by being used, and a grammar to be written. So in the meantime, files were marked to borrow an existing language’s highlighter — a provisional arrangement, honest about being provisional, good enough to read code by while the real recognition is left to follow from real use.

Trust is the actual deliverable

Step back from the checklist and the pattern in it is a single thing: almost every must-have item is a trust signal. A license is permission made explicit — the legal counterpart to the language’s own preference for saying things outright rather than leaving them ambient. A passing CI badge is the difference between “it works on my machine” and “you can see it work on machines that aren’t mine.” Current documentation is a promise that what you read is what you get. None of these are features of the language; all of them are the reasons a stranger can take the project seriously enough to spend an hour on it. The unglamorous chores are, exactly, the hospitality — the work of making something built for oneself into something offered to others.

And there is a quiet consistency worth naming between the launch and the language. The license reserves a future option rather than fixing everything now; the package manager waits for a need it can see; highlighting borrows until it earns its own. Each is the same move the design made over and over — commit when you know, defer what you don’t, and be honest about which is which. The way a project goes public turns out to rhyme with how it was built.

From private experiment to public thing

With the license in place, the tests running green in public, the docs current and in English, and the repository open under its own organization, the language crossed the line this part was about. It stopped being “the thing I am working on” and became something that could be found, read, trusted enough to try, and — the real test — built upon by someone who was not there for any of the preceding parts.

Recognition, of course, is not granted by a launch; it accrues, or fails to, from what happens after. But the door is open, which was the whole task of this part. A working, self-hosting, named, documented, licensed language now exists in public.

Which raises the question a public and living language always faces next: what does it grow? Being usable is a beginning, not an end, and the first substantial thing this language reached for after opening its doors was one of the hardest features a language can add without betraying its principles — running more than one thing at once, safely, with the guarantees intact. Next, Part VII opens: concurrency.