Sisu

Design decisions

Every design choice in Sisu is written down with its reasons, as a short decision record. This page lists them all.

35 records · at commit 3c93176

The values behind the choices

Sisu's goal is that people are productive in it because things work. Four values serve that goal, and a choice that trades one for another follows this order.

  1. Correctness

    The language makes wrong programs hard to write. Mistakes are caught early, at compile time where possible.

  2. Simplicity

    Few concepts, rules without special cases, every effect visible where it happens.

  3. Readability

    Code that reads top to bottom. Errors in plain words.

  4. Performance

    Native code with predictable memory. Optimizations never change what a program means.

Simplicity ranks above readability because agents now write and read much of the code. Special cases and two ways to do one thing cause their mistakes, and slow a human reviewing their work.

Principles

Some records settle features that are still planned, such as interfaces. The status page shows what works today.

Syntax and names

Values and change

Memory

Types

Errors and diagnostics

Runtime, I/O and concurrency

The compiler

What Sisu deliberately avoids

These come from the roadmap's Deliberately avoided list.

  • Lifetimes and a borrow checker. Reference counting keeps Sisu in Swift's ergonomic camp. Inferring lifetimes without annotations only moves the cost into the compiler.
  • Header files.
  • Unrestricted operator overloading.
  • Inheritance. A class is a reference type, not a hierarchy; composition, enums and interfaces cover polymorphism, as in Rust and Go.
  • Macros. They hide code from error messages, the formatter and the language server. Generated conformances, const initializers, attributes and committed generated files do their jobs.
  • Variadic parameters. An array costs two characters, sum([1, 2, 3]), and uses a type that already exists.
  • Pointers in Sisu code. A class is already a reference, and arrays are values.
  • Formatter options. One style ends style debates.
  • A separate linter. Lints are compiler warnings.
  • import *. A reader must always see where a name comes from.
  • A pipe operator |> and function captures. Method chains and continuation lines already do this, and two ways to write one call break "one obvious way".
  • Gleam's use. Gleam needs it because it has no early return; Sisu has return.
  • A return that names a function further up the call stack. The functions in between would end early with nothing in their signatures to show it; Result and ? pass a failure up one visible step at a time.
  • Separate float operators such as +.. The checker knows each operand's type, so + serves both.
  • Integers without a size limit, or division by zero that gives 0. Sisu's fixed-size integers panic on overflow and on a zero divisor.
  • Mutable memory shared between tasks. Tasks share no objects, so counts stay non-atomic and Sisu code cannot have a data race (ADR 0010, proposed).
  • A package registry, for a long time. A registry means hosting, security and name squatting.

Interfaces are planned. Planned work has no promised date and may change.

Compile-time evaluation and reflection are left open, to decide once Sisu has grown; the roadmap's Open decisions lists what has to be settled first.

Proposing a change

Open a GitHub issue that names the record and the change you propose. A change that is accepted becomes a new record that supersedes the old one. See how to contribute.