Why Another Programming Language?

The world has hundreds of programming languages. Many are excellent. So why spend years building Lateralus? This is my attempt to answer that question honestly.

◉ The Frustration

I've used dozens of languages professionally: C, C++, Python, JavaScript, Rust, Go, Haskell, OCaml, Ruby, Perl, and more. Each solves some problems well and creates others. The pattern I kept hitting:

• Scripting languages (Python, Ruby): Great for prototyping, terrible for performance-critical code. No types until runtime explodes.
• Systems languages (C, C++, Rust): Great performance, painful for quick scripts. High ceremony for simple tasks.
• Functional languages (Haskell, OCaml): Beautiful abstractions, but ecosystem fragmentation and steep learning curves.
• Modern pragmatics (Go, TypeScript): Good middle ground, but specific design choices that grate over time.

The specific frustration: I was constantly switching languages based on task type. Shell script for glue, Python for quick analysis, Rust for the actual program, JavaScript for the web UI. Four languages, four mental models, four build systems.

◉ The Insight

Most code I write, regardless of language, follows the same pattern:

1. Get data from somewhere
2. Transform it through stages
3. Put data somewhere else

This is a pipeline. ETL systems know this. Unix pipes know this. Data engineering knows this. But most programming languages treat pipelines as a library feature, not a core primitive.

What if a language was designed from scratch around data flow?

◉ Data Flow First

Lateralus puts the pipeline operator at the center of everything:

// This isn't "sugar" — it's the primary way to express computation
let result = input
    |> parse()
    |> validate()
    |> transform()
    |> output()

// Compare to nested calls
let result = output(transform(validate(parse(input))))

The pipeline version reads in the order operations happen. The nested version requires reading inside-out. This isn't just aesthetics — it changes how you think about programs.

◉ Systems + Scripts

Lateralus compiles to multiple targets from the same source:

• Python: For scripting, prototyping, interop with data science tools
• C99: For performance, embedding, bare metal
• Bytecode: For the VM, portable distribution
• LLVM IR: (planned) For native binaries with optimization

Same language for your automation script and your OS kernel. No context switching, no rewriting when performance matters.

// Quick script for data analysis
cat("data.json") |> json.parse() |> filter(_.active) |> map(_.name) |> println()

// Same language for kernel driver
@freestanding
fn handle_interrupt(irq: u8) {
    let handler = interrupt_table[irq]
    handler() |> log_if_error()
}

◉ Thoughtful Defaults

Every language makes choices. These are ours:

Choice	Default	Opt-in Alternative
Mutability	Immutable	let mut
Nullability	No null	Option[T]
Pattern matching	Exhaustive	_ => ... catch-all
Error handling	Result[T,E]	panic() for unrecoverable
Concurrency	Structured (scoped)	spawn for raw tasks
Visibility	Private	pub

These defaults create a "pit of success" — the easy way to write code is also the safe way.

◉ What Lateralus Is Not

Honest about limitations:

• Not production-ready: Still in active development. Breaking changes happen.
• Not a Rust replacement: We don't have borrow checking. Memory safety comes from GC or manual management, not lifetime analysis.
• Not a Python replacement: The ecosystem is tiny. You can't import numpy.
• Not for everyone: If you're happy with your current tools, keep using them.

◉ Who Is This For?

Lateralus might fit if you:

• Write a lot of data transformation code
• Bounce between scripting and systems programming
• Value pipeline-oriented thinking
• Want to experiment with language design
• Are building embedded systems with custom requirements
• Enjoy trying new tools

◉ The Name

"Lateralus" — from the Tool album. The Fibonacci spiral, thinking laterally, patterns that expand outward. Data flowing through transformations. It felt right.

Try it in the playground or check the source on GitHub.