Language Comparisons

How does our type system compare to other systems languages? Here's where we stand.

Versus C

C is the gold standard for transparency and simplicity.

What we keep from C:

• Transparent memory layout — you know what your data looks like
• Explicit control — no hidden magic
• Direct hardware mapping — types correspond to machine types
• Predictable performance — code maps clearly to instructions

What we add:

• Safety checks — catch bugs at compile time
• Generics — reusable code without macros or void pointers
• Enums with data — algebraic types for modeling alternatives
• Type inference — less boilerplate, same clarity
• Ownership tracking — memory safety without manual tracking

What we keep from C's philosophy:

• Mutable by default — variables can be changed without ceremony
• Simple syntax — no extra keywords cluttering your code

Result: C with a modern type system. You get C's transparency and control, plus compile-time safety and better abstractions.

Versus Rust

Rust proves that memory safety without garbage collection is possible.

What we share:

• Ownership tracking — memory safety at compile time
• Algebraic data types — enums, pattern matching, exhaustive checking
• Zero-cost abstractions — high-level code with low-level performance

What we simplify:

• No let keyword — just $x = value
• Mutable by default — no mut keyword needed
• Just & for references — no &mut, compiler detects mutation automatically
• Smart parameter passing — compiler chooses by-value vs by-reference automatically
• Fewer lifetime annotations — trust the programmer more
• More escape hatches — raw pointers available without ceremony
• Simpler trait system — less complexity, same power
• Single string type with ARC — no String vs &str complexity

Trade-offs we make:

• String ARC has slight overhead vs pure move semantics
• Less compile-time enforcement of immutability (intentional simplicity)

Result: Memory safety with less friction. We take Rust's proven safety model and make it more practical for everyday use.

Versus Go

Go prioritizes simplicity and fast compilation.

What we do differently:

• More expressive types — generics, enums with data, pattern matching
• Zero-cost abstractions — no runtime overhead
• Memory safety without GC — ownership instead of garbage collection
• No hidden allocations — explicit is better than implicit

Result: Systems programming with modern features. Go's simplicity is admirable, but we don't sacrifice expressiveness or performance for it.

Versus C++

C++ evolved from C but accumulated complexity.

What we avoid:

• Implicit conversions — no surprise behavior
• Multiple inheritance — single inheritance or composition
• Template metaprogramming complexity — simpler generics
• Undefined behavior everywhere — well-defined semantics

What we keep:

• Zero-cost abstractions — performance without compromises
• RAII patterns — resource management through ownership
• Value semantics — control over when things copy

Result: What C++ could have been if it started over. Modern features without decades of accumulated complexity.

Versus PHP

PHP has a straightforward, practical approach to OOP that "just works."

What we borrow from PHP:

• OOP as a first-class citizen — classes, inheritance, visibility modifiers
• Single inheritance model — simple and predictable
• Public/private/protected visibility — familiar access control
• Natural OOP syntax — readable and ergonomic

What we add:

• Compile-time type safety — catch errors before runtime
• Zero-cost abstractions — OOP without performance penalty
• Ownership tracking — memory safety built-in
• Value types alongside objects — not everything needs to be a class

What we avoid:

• Dynamic typing — we're statically typed for safety
• Runtime type errors — all type errors caught at compile time
• Garbage collection — ownership-based memory management instead

Result: PHP's ergonomic OOP model with systems programming power. Familiar syntax, compile-time safety, zero overhead.

Versus Swift

Swift pioneered practical ARC (automatic reference counting) for a systems-oriented language.

What we share:

• ARC for memory management — deterministic, predictable deallocation
• No garbage collection — no unpredictable pauses
• Reference counting overhead is explicit — documented behavior
• Modern type system — optionals, pattern matching, generics

What we do differently:

• ARC only for strings — most types use move semantics (lighter weight)
• Mutable by default — simpler variable declarations
• More low-level control — raw pointers always available
• No Objective-C baggage — clean systems language design

Why selective ARC?

Swift uses ARC for all reference types. We use it only for strings:

• Strings benefit most — frequently copied, often large
• Other types use zero-cost move semantics
• Simpler mental model — one special case (strings), everything else is predictable

Result: Swift-like ergonomics where it matters (strings), zero-cost semantics everywhere else. Best of both worlds.

Our Position

We're not trying to replace any of these languages. We're taking the best ideas from each:

• C's transparency and simplicity — mutable by default, predictable performance
• Rust's memory safety model — ownership tracking without garbage collection
• PHP's pragmatic OOP — classes, single inheritance, clear visibility
• Swift's selective ARC — ergonomic strings without full ARC overhead
• Modern type system features — algebraic types, generics, inference
• Trust in the programmer — powerful tools, minimal ceremony

The goal: A practical systems language that's simple, transparent, and safe.

No runtime overhead (except where documented). No hidden behavior. No fighting the compiler.

Just powerful tools that help you write fast, correct code.