The mesh can compile Go, which is why nothing delivered the host #154

2026-09-30T07:49:07Z

jschoubben commented

2026-09-30 07:49:07 +00:00

First of two stages for novox/hq issue 142. ADR 0141's progressive insight names what is missing, and this is the first: nothing can compile it.

The toolchain list was a closed set of typescript and python. Its warning — every language is another implementation of the contracts modules share — does not attach to Go: Go is how the host, the control plane and the builder are written, and none of them is a module in that sense. The host is what applies modules.

The entry names mesh-tools-go as its base rather than pinning an upstream release in this source (ADR 0142, 0044) — named and not pinned means the mesh answers with the copy it holds.

Two things beyond the list also assumed one language, and both would have failed right after the entry was added:

sourcesFor turned every entrypoint into a .ts file. The extension is the toolchain's now.
The output directory was left to the compiler. tsc --outDir makes one; go build -o writes into a directory and does not make it, failing with a message about a path rather than a build. Made here for every toolchain.

A toolchain also now says what it is pointed at: a file list from the module's entrypoints, or the one package the artifact is built from. Pointing go build at a file list builds a program out of exactly those files and ignores the rest of the package — a missing symbol rather than a legible refusal.

Static and -trimpath: a machine holds a file, not a container, so a binary needing a libc it did not bring is a delivery that works until a machine differs; and a version comes from where a component sits rather than from its linker.

New repository novox/mesh-tools-go carries the base module.

make check: only the pre-existing failure.

First of two stages for novox/hq issue 142. ADR 0141's progressive insight names what is missing, and this is the first: **nothing can compile it.** The toolchain list was a closed set of typescript and python. Its warning — every language is another implementation of the contracts modules share — does not attach to Go: Go is how the host, the control plane and the builder are written, and none of them is a module in that sense. The host is what *applies* modules. The entry names `mesh-tools-go` as its base rather than pinning an upstream release in this source (ADR 0142, 0044) — named and not pinned means the mesh answers with the copy it holds. **Two things beyond the list also assumed one language**, and both would have failed right after the entry was added: - `sourcesFor` turned every entrypoint into a `.ts` file. The extension is the toolchain's now. - The output directory was left to the compiler. `tsc --outDir` makes one; `go build -o` writes into a directory and does not make it, failing with a message about a path rather than a build. Made here for every toolchain. A toolchain also now says **what it is pointed at**: a file list from the module's entrypoints, or the one package the artifact is built `from`. Pointing `go build` at a file list builds a program out of exactly those files and ignores the rest of the package — a missing symbol rather than a legible refusal. Static and `-trimpath`: a machine holds a file, not a container, so a binary needing a libc it did not bring is a delivery that works until a machine differs; and a version comes from where a component sits rather than from its linker. New repository `novox/mesh-tools-go` carries the base module. `make check`: only the pre-existing failure.

jschoubben added 1 commit 2026-09-30 07:49:07 +00:00

The mesh can compile Go, which is why nothing delivered the host 0983b00284

novox/hq 04-ISSUES/142, and ADR 0141's own progressive insight naming
this as the first of two things missing: "nothing can compile it". The
toolchain list was a closed set of typescript and python, whose warning —
every language is another implementation of the contracts modules share —
does not attach to Go. Go is how the host, the control plane and the
builder are written, and none of them is a module in that sense: the host
is what APPLIES modules.

The toolchain names mesh-tools-go as its base rather than pinning an
upstream release here (ADR 0142, 0044): named and not pinned means the
mesh answers with the copy it holds, and moving compiler is a build
instead of an edit to this file.

Two things beyond the list also assumed one language, and both would have
failed after the entry was added:

  sourcesFor turned every entrypoint into a `.ts` file. The extension is
  the toolchain's now — one language's file extension written into the
  code that serves every language is a wall the next one hits.

  The output directory was the compiler's to create. tsc --outDir makes
  one; go build -o writes into a directory and does not make it, failing
  with a message about a path rather than about a build. Made here for
  every toolchain, because which compilers are forgiving is not something
  a reader should have to know.

And a toolchain now says what it is pointed at: a file list from the
module's entrypoints, or the one package the artifact is built `from`.
Pointing `go build` at a file list builds a program out of exactly those
files and ignores the rest of the package — a missing symbol rather than a
legible refusal.

Static and -trimpath: what a machine holds is a file, not a container, so
a binary needing a libc it did not bring is a delivery that works until a
machine differs; and a version comes from where a component sits rather
than from its linker, so two builds of one commit are the same bytes.

jschoubben merged commit bd7ee12938 into main

2026-09-30 07:49:14 +00:00

jschoubben deleted branch feat/142-the-mesh-compiles-its-own-go

2026-09-30 07:49:14 +00:00

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: novox/mesh-controller#154