C-Comparison Synthesis: C3, Odin, Hare, Val (Hylo), Cake

Synthesis deliverable of episode 1-A (prompts/episodes/02-episode-plan.md). It pools the five C-comparison study notes and feeds phase 2 (language specification). The comparison baseline is C.

This document compares the five studied candidates — C3, Odin, Hare, Val (now Hylo), and Cake — on the criteria in prompts/common/04-c-comparison-criteria.md (authoritative; unmodified). Across the five it states what has been tried before, what worked, and what did not work; it selects the ideas Elseon should use and the ideas Elseon should avoid, each with reasoning and the source study; it recommends candidates to drop from the list (the human decides); and it proposes revisions to criteria that proved weak or missing (proposals only, the criteria file is not modified).

1. Inputs, method, and provenance

Inputs and their roles:

Method and provenance rules:

2. The five candidates as the studies left them

Candidate Refined identity (per study) Survey camp Study verdict Backend
C3 Applications-targeted “evolution of C”; documented fork of C2 that outgrew it; modules replace headers; no PFE header ingestion; safe-mode checks vanish at -O2 Camp 1 (with C2 as one lineage) Idea source — the strongest Camp 1 sibling, not a model LLVM
Odin Data-oriented “C alternative”; C statement shape but type-last declarations; explicit allocators with an implicit per-scope context default; ships real software; self-hosted compiler Camp 1 Idea source, not a model LLVM
Hare Spec-first “boring” systems language; name-last declarations; QBE backend, not LLVM; manual FFI; free-software platforms only; builds real kernels with the stock toolchain Camp 1 Idea source with selected model aspects QBE
Val / Hylo Research language on mutable value semantics; Swift-shaped surface; renamed from Val to Hylo 2023; automatic compile-time memory management; pre-1.0 and officially “not ready to be used yet” Camp 1 (row wording needs correction) Idea source, not a model LLVM
Cake Camp 2 superset “C23 and beyond”; a C front end that transpiles to C89; compile-time ownership checks on ordinary C pointers; single-maintainer, GPLv3 plus AI-training addendum Camp 2 Idea source; the superset strategy itself is what Elseon avoids None (emits C89)

Row corrections and refinements the studies established:

3. Comparison on the criteria

3.1 Positioning (criteria dimension 1)

3.2 Kernel-test adherence (criteria dimension 2)

The four Elseon guarantees are assessed per candidate; a study’s “stated”, “observed”, and “unverified” markings are preserved.

No garbage collection / no hidden runtime.

No hidden allocations.

No hidden control flow.

Deterministic memory layout.

C-compatibility (the fourth kernel-test element).

3.3 Syntax family (criteria dimension 3)

3.4 C interoperability and the PFE angle (criteria dimension 4)

3.5 Toolchain (criteria dimension 5)

3.6 Ecosystem and adoption (criteria dimension 6)

4. What has been tried, what worked, and what did not work

4.1 Recurring patterns across the five

4.2 What worked (with where it was observed)

4.3 What did not work (with where it was observed)

4.4 What nobody has tried — the PFE gap

5. Use list for Elseon

Each item names the reasoning and the source study. Admission remains subject to the kernel test; items from candidates whose own semantics fail the test are borrowed as mechanisms only.

Memory and allocation:

  1. Explicit allocators as data, with any per-scope default spelled out in source — reasoning: Odin proves the mechanism works and ships software; the default must be source-visible to satisfy Elseon’s no-hidden- allocations rule (Odin study §2, §9).
  2. Scope-based arena idiom with bulk free — reasoning: C3’s temp allocator with an explicit @pool and Odin’s temp allocator with free_all give per-frame memory with manual predictability (C3 study §7, §9; Odin study §9).
  3. Tracking allocator for leak and bad-free detection at debug time — reasoning: cheap, build-time-gated verification observed working in Odin (Odin study §7, §9).
  4. Defined out-of-memory behavior: abort by default, a recoverable error path, and nullable results — reasoning: Hare specifies OOM instead of leaving it hidden, matching “no hidden allocations” (Hare study §2, §9).
  5. No-allocation operation variants plus a strict-mode compile flag that rejects any implicitly allocating construct — reasoning: Hare’s static append/static insert and -Fstrictoom enforce the guarantee at kernel build time (Hare study §2, §9).
  6. Compiler-known pointee contracts for standard allocators (_Uninitialized/_Clear on malloc/calloc) — reasoning: Cake catches use-before-init and null passing at compile time with zero runtime cost (Cake study §7, §9).

Errors and control flow:

  1. Value-returning errors with no exceptions — reasoning: proven in three candidates (C3 optionals with pointer-sized faults; Odin multi-return with or_return spelled in source; Hare tagged unions with exhaustive match and ?/!) with zero hidden control flow (C3 study §7, §9; Odin study §9; Hare study §7, §9).
  2. Explicit defer for scope-exit resource management — reasoning: matches Elseon’s explicit-resource-management rule with no hidden control flow (C3 study §9; Odin study §9; Hare study §9; language doc §4).
  3. Nullable versus non-nullable pointer types with mandatory null tests — reasoning: Hare’s cheap, explicit safety fits Elseon’s checked call boundaries for ingested C headers (Hare study §7, §9).
  4. Bounds-checked slices as first-class types with an explicit unbounded escape hatch — reasoning: deterministic, ABI-friendly iteration in C3, Odin, and Hare; the checks must be explicit per Elseon’s standard (C3 study §9; Hare study §9; Odin study §9).
  5. Mutable-value-semantics mechanisms where they fit: a semantic & mutation marker, subscripts/inout projections, consuming moves, and definite (de)initialization as a compiler pass — reasoning: Val/Hylo’s research shows alias-free mutation with visible markers; Elseon takes the mechanisms, not the automatic management, and uses the pass technique in conformance checks (Val study §7, §9).

Determinism and layout:

  1. Fixed-width integer types, defined wrapping, no implicit narrowing, defined evaluation order, zero-initialization with an opt-out — reasoning: C3 proves deterministic semantics C never standardized (C3 study §7, §9).
  2. A deterministic-layout toolbox: C-rules default layout plus explicit @packed/@align/endianness control and bit-accurate layout types — reasoning: C3’s attributes and bitstruct and Odin’s #packed/ #align/#raw_union/endian-specific integers give the vocabulary for Elseon’s language-specified layout (C3 study §2, §9; Odin study §2, §9).
  3. Compile-time layout verification via size_of/offset_of/#assert — reasoning: Odin checks layout contracts at build time; Elseon’s backend conformance tests need exactly this (Odin study §2, §9; language doc §6).
  4. Spec-defined struct layout with source-order offsets as the fallback contract — reasoning: Hare demonstrates specifying offsets per platform; Elseon goes further and guarantees C compatibility at the semantic layer for ingested types (Hare study §2, §9).

Modules, toolchain, and the C boundary:

  1. Module system replacing user headers and the preprocessor — reasoning: proven viable at standard-library scale in C3 and Hare; the same instinct as Elseon’s semantic header import (C3 study §7; Hare study §7; survey).
  2. Compiler-understood semantics for constructs C implements with macros (assert, offsetof, type traits) — reasoning: Cake shows the compiler must understand semantics, not text — the same instinct as Elseon’s semantic header import (Cake study §7, §9).
  3. Compile-time-only ownership and nullability checks placed at Elseon’s C-header boundaries — reasoning: Cake’s _Owner/_Opt/_View contracts give lifetime safety with zero runtime cost and incremental adoption; Elseon makes them part of the boundary system rather than optional annotations (Cake study §7, §9).
  4. Numbered, configurable, IDE-integrated diagnostics (SARIF, gcc/msvc formats) and style checking from day one — reasoning: Cake shows tooling quality is a differentiator Elseon should ship early (Cake study §7, §9).
  5. Self-hosting the compiler and standard library as dogfooding — reasoning: the strongest single evidence a systems language is usable, shown by Odin’s compiler and Hare’s standard library (Odin study §7; Hare study §7).
  6. LLVM as the backend, accepting that codegen will dominate compile time — reasoning: three candidates run LLVM and C3’s author measured the cost and still recommends it as the best first backend; matches Elseon’s plan (C3 study §5, §7; language doc §6).
  7. Freestanding environment as a first-class spec concept with a user-supplied runtime and a short documented list of compiler-emitted functions — reasoning: Hare’s rt contract is the clean kernel-adjacent toolchain boundary Elseon should specify the same way (Hare study §7, §9).
  8. One-command build, public CI, and integrated test/benchmark/docgen in the driver — reasoning: Odin’s onboarding and C3’s @test/@benchmark/ docgen story keep CI-verifiability cheap (Odin study §7, §9; C3 study §7, §9).
  9. A web playground for language evaluation — reasoning: Cake’s reachable playground is a zero-install harness useful for Elseon’s conformance corpus (Cake study §7, §9).

Process and governance:

  1. Specification-first design that defines behavior where C has undefined behavior, with conservative optimizer rules — reasoning: Hare proves the discipline is workable and gives a testable contract for conformance tests (Hare study §7, §9).
  2. A permanent feature freeze at 1.0 with source-compatibility-only standard-library changes — reasoning: Hare’s “boring” 100-year plan matches Elseon’s simplicity goal; but freeze only semantics that are already settled (Hare study §7, §9; Hare study §8 on const).
  3. Feature-removal discipline and honest public accounting — reasoning: C3’s removals and post-mortems freed compiler complexity and are a governance pattern for a pre-1.0 language (C3 study §7, §9).
  4. The C-standard-ahead laboratory as PFE for language evolution — reasoning: Cake’s tracking of C2Y proposals and WG14 N-documents gives Elseon a live design corpus for feature justifications (Cake study §7, §9).
  5. Guaranteed cost invariants stated as language promises — reasoning: Val/Hylo’s planned closure-allocation guarantee shows the value of spelling out invariants; Elseon should promise layout and allocation invariants the same way (Val study §7, §9).
  6. Safe-by-default framing with explicit, auditable unsafe opt-in at the C boundary — reasoning: Val/Hylo’s framing is workable; Elseon mirrors it for checks on ingested C headers (Val study §7, §9).

6. Avoid list for Elseon

Each item names the reasoning and the source study.

Memory and allocation:

  1. Implicit allocation sites behind defaults — uninitialized-container defaults and a compiler-injected @pool (C3), and context.allocator defaults in core builtins, dynamic-array growth, and fmt (Odin) — reasoning: hidden allocations by Elseon’s standard; Odin itself had to ban implicit dynamic literals in dev-2025-01 (C3 study §2, §9; Odin study §2, §8, §9).
  2. Automatic memory management with compiler-inserted deinitialization and copy-on-write containers — reasoning: Val/Hylo’s hidden scope-exit behavior and hidden sharing fail the kernel test, and deterministic layout must not rest on COW (Val study §2, §9).
  3. An implicit per-scope context threaded through the calling convention — reasoning: Odin’s hidden state flow is a documented source of bugs (the context cannot be updated in a loop) (Odin study §2, §8, §9).

Control flow and semantics:

  1. Mode-dependent safety: checks only in safe mode that vanish at -O2 and assert degrading to an optimization hint — reasoning: C3’s silent semantic drift is hidden control flow whose meaning changes with optimization level (C3 study §2, §9).
  2. Default-on bounds and type-assert panics as hidden branches — reasoning: Odin’s checks must be explicit opt-in in Elseon, not program-wide defaults (Odin study §2, §9).
  3. Bounds/OOM aborts as the only defined failure path — reasoning: Hare gives no language-level way to configure per-target failure policy; Elseon should let failure behavior be explicit and compilable-out, never silently different (Hare study §9).
  4. Implicit @init/@fini with unspecified ordering — reasoning: Hare’s hidden control flow fails Elseon’s determinism rule (Hare study §2, §9).
  5. Scope-exit _Defer and postfix checked ! as surface syntax — reasoning: Cake’s implicit execution points violate Elseon’s zero-hidden-control-flow standard unless re-expressed as explicit statements (Cake study §3, §9).

Syntax surface:

  1. Type-last declarations and expression-semicolon function bodies — reasoning: Odin’s x: int and Hare’s let x: int/= { ... }; are needless friction against Elseon’s C type-first family (Odin study §9; Hare study §3, §9).
  2. Swift-shaped surface (fun, let/var, inout, subscripts, argument labels, & redefined) — reasoning: Val/Hylo leaves Elseon’s C/JavaScript syntax family entirely (Val study §3, §9).
  3. Mandatory case-based identifier grammar for parseability — reasoning: C3’s lexer rule sacrifices C identifier freedom for no kernel-test benefit (C3 study §3, §9).
  4. Semicolon-optional syntax — reasoning: Odin’s marginal friction helps neither machine nor reader of C-family code (Odin study §9).

C interop and the PFE boundary:

  1. Removing const/volatile qualifiers and atomics keywords — reasoning: C3’s removals harm C-header ingestion fidelity and const-correctness, which Elseon’s PFE needs (C3 study §3, §9).
  2. Shipping a const qualifier with weak, inconsistently enforced semantics for years — reasoning: Hare’s const debt forced a planned overhaul that “will break nearly every existing Hare codebase”; settle semantics before the feature freeze (Hare study §8, §9).
  3. Manual forward-declaration FFI as the primary C-interop path — reasoning: every study documents the re-declaration tax and none has header ingestion; Elseon’s differentiator is ingesting the headers, with hand externs kept only as an escape hatch (C3 study §4, §9; Odin study §4, §9; Hare study §4, §9; Cake study §4).
  4. Superset-of-C as the Elseon strategy — reasoning: extending C in place keeps C’s semantic baggage and cannot give checked boundaries at the header edge; Elseon’s PFE is the third position that avoids both Camp 2 failure modes (Cake study §8, §9; survey).
  5. Optional, annotation-only safety without mandatory boundaries — reasoning: if checks can be silenced per function or bypassed by raw-pointer extraction, the guarantee is advisory (Cake study §8, §9).
  6. Inter-procedurally blind analysis with suppression escapes — reasoning: suppressions accumulate exactly where bugs live; plan cross-function inference or document the local granularity (Cake study §8, §9).

Toolchain and strategy:

  1. A lowered old-C codegen target — reasoning: Cake’s C89 floor becomes the language’s ceiling, with unimplementable features and lossy rewrites; Elseon emits through LLVM (Cake study §8, §9).
  2. A small-backend strategy in the style of qbe with a stated 25%–75% performance range — reasoning: Elseon needs LLVM-grade optimization and already chose LLVM (Hare study §8, §9).
  3. Compiler core restarts — reasoning: Val/Hylo’s archived generations and the hylo-new restart cost years; Elseon should treat the front-end/backend split and its conformance corpus as stable commitments (Val study §8, §9).
  4. Name renames and domain churn — reasoning: Val-to-Hylo destroyed link equity and discoverability; Elseon should fix its name and URLs once (Val study §8, §9).
  5. Announcing headline interoperability years before shipping — reasoning: Val’s “Interoperable with C++” never shipped; Elseon’s PFE claim should be gated on a working header-ingestion pipeline from milestone one (Val study §8, §9).
  6. Marketing the language by what it replaces — reasoning: C3’s documented “C alternative” mistake, Odin’s conceded lack of a killer feature, and Hare’s rejected press framing; position by purpose and domain (C3 study §8; Odin study §8; Hare study §1).
  7. Decade-long pre-1.0 breaking changes — reasoning: C3 breaks in every 0.x.0 toward a 2028 1.0; Elseon should freeze its core earlier (C3 study §8, §9).
  8. Platform overreach without CI or testing — reasoning: C3’s untested WASM/freestanding rows and Odin’s macOS AMD64 CI drop are lessons in scope discipline (C3 study §8, §9; Odin study §8).
  9. A draft specification left non-authoritative for years — reasoning: Hare’s spec is still a draft in 2026 while the language is in use; set a hard spec-authoritative milestone (Hare study §8, §9).
  10. No generics as a permanent constraint — reasoning: Hare’s hand-rolled hash tables are a self-imposed burden with no kernel-test justification; nothing in the kernel test forbids safe, explicit generics (Hare study §8, §9).
  11. Compiler licensing that blocks reuse — reasoning: Cake’s GPLv3 plus AI-training addendum makes embedding problematic; take ideas, not code (Cake study §5, §8, §9).
  12. Letting core documentation rot to “outdated” status and an open-ended “not ready” status without shipped milestones — reasoning: Val/Hylo’s docs read as abandoned and its value proposition was untestable for four years; define what “ready” means and test it against the kernel corpus early (Val study §8, §9).

7. Candidate-drop recommendations (the human decides)

These are recommendations for the human to decide; nothing is decided here. The criteria file keeps the list provisional (“a study may recommend dropping a candidate in its verdict, and the synthesis task collects the recommendations for the human to decide”).

8. Proposed criteria revisions (proposals only)

Proposed revisions to prompts/common/04-c-comparison-criteria.md for the human to consider. The file is not modified by this task. Each proposal names the evidence that showed the criterion weak or missing.

  1. Add an identity-and-lineage check to dimension 1 (Positioning) — evidence: two of five candidates required identity work outside the criteria — C3 is a documented fork of C2 (C3 study §1), and Val was renamed to Hylo in 2023 with dead domains and naming collisions (Val study §1, §6).
  2. Add an artifact-type classification to dimension 1 — evidence: Cake is a compiler front end and transpiler whose surface IS C, so comparing it as a “language” was awkward; the survey already carries non-language entries (CHERI/Morello as a hardware repair) that the candidate concept does not describe (Cake study §1).
  3. Require an evidence-level tag (stated / observed / unverified) per kernel-test guarantee, with mode and optimization-level context where applicable — evidence: the studies answered guarantees at different standards — C3’s freestanding targets are untested and its “never-reordered” guarantee is unverified (C3 study §2); Val/Hylo’s runtime bookkeeping is unverified and its layout guarantee unmet or unverified (Val study §2); Cake’s cross-target correctness is unverified in practice (Cake study §2).
  4. Sharpen “no hidden allocations” and “no hidden control flow” to ask about source sites in every mode, not mechanisms — evidence: C3 and Odin both have explicit allocator mechanisms with implicit sites (container defaults, context.allocator), and C3’s checks vanish at -O2 (C3 study §2; Odin study §2).
  5. Add a toolchain sub-item for backend rationale, measured cost, and dogfooding evidence — evidence: C3 measured LLVM codegen at over 98% of compile time (C3 study §5); Hare’s qbe costs 25%–75% of LLVM performance (Hare study §5); Odin’s self-hosted compiler and Hare’s Hare-written standard library were the strongest usability signals (Odin study §7; Hare study §7).
  6. Add a license-and-reuse sub-item to dimension 6 (Ecosystem and adoption) — evidence: the five candidates carry five materially different license stacks (C3 MIT+LGPL 3.0; Odin zlib; Hare MPL+GPL-3.0+FDL; Val/Hylo Apache-2.0; Cake GPLv3 plus AI-training addendum), and Cake’s license alone rules out code reuse (C3 study §6; Odin study §6; Hare study §6; Val study §6; Cake study §5, §6).
  7. Ask for claimed versus observed positioning, including any first-party retrospection — evidence: C3’s author retracted the “C alternative” framing (C3 study §8), Odin’s creator concedes no killer feature and slow growth (Odin study §6, §8), and Hare rejected the press framing (Hare study §1); positioning predicted adoption failure modes better than any technical dimension.
  8. Extend the verdict classification with a mandatory candidacy line (keep / drop / merge) and permit qualified classifications — evidence: the criteria say a study “may recommend dropping a candidate in its verdict”, but none of the five did, leaving the synthesis to infer; and Hare needed the qualifier “idea source with selected model aspects”, which the model/idea-source/avoid vocabulary does not name (Hare study §9).
  9. Make the “stated by the project” versus “observed in practice” distinction mandatory per kernel-test guarantee rather than per study — evidence: application was inconsistent — C3 and Odin carried the distinction into section 2, while the value of tagging each guarantee was clearest where claims (freestanding support, layout contracts) outran observation (C3 study §2; Odin study §2; Hare study §2; Val study §2).

9. Sources and traceability