Brine is young: version 0.4.0, with a self-hosted compiler that builds itself on every CI run on Linux, macOS and Windows. Until 1.0, any minor release (0.x) may change the language; 1.0 will mean a stable language and ABI, and there is a lot to do before then. The order below is a plan, not a promise.
The next steps, from the Brine README:
- Mach-O output, so macOS on Apple silicon gets native dev builds.
- A built-in linker, so builds don’t need a C toolchain.
- Arrays kept on the GPU between constructs.
- AMD and Intel GPUs through Vulkan.
- Quantifiers in contracts:
forall i in 0..n: a[i] >= 0. - An LSP server and a package manager.
| Version | What it brought |
|---|---|
| 0.1 | The core language: structs and methods, enums and match, generics, Option/Result and ?, tuples, arrays, maps, strings with methods and slices, f-strings, for a, b in, enumerate, file and process I/O, modules. Contracts and the prover. The par constructs and world. Tests, the CLI, fmt, explain, guide. The self-hosted compiler. |
| 0.2 | The Brine IR. The native x86-64 backend (COFF and ELF). C generated from the IR, in parallel translation units cached one by one. |
| 0.3 | Unicode-aware string methods. Nested tuple unpacking. print with sep= and end=. The compiler parses and proves in parallel. Unwind tables in native code. |
| 0.4 | GPU offload (CUDA and Metal) with results identical to the CPU’s. Deterministic reduction order. The native AArch64 backend for Linux. Native debug builds with DWARF and gdb pretty-printers. Prebuilt releases and one-line installers. Faster native code, strings and allocation. |
The changelog has every change.
Planned
Section titled “Planned”Backends
Section titled “Backends”- Mach-O objects, so macOS on Apple silicon gets native dev and debug builds instead of going through C.
- CodeView debug info, for Visual Studio and WinDbg.
- Register allocation and optimization passes on the IR, so native builds get closer to optimized C.
- A built-in linker and a prebuilt runtime, so builds don’t need a C toolchain at all.
- SIMD.
- MSVC support in the C backend.
- Arrays kept on the device between constructs. Today every launch copies the arrays a body reads to the GPU and the ones it writes back, so constructs that do little work per byte (a plain sum of an array) stay on the CPU.
par(...)forks and nested constructs on the GPU.- AMD and Intel GPUs, once there is hardware to test on: Vulkan compute with SPIR-V kernels (the driver loaded at run time, as CUDA is), exactly rounded
/andsqrtin the kernels, a capability check for denormals and f64, and a self-test kernel at startup that turns the GPU off if its results differ from the CPU’s. NVIDIA GPUs and lavapipe (Mesa’s CPU Vulkan) can test most of it, but not each vendor’s own shader compiler, so it waits for real devices. This includes the AMD and Intel GPUs in Intel Macs: Metal is used only on Apple GPUs for now.
WebAssembly
Section titled “WebAssembly”WebAssembly builds (--target wasm and web) are on Brine’s main branch, not yet in a release. Next:
- Threads (wasi-threads, Web Workers), so
parruns in parallel there too. Today it runs in order on one thread. - Files in the browser.
- A playground page that runs the compiler itself in the browser. The compiler already builds for WebAssembly: its generated C for itself is byte-identical to the native compiler’s.
Proofs
Section titled “Proofs”- Generic bodies checked once against constraints, rather than once per instance.
- Quantifiers in specs:
forall i in 0..n: a[i] >= 0. - Reasoning about array contents.
- Nonlinear facts such as
i * j. - Counterexamples when a proof fails.
- An LSP server, for editors.
brine fix, which applies the machine-applicable fixes diagnostics already carry in--jsonoutput.- A package manager (
brine add). brine launch --hosts, to start a multi-machineworldrun (today you setBRINE_RANK,BRINE_WORLD_SIZEandBRINE_PEERSyourself; see Environment variables).
Versions
Section titled “Versions”Brine follows Semantic Versioning. The version is set in one place in the compiler, and every release is a tagged commit with notes in the changelog.
| Release | Means |
|---|---|
| 0.x.0 (minor) | new features or breaking changes: the language, the CLI or the results of a program may change. Breaking changes are marked in the changelog with how to migrate. |
| 0.x.y (patch) | fixes only |
| 1.0.0 | a stable language and ABI: from then on, breaking changes only in a new major version |
Versions move one step at a time, and only the maintainer decides when 1.0 happens. Pre-releases are tagged with a - (like v0.5.0-rc.1) and marked as such on GitHub.
Until 1.0, pin the version you build with (BRINE_VERSION=0.4.0 for the installers) and read the changelog before upgrading.