Introduction

What Sec Is

Sec is a compiled programming language designed for high-performance native programs. The intended backend is LLVM, and the language is designed so the compiler can generate efficient machine code without relying on a large runtime by default.

Sec is statically typed. Types are not only storage descriptions; they can also describe domain meaning. A value of type CustomerID and a value of type ProductID may both be represented as integers internally, but they are not the same type in the program model.

The language is designed around the idea that safe and correct code should be the easy path. Unsafe operations are allowed when needed, but they must be visible in the source code.

Design Goals

The following goals guide the language design:

• Compiled by default. Sec programs are compiled before execution.
• High performance. The language should allow predictable native performance.
• Strong static typing. Type errors should be caught at compile time whenever possible.
• Semantic typing. Types should express domain intent, not only memory layout.
• Safe by default. Safe code should not allow null references, dangling references, or unchecked pointer arithmetic.
• Explicit unsafe code. Code that escapes the safe model must be marked with unsafe.
• No hidden magic. Imports do not execute code, allocations should be visible, and initialization is explicit.
• One concept, one syntax. Syntax should not have several unrelated meanings.
• One symbol, one meaning. Symbols are reserved for narrow, consistent meaning families.
• Official formatting. Sec should have a standard formatter with a gofmt-like philosophy.
• Minimal runtime by default. Runtime services are opt-in rather than assumed.

Safety Model

Sec aims to make safe code the normal form of code. The language uses ownership and borrow checking concepts inspired by Rust, but with a preference for simpler rules where possible.

Safe Sec code should prevent common classes of memory errors. References cannot outlive the value they refer to. Mutable references require exclusive access. Null is not part of safe reference handling; absence is represented explicitly with Option[T].

Explicitness

Sec prefers visible operations over implicit behavior. This affects several parts of the language:

• Mutation requires a mutable binding.
• Fallible operations must be handled with try, match, or explicit error handling.
• Imports make symbols available, but they do not initialize systems or change program state.
• Unsafe operations require an unsafe context.
• Absence is represented with Option[T], not with implicit null values.

Runtime Model

Sec does not assume a garbage collector by default. It should be possible to write programs with predictable memory behavior and no hidden allocation. Heap allocation, shared ownership, task scheduling, channels, and other runtime services may exist, but the language design keeps them explicit.

This does not mean the standard library must be small. It means the core language should not hide major runtime behavior behind syntax that appears simple but performs complex work.

Example Program

The following example shows several core ideas in a small Sec-style program.

module cmd.demo

import (
    "fmt"
)

type Percent int range 0..100

type User struct {
    Name: string,
    Completion: Percent,
}

fn main() void {
    completion := try Percent(90)

    user := User{
        Name: "Anna",
        Completion: completion,
    }

    fmt.Println($"{user.Name}: {user.Completion}")
}

The type Percent is not just an integer. It is a constrained semantic type. The conversion try Percent(90) is explicit because a runtime value may fail validation.

Non-Goals

Some features are intentionally not part of the initial language direction:

• No classical inheritance model.
• No implicit package initialization.
• No hidden compiler directives inside comments.
• No C-style for(init; condition; increment) loop.
• No ++ or -- operators.
• No separate primitive any type.
• No nil value in safe code.