Show HN: The C3 programming language (C alternative language)

Original Article ↗ Hacker News Discussion ↗

Overall impressions & goals

  • Several users tried C3 for small tools and game-related work and found it a substantial ergonomic improvement over C while preserving the C ABI and familiar semantics.
  • Pre‑1.0 rough edges exist, but people praise the design as pragmatic and “fun” rather than experimental or academic.

Comparison with Zig, Odin, Jai, Nim, etc.

  • C3 is described as philosophically closer to Odin (focus on “joy of programming”, convenience, open extension) than to Zig.
  • Zig is seen as emphasizing minimalism, explicitness, and composing small primitives instead of adding convenience functions, which some view as a “puzzle” style of programming.
  • C3 and Odin trade some explicitness for ergonomic standard library helpers; Zig users may prefer constructing solutions from smaller pieces.
  • C3 is available to download and try; this is contrasted with Jai’s closed beta model.
  • Some note all these “C alternatives” are still pre‑1.0 and carry churn risk compared to C.

Types, vectors, and ergonomics

  • C3 has built‑in vector types and swizzling (e.g. a.xxzx), which users like for 3D/graphics work; this is compared with Zig’s SIMD vectors (no swizzle) and Odin’s influence.
  • Discussion of missing features: tagged unions are desired and apparently planned; no native fixed‑point yet, though it could be implemented via user types/methods and there’s an open proposal.

Macros, compile‑time, errors, and contracts

  • C3 keeps macros but moves “conditional compilation” into parsed compile‑time constructs ($if, $switch, @if), not a C-style text preprocessor.
  • Contracts (@require) are used for programmer errors; recoverable conditions use “faults” (faultdef and return SOME_FAULT?).
  • Example: Base32 implementation uses contracts for impossible API uses and faults for invalid data; wrappers can reclassify contract checks into faults if desired.
  • Future work aims to statically prove some contract violations at compile time.

FFI, C ABI, and single-header libraries

  • C3 targets LLVM and follows the C ABI; interop with C libraries (including OpenGL, raylib, libtmx) is reported as straightforward.
  • Single-header C libraries that require a defining macro (#define FOO_IMPL) can be integrated, but their compilation is delegated to a native C compiler, which limits cross‑compilation.

Memory model, RAII, and ownership

  • C3 intentionally does not introduce RAII/destructors or a formal ownership system; it positions itself as a C alternative, not a C++/Rust competitor.
  • Resource management is handled via:
    • Temp/stack-like allocators with explicit push/pop scopes.
    • Macro patterns with trailing blocks to scope resources (files, sockets, etc.).
  • Some commenters argue this is “halfway” and advocate for full destructors; others prefer explicit contexts, claiming destructors can obscure control flow.

Syntax debates: fn, ::, const, switch

  • fn is controversial: some dislike the break from C; proponents say it improves greppability, lambda syntax, and symmetry with macros. Removing it is considered unlikely but not impossible post‑1.0.
  • :: is used for modules/paths, . for member access. Supporters like the visual disambiguation and avoidance of shadowing problems; critics find :: noisy and prefer a single ..
  • C3 changes switch semantics to avoid implicit fall‑through, which is widely applauded.
  • const is pared back; there is no general “read‑only pointer” like const int*—instead, parameter direction (in/out/inout) is used.

Debugging, sanitizers, and UB / provenance

  • “Safe mode” with contracts can be kept in optimized builds (-O3 --safe=yes).
  • LLVM’s address and thread sanitizers work; memory sanitizer support is in progress.
  • Pointer provenance is acknowledged but not deeply specified; some UB notes may need revisiting. Users reference ongoing C/LLVM provenance debates as relevant for the future.

Concurrency and parallelism

  • Cross‑platform threads and basic thread pools exist, but concurrency abstractions are still sparse.
  • There is explicit disinterest in building async into the language; concurrency support is expected to evolve in the library and patterns.

Adoption, ecosystem, and churn

  • Several commenters worry about adopting any non‑C alternative in companies (“island” problem) and about churn in young languages.
  • The C3 author acknowledges this as a real issue and has written about the case against C alternatives; C3 aims for a frozen language spec at 1.0 with only stdlib/tooling changes afterward.

Community and language-politics meta-discussion

  • Long side-threads debate:
    • Perceptions of Zig/Rust communities as “evangelical” vs. largely pragmatic.
    • Accusations and defenses around V language marketing and criticism by rival language leaders.
    • Whether GitHub stars, Wikipedia pages, or books are valid measures of “real” adoption.
  • Some participants push for more cross-language curiosity and less adversarial framing; others emphasize that every language community inevitably critiques others.