Krypton 2.3.0

The compiler stopped needing C. Krypton 2.3.0 is fully clang/gcc-free across build, run, imports, and self-host — and the toolchain now hosts itself on macOS (arm64), Linux (x86-64), and Windows (x86-64).

⚠️ Breaking changes

• kcc.sh removed. Use kcc — the new Krypton-native driver (compiled from kcc.ks, no bash). Repoint any scripts/tooling that called kcc.sh.
• C path removed. --c / --gcc / --llvm are gone (hard error). The native pipeline is the only path now.

Highlights

• Clang/gcc-free self-host on all three platforms — fixpoint byte-stable.
• Native StringBuilder (growing-capacity, doubling realloc): amortized O(1) append. Append-heavy code goes from minutes to seconds; self-host RAM drops sharply.
• Krypton-native kcc.ks driver replaces the bash kcc.sh.
• Linux backend parity: first-class functions/closures (FUNCPTR/callPtr, k:fp), int-arg builtins, library-file + GC-diagnostic fixes. New --aarch64 cross-compile (--arm64 kept as an alias).
• Windows: kcc.exe/kcc-bin.exe driver/backend split, native krypton_rt.dll StringBuilder, kr.exe Swift-like auto-wrap + REPL, -e quoting fixes.
• macOS: Mach-O self-host crash fixed; StringBuilder already at parity; fresh-clone build/install fixed.

Install

macOS (arm64)

Homebrew (recommended):

brew install t3m3d/krypton/krypton

Or the tarball (no clang, no clone):

tar xzf krypton-2.3.0-macos-arm64.tar.gz
cd krypton-2.3.0-macos-arm64 && ./install.sh
kcc --version

A double-click installer is also attached: krypton-2.3.0-macos-arm64.pkg.

Linux (x86-64)

tar xzf krypton-2.3.0-linux-x86_64.tar.gz
cd krypton-2.3.0-linux-x86_64 && ./install.sh
kcc --version

aarch64: cross-compile from an x86-64 host with kcc --aarch64 prog.k -o prog (no native aarch64 toolchain this release).

Windows (x86-64)

Run krypton-2.3.0-windows-x86_64.exe'. Associates .ks→kr.exe, .k→kcc.exe`.

Known limitations

• macOS: byte buffers, env-map, unixConnect, and some settings/fs builtins aren't on the macho backend yet (parity backlog; all language basics work).
• Linux: no native GUI backend yet (X11 in progress — GUI apps are Windows/macOS for now); splitBy unreliable on the native backend; no native aarch64 toolchain (cross-compile only).