feat: rebuild website with full learning funnel

Website rebuilt from scratch based on analysis of 11 beloved language
websites (Elm, Zig, Gleam, Swift, Kotlin, Haskell, OCaml, Crystal, Roc,
Rust, Go).

New website structure:
- Homepage with hero, playground, three pillars, install guide
- Language Tour with interactive lessons (hello world, types, effects)
- Examples cookbook with categorized sidebar
- API documentation index
- Installation guide (Nix and source)
- Sleek/noble design (black/gold, serif typography)

Also includes:
- New stdlib/json.lux module for JSON serialization
- Enhanced stdlib/http.lux with middleware and routing
- New string functions (charAt, indexOf, lastIndexOf, repeat)
- LSP improvements (rename, signature help, formatting)
- Package manager transitive dependency resolution
- Updated documentation for effects and stdlib
- New showcase example (task_manager.lux)

Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
This commit is contained in:
2026-02-16 23:05:35 -05:00
parent 5a853702d1
commit 7e76acab18
44 changed files with 12468 additions and 3354 deletions

107
examples/showcase/README.md Normal file
View File

@@ -0,0 +1,107 @@
# Task Manager Showcase
This example demonstrates Lux's three killer features in a practical, real-world context.
## Running the Example
```bash
lux run examples/showcase/task_manager.lux
```
## Features Demonstrated
### 1. Algebraic Effects
Every function signature shows exactly what side effects it can perform:
```lux
fn createTask(title: String, priority: String): Task@latest
with {TaskStore, Random} = { ... }
```
- `TaskStore` - database operations
- `Random` - random number generation
- No hidden I/O or surprise calls
### 2. Behavioral Types
Compile-time guarantees about function behavior:
```lux
fn formatTask(task: Task@latest): String
is pure // No side effects
is deterministic // Same input = same output
is total // Always terminates
```
```lux
fn completeTask(id: String): Option<Task@latest>
is idempotent // Safe to retry
with {TaskStore}
```
### 3. Schema Evolution
Versioned types with automatic migration:
```lux
type Task @v2 {
id: String,
title: String,
done: Bool,
priority: String, // New in v2
from @v1 = { ...old, priority: "medium" }
}
```
### 4. Handler Swapping (Testing)
Test without mocks by swapping effect handlers:
```lux
// Production
run processOrders() with {
TaskStore = PostgresTaskStore,
Logger = CloudLogger
}
// Testing
run processOrders() with {
TaskStore = InMemoryTaskStore,
Logger = SilentLogger
}
```
## Why This Matters
| Traditional Languages | Lux |
|----------------------|-----|
| Side effects are implicit | Effects in type signatures |
| Runtime crashes | Compile-time verification |
| Complex mocking frameworks | Simple handler swapping |
| Manual migration code | Automatic schema evolution |
| Hope for retry safety | Verified idempotency |
## File Structure
```
showcase/
├── README.md # This file
└── task_manager.lux # Main example with all features
```
## Key Sections in the Code
1. **Versioned Data Types** - `Task @v1`, `@v2`, `@v3` with migrations
2. **Pure Functions** - `is pure`, `is total`, `is deterministic`, `is idempotent`
3. **Effects** - `effect TaskStore` and `effect Logger`
4. **Effect Handlers** - `InMemoryTaskStore`, `ConsoleLogger`
5. **Testing** - `runTestScenario()` with swapped handlers
6. **Migration Demo** - `demonstrateMigration()`
## Next Steps
- Read the [Behavioral Types Guide](../../docs/guide/12-behavioral-types.md)
- Read the [Schema Evolution Guide](../../docs/guide/13-schema-evolution.md)
- Explore [more examples](../)