Use cases

Ship one library to five ecosystems

For SDK and library vendors.

If your library exists as an npm package, a Python package, a crate, and a Go module, you maintain several implementations of one promise: that they all behave the same. Every port is a place for them to quietly disagree, and every release multiplies the chance.

Bock collapses the ports into one source. bock build --all-targets emits a native package for each target, complete with each ecosystem's manifest: package.json for JavaScript and TypeScript, pyproject.toml for Python, Cargo.toml for Rust, go.mod for Go. Your @test functions transpile into each ecosystem's own test framework and run there: vitest, pytest, cargo test, go test. The packages you publish are plain code in each target language. No Bock runtime ships.

The proof is in the repository. textkit is a small string and slug utility library, the kind an SDK vendor ships, written once in Bock in 185 lines. Its build emits all five native packages. All nine of its tests pass through every native test runner. Its driver, compiled for each target and run on each native runtime, prints byte-for-byte identical output on all five: one checksum across five languages. Every command and every output block in the demo is captured from a real run, and the whole thing is reproducible from the repository.

See the textkit demo →

The boundary, stated plainly: v1 covers self-contained logic emitted as native packages. Parsing, validation, transformation, protocol and business rules all fit. Calling target-native libraries from Bock source is planned for v1.x. If your library is mostly a thin wrapper over platform APIs, Bock is not yet the tool for it.

Keep shared logic identical across services

For polyglot platform teams.

The same validation rules live in a TypeScript edge service, a Python data job, and a Go backend. Today their agreement is enforced by code review and convention, and it degrades one small divergence at a time, faster when agents are doing the maintenance.

Written in Bock, that shared logic is one source with five verified realizations. A change lands once, builds everywhere, and the conformance checks confirm the targets still agree before anything ships. The divergences that slip past review are exactly the kind the compiler's conformance testing exists to catch.

Adopt AI codegen with a review trail

For teams that need to answer for what their agents wrote.

Bock's compiler can call an AI model at specific stages of compilation, and the pipeline is built so that doing so never costs you an audit trail. Every AI decision is verified deterministically before it is accepted, logged in a decision manifest, and overridable. Production builds replay pinned decisions instead of consulting the model, so builds are reproducible. A deterministic fallback exists for every AI-assisted stage, and the AI path is opt-in: by default, builds are fully rule-based.

The language carries governance in its signatures too. A function that declares with Network, Storage has made a machine-checked statement about what it can touch, which turns “what can this generated code actually do?” from a review question into a compiler question.

None of this requires multiple targets. The decision manifest, the pins, and the effect checks apply to a single-target build unchanged.