fluid-core/docs/adr/0001-go-as-implementation-language.md

47 lines
1.6 KiB
Markdown
Raw Normal View History

# ADR-0001 — Go as the implementation language
**Status:** accepted · **Date:** 2026-09-04
## Context
fluid-core had no implementation. Three stacks were credible: Go, TypeScript
and Python. The specification (`ArchitectureBlueprint.md` §4243) points at a
long-running gateway, a router, an append-only store and, later, a Kubernetes
controller with custom resources.
Python is the obvious first reach — pydantic maps almost literally onto the
record schemas, and it matches existing tooling in sibling repositories.
TypeScript is attractive because the first consumers are platform SDKs with
strong TypeScript clients.
## Decision
fluid-core is written in Go.
## Rationale
The always-on component is infrastructure: proxy, router, registry, evidence
store. That is Go's centre of mass. A single static binary is also the most
credible form of "drop this in front of any API" — the promise ADR-0002 makes.
Blueprint §43 maps 1:1 onto controller-runtime, so the Kubernetes path stays
open at no extra cost.
Go is the lowest-entropy of the three to debug, which matters under a per-task
budget policy.
## What we gave up
Record modeling is more verbose in Go than in Python. This is paid once, behind
generated types (ADR-0003), rather than continuously.
The generative Daimon (Blueprint Phase D) would be easier in Python. ADR-0002
makes that a non-issue: the Daimon is a separate process speaking the wire
contract, so it may be written in whatever suits it.
## Consequences
- No third-party Go modules are used where the standard library suffices; the
build stays offline-capable.
- Python remains a build-time dependency for schema validation only.