No description
Find a file
shoney.arickathil 065ac99224 feat: json encode/decode + as, .wob v2 class metadata — log-watcher compiles
docs/examples/log-watcher (1285 lines, 7 files) now compiles clean: 0
diagnostics, a 35KB .wob written. corpus 71/0, woc runtest 565/0, every wovm
unit gate green (both dispatch flavors).

- .wob v2: each class row gains three u32 per-field arrays — the field's NAME
  constant, the CLASS it refers to (or the json-raw marker), and a container
  field's ELEMENT kinds. json is then a runtime service driven by metadata
  instead of per-type generated code. loader/emitter/disassembler/test
  assembler all read and write v2; field-name constants are interned with the
  rest of the pool (interning during serialization silently loses them)
- runtime/src/json.c (new): encode by static kind + object headers + class
  table (nested records need no static knowledge); decode parses and BINDS
  straight into the target class — keys matched to field names, nested objects
  built as the field's class, arrays as a multi of the field's element kind,
  unknown keys skipped, absent keys nil. Malformed input is nil, never a trap
- `as`: `json.decode(text) as T` is the one cast this language has (WO-E403
  for any other `as`, and for a bare json.decode with no target type). Its
  result is `?T`, which is why the decode and the target are one instruction
- json.Value: a reserved type name for a value the source does not inspect —
  the raw JSON slice, kind TEXT, re-emitted verbatim by encode
- docs: 00-wob-format.md is now the v2 reference (class metadata, TRY/ENDTRY,
  the whole builtin surface, WO_T_IO); 08-builtin-surface.md documents the
  text/container builtins, the OS modules with their predeclared records, and
  json's two documented limits (Bool encodes 0/1, floats truncate)

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
2026-08-14 17:08:46 +02:00
.dev feat: milestone 1 complete — .wob emitter, conformance corpus, single binary; GC redesign specced 2026-08-11 19:31:26 +02:00
.vscode add wo-rt-c: C runtime prototype, phases A-F shipped 2026-06-12 23:05:13 +02:00
compiler feat: json encode/decode + as, .wob v2 class metadata — log-watcher compiles 2026-08-14 17:08:46 +02:00
crates remove scrap 2026-08-08 05:01:33 +02:00
docs feat: json encode/decode + as, .wob v2 class metadata — log-watcher compiles 2026-08-14 17:08:46 +02:00
infra scaffold sibling crates, multi-app ecommerce, REST + concurrency docs 2026-05-04 13:39:58 +02:00
prototypes/wo-db remove scrap 2026-08-08 05:01:33 +02:00
runtime feat: json encode/decode + as, .wob v2 class metadata — log-watcher compiles 2026-08-14 17:08:46 +02:00
scripts feat(compiler): iteration 5 Tasks 1-4 — modules, language surface, switch, typedef records + enum variants 2026-08-12 14:40:07 +02:00
static scaffold sibling crates, multi-app ecommerce, REST + concurrency docs 2026-05-04 13:39:58 +02:00
templates scaffold sibling crates, multi-app ecommerce, REST + concurrency docs 2026-05-04 13:39:58 +02:00
tests/corpus feat: systems stdlib OS half — fs, time, env, net, proc 2026-08-14 16:54:31 +02:00
.gitignore feat: milestone 1 complete — .wob emitter, conformance corpus, single binary; GC redesign specced 2026-08-11 19:31:26 +02:00
.gitmodules begin 2026-04-05 00:45:02 +02:00
Cargo.lock add http runtime 2026-05-04 23:50:16 +02:00
Cargo.toml abstract syntax tree and parser prototype 2026-04-21 03:28:25 +02:00
CLAUDE.md add skills as symlinks 2026-08-08 05:33:19 +02:00
justfile feat: milestone 1 complete — .wob emitter, conformance corpus, single binary; GC redesign specced 2026-08-11 19:31:26 +02:00
prompt.md next oer board 2026-07-12 05:47:40 +02:00
README.md add skills as symlinks 2026-08-08 05:33:19 +02:00

writeonce

A declarative full-stack programming language. You write .wo files; the runtime compiles them into a binary that owns the database, serves REST, and pushes live subscriptions — no external database, no external web server, no frontend framework.

Think Go + Postgres + net/http + Phoenix LiveView, folded into one language and one binary.

persistant database

  • reads and writes database to RAM, persist data to postgres SQL.
  • The entire database lives in RAM; every committed write is mirrored to PostgreSQL as a backup — asynchronously, behind the runtime's own WAL, never in the read or ack path. Set WO_PG=postgres://user@host:5432/db and every type's rows appear as a Postgres table (named by its @table(name: ...) annotation) that you can query with plain psql. Plan and phases: docs/plan/16-postgres-mirror.md; try it: just pricing-pg-demo.

Quickstart

git clone https://github.com/shoneyJ/writeonce
cd writeonce
cargo run --bin wo -- run docs/examples/blog     # serve the sample blog on :8080
curl http://127.0.0.1:8080/api/articles          # it's a real REST API now

See .dev/reference/rest/blog.rest for a preconfigured HTTP-request file that drives the whole sample — open it in VS Code (with the REST Client extension) or JetBrains and click "Send Request" on each block.

What this repository contains

Path What it is
crates/rt/ The new .wo language runtime — lexer, type-DSL parser, in-memory engine, axum REST server. Produces the wo binary.
crates/{ql,value,engine,txn,db,wal,sub,http,gen,policy,logic,service,ui,app}/ 14 empty placeholder crates scaffolded for Phases 2–6. Real code extracts from rt/ as each phase activates.
docs/runtime/wo-language.md Start here. The language overview: toolchain, hello-world, stdlib, client model.
docs/runtime/database.md The 7-phase engineering series that drives the runtime's design.
docs/examples/blog/ Sample .wo project: blog with articles, authors, tags, comments. ~200 lines.
docs/examples/ecommerce/ Sample .wo project: storefront + live order-ops table + cross-paradigm checkout. ~300 lines.
prototypes/wo-db/ C++ prototype of the query-layer engine (SQL + Cypher + document paths, RETURNING aliases, LIVE stub). ~2k lines, smoke tests pass. Reference implementation the Rust port follows.
.dev/reference/rest/ .rest files (VS Code REST Client / JetBrains HTTP format) for manually testing the running prototype.
.dev/reference/crates/ The v1 writeonce blog — 13 Rust crates implementing the original .seg + sidecar-index storage engine and .htmlx templating. Preserved as a nested workspace; see .dev/reference/README.md.

Current stage

The runtime is under active development. Each stage lands as an independently shippable cut:

Stage What works Status
1 wo run <dir> discovers every .wo file under a directory ✅ shipped
2 Type-DSL parser, in-memory engine, REST CRUD (list / get / create / update / delete) generated from service rest blocks, JSON bodies with auto-id, default-value seeding, partial-update PATCH ✅ shipped — cargo run -- run docs/examples/blog
3 LIVE subscriptions over WebSocket, delta frames on commit, me / session layer pending
4+ Transactional fns (fn checkout in txn snapshot), row-level policies, type-attached triggers, ##ui SSR, WAL durability, codegen see docs/runtime/database.md

cargo test --lib at the root runs 14 unit tests covering the lexer, parser, compiler, and engine. Stage-3 endpoints respond 501 Not Implemented until they land.

Build & test

cargo build                                         # builds all 15 crates (only `rt` has real code)
cargo test --lib                                    # 14 unit tests

cargo run --bin wo -- run docs/examples/blog       # serve the blog sample
cargo run --bin wo -- run docs/examples/ecommerce  # serve the ecommerce sample

# Override the listen address
WO_LISTEN=127.0.0.1:9000 cargo run --bin wo -- run docs/examples/blog

The v1 codebase (reference)

The original writeonce blog engine — 13 crates, flat-file .seg storage, sidecar indexes, .htmlx templates, hand-rolled epoll event loop — moved to .dev/reference/crates/ when the new runtime was scaffolded. It's a nested Cargo workspace:

cd .dev/reference/crates
cargo build                   # all 13 v1 crates still compile
cargo test                    # 12 unit tests, 1 ignored integration test

V1 crates keep the wo- prefix (wo-seg, wo-store, …). The new runtime crates dropped it (ql, value, engine, …). docs/runtime/database/07-wo-seg-migration.md is the phased coexistence plan for replacing v1 with the new runtime — abstract behind a trait, dual-write, cut over, decommission.

License & status

Work in progress. Nothing here is stable. Read the language overview in docs/runtime/wo-language.md if you want to know the shape; read the phase docs if you want to see the engineering plan; look in docs/examples/ if you want to see what the end product feels like.