Low

Roadmap

  1. Standard library, written in Low:
    1. Vector values in registers across blocks and calls, and an AVX-512 version.
    2. QUIC (RFC 9000, 9001 and 9002) over UDP with the TLS 1.3 handshake, loss recovery and congestion control; HTTP/3 (RFC 9114) with QPACK (RFC 9204).
    3. WebRTC data channels: ICE with STUN, DTLS, SCTP over DTLS and the data channel establishment protocol; media over SRTP.
    4. Cryptography:
      1. Hashing: BLAKE3, with keyed hashing, key derivation and extendable output.
      2. Random generation: a ChaCha20 CSPRNG seeded from getrandom for crypto.random, and AES-256-CTR-DRBG (NIST SP 800-90A).
      3. Post-quantum signatures: ML-DSA-44, ML-DSA-65 and ML-DSA-87 (FIPS 204), SLH-DSA (FIPS 205), and Falcon (FN-DSA).
      4. HPKE (RFC 9180) with the DHKEM(X25519) and X25519MLKEM768 KEMs, HKDF-SHA-256 and the AES-256-GCM and ChaCha20-Poly1305 AEADs.
      5. Shamir's secret sharing over GF(2^8).
      6. VOPRF (RFC 9497) over ristretto255 and P-256.
      7. Zero-knowledge proofs: Groth16 over BN254 and BLS12-381, Halo2 with KZG and IPA commitments, and STARKs over FRI.
      8. Homomorphic encryption: BFV, CKKS and TFHE.
  2. GPU UI library with GPUI's renderer and platform layer and a signal-based state model, Linux first:
    1. A Wayland window through libwayland-client, with bindings generated from protocol XML; a Vulkan swapchain through VK_KHR_wayland_surface; a clear colour.
    2. A scene of GPU primitives (shadows, quads with rounded corners and borders, paths, underlines, monochrome, subpixel and polychrome sprites) drawn by GLSL shaders compiled to embedded SPIR-V. Primitives are sorted by draw order, batched by kind and atlas texture, and clipped by content masks.
    3. Text: font discovery with an embedded fallback font, OpenType parsing, rasterizing into a glyph atlas, shaping, line layout, Unicode grapheme and line-break segmentation from embedded Unicode tables.
    4. A retained element tree. Components run once at mount and build elements; only the closures that read a signal run again.
    5. Signal[T], Memo[T: Eq] and effects. Reads are tracked through a current-observer scope on the UI thread. A memo whose new value is equal to the old one does not propagate.
    6. Reactive structure through explicit containers: a dynamic branch, and a keyed dynamic list.
    7. Incremental layout: a flexbox subset with dirty flags that propagate to ancestors and cached measurements, so a change re-lays out only the affected subtrees.
    8. Incremental paint: per-element scene fragments are reused, and only dirty elements re-emit primitives.
    9. Styles with partial overrides for hover and active states, driven by signals.
    10. Input: libxkbcommon keyboard, key repeat, hitboxes, mouse dispatch, focus and tab stops, actions and keymaps. Focus and hover state are signals.
    11. Foreground and background executors on the scheduler; a background task's result is written into a signal on the UI thread.
    12. Text input element whose state is held in signals, clipboard, IME (text-input-v3), fractional scale, cursor-shape, xdg-decoration and client-side decorations.
    13. Portals and AT-SPI over D-Bus, PNG images, SVG paths.
  3. Own assembler and linker in place of as and ld, with static and dynamic ELF output.
  4. A wasm32 target and a browser playground that runs snippets:
    1. Targets named by OS and architecture, with wasm32 beside amd64.
    2. A WebAssembly back end lowered from the IR: structured control flow rebuilt from the IR's blocks, locals in place of registers, a linear-memory heap with the size-class bins, and a module written directly without an external assembler or linker.
    3. A browser host: print and the clock as JavaScript imports; modules that need the OS (files, sockets, processes, the UI library) are rejected at compile time for this target.
    4. The compiler built for js/wasm, so the page compiles and runs a snippet without a server.
    5. A Run button on every documentation snippet, and an editable playground page on the site.
  5. Standard library on windows/amd64:
    1. OS-specific std code selected by target, so each OS-facing module (std/os, std/os/signal, std/file, std/net, std/process) carries one implementation per OS behind one API.
    2. __syscall rejected at compile time on the Windows target, so a module without a Windows implementation fails the build.
    3. std/process over kernel32: CreateProcessW with Windows command-line quoting, CreatePipe with overlapped reads and writes for piped streams, WaitForSingleObject and GetExitCodeProcess, TerminateProcess, job objects for process groups, and find over PATH and PATHEXT.
  6. Further targets: linux/arm64, darwin; macOS (Metal) and Windows backends for the UI library.