# EX Script — Philosophy

> *LESS CODE. LESS CONFIGURATION. LESS CONFUSION. FEWER BUGS. BETTER ERRORS. BETTER TOOLING. BETTER PERFORMANCE.*

EX Script is a compiled-to-JavaScript programming language designed as a modern alternative
to TypeScript. It is not "TypeScript with extra features". It rethinks the developer
experience from the ground up, while staying familiar enough that a JavaScript or TypeScript
developer can read and write it within an hour.

## The design principles

### 1. Easy to learn, easy to use
The language has a small surface area. Every feature must justify its existence
(Language Design Rule). If a feature adds more confusion than it removes, it is cut.
There is exactly one way to do each common thing.

### 2. Minimal boilerplate
Types are inferred. `return` is optional (the last expression of a function body is its
value). Configuration is zero by default. A hello-world project is:

```
// hello.xan
import std.io

export fun main() {
    io.println("Hello, world!")
}
```

`ex init && ex run` and you are done. No tsconfig, no bundler config, no build script.

### 3. Excellent error messages
The compiler explains *what* went wrong, *why* it happened, and *how* to fix it — with
code frames and concrete suggested fixes. Compiler jargon is banned from user-facing
output. This is the defining feature of the language.

### 4. Safe by default
- No `null` exists in the language at all. Values that may be missing are marked `?`
  (`String?`) and the compiler refuses to use them as if they were guaranteed.
- `let` values are immutable by default; mutability is an explicit choice (`let mut`).
- Every value has exactly one type; there is no implicit `any`.
- Expected failures are explicit: fallible functions return `Result` values
  (written `T!`), and the compiler refuses to let a possible failure be silently ignored.
- Everything is private by default; `export` is explicit.

### 5. Fast compilation and execution
The pipeline is lexer → parser → type checker → code generation. No elaborate
transform pipelines, no plugin system to load, no config parsing. Incremental builds
rebuild only changed modules. Generated JavaScript is plain, readable, and tree-shakeable.

### 6. Modern syntax
Pattern matching, destructuring, discriminated unions, expression-oriented blocks,
string interpolation, ranges, and structured concurrency are built in — not bolted on.

### 7. First-class async and concurrency
`async` is a function modifier, not an accident of a promise library. `all`, `race`,
and `timeout` combinators are built in. Concurrent code is easy to read and hard to
misuse.

### 8. Strong typing without fighting
The type system infers almost everything, uses structural typing so `contract`s are
satisfied automatically, narrows types inside `match` and `if let`, and treats unions
as first-class values. You write types only where they add information.

### 9. Tooling is part of the language
One binary, one command per task: `ex init`, `ex run`, `ex build`, `ex test`, `ex fmt`,
`ex lint`, `ex migrate`, `ex add`, `ex doc`. No ecosystem of unrelated tools.

### 10. Runtime safety is first-class
Static types are a compile-time guarantee, not a runtime one. For untrusted data
(JSON, API responses, env vars, user input, database rows, JS interop), `schema`
generates runtime validators automatically from the same declaration that defines
the static type. Validation and typing never drift apart.

## What EX Script is not

- Not a superset of JavaScript. EX Script compiles *to* JavaScript but is its own
  language with its own semantics.
- Not a toy. It is designed for production: real packages, real tooling, real
  standard library, real error messages.
- Not a syntax experiment. Syntax serves semantics; nothing exists just to look novel.

## Language Design Rule

> Every feature must justify its existence.

Before any feature is added, it must answer: *does this make code shorter, safer,
clearer, or faster?* If the answer is "other languages have it", the feature is rejected.