Composite Code. Cultivated Performance.
Aster (.ax) is a unified language environment that solves the Two-Language Problem by allowing high-level and low-level code to coexist in the same syntax, within the same project, under different execution contexts.
Instead of rewriting a prototype in another language, Aster lets you change the environment, not the code.
An Aster is a composite flower β what appears to be a single bloom is actually many structures working together.
- The Core is inward, dense, and deterministic β where structure and performance live.
- The Crown is outward, expressive, and adaptive β where interaction and iteration happen.
In Aster, your code does not change.
Only its environment does.
Execution behavior is defined by configuration, not syntax.
| Component | Name | Description |
|---|---|---|
| Language | Aster |
Unified syntax across execution environments |
| Compiler | Proteus | Shape-shifting compiler targeting native or hosted runtimes |
| Config | Calyx | Directory-level configuration (calyx.ax) |
| Native Mode | Core | Deterministic, high-performance native execution |
| Hosted Mode | Crown | Adaptive, dynamic, GC-managed execution |
| Interop | Graft | Auto-generated boundary bridges between Core and Crown |
| Std Library | Lupine | Dual-mode standard library |
| Package Manager | Rhizome (rhi) |
Dependency distribution and resolution |
Aster is biome-based.
Each directory defines its execution environment via a calyx.ax file.
/my-project
βββ /core <-- Core biome (native)
β βββ physics.ax
β βββ calyx.ax
β
βββ /ui <-- Crown biome (hosted)
β βββ main.ax
β βββ calyx.ax
β
βββ `Aster`.toml <-- Workspace root
calyx.ax defines how all .ax files in the directory are compiled and executed.
import { Config } from "`Aster`/calyx"
export const Environment = Config.define({
mode: "core", // Native execution
safety: "strict", // No unsafe memory
optimization: "speed"
})import { Config } from "`Aster`/calyx"
export const Environment = Config.define({
mode: "crown", // Hosted execution
platform: "web",
hot_reload: true
})The syntax is consistent across environments β only semantics differ.
struct Vector3 {
x: f64
y: f64
z: f64
}
pub func add(v1: Vector3, v2: Vector3) -> Vector3 {
return Vector3 {
x: v1.x + v2.x,
y: v1.y + v2.y,
z: v1.z + v2.z
}
}This compiles to optimized native code via Zig.
import { Physics } from "../core/physics.ax"
func on_click() {
let player_pos = { x: 10.0, y: 5.5, z: 0.0 }
let move_vec = { x: 1.0, y: 0.0, z: 0.0 }
// GRAFT:
// Dynamic Crown objects are serialized and
// packed automatically for Core execution.
let new_pos = Physics.add(player_pos, move_vec)
print("New Position: " + new_pos.x)
}This runs in a hosted JavaScript runtime (QuickJS, browser, or embed).
Cross-boundary calls require no manual FFI.
When Crown code calls Core code:
- Proteus detects the boundary crossing
- Generates a C-compatible serialization layer
- Transforms layouts safely and deterministically
- Executes native logic
- Returns structured data back to Crown
You write one function call.
Rhizome distributes and resolves Aster modules across biomes.
# Add a dependency
`Aster` rhi add https://github.com/`Aster`-lang/lupine-math
# Build the workspace
`Aster` buildRhizome is environment-aware: Core code never pulls Crown-only dependencies.
Aster exposes execution and failure states explicitly:
- Dormancy β compiled but inactive
- Bloom β activated and live
- Wilt β recoverable degradation
- Blight β unrecoverable failure
- Thorns β enforced safety constraints
These are user-facing concepts, not internal jargon.
β οΈ Asteris currently pre-alpha and under active design.
curl -s https://`Aster`-lang.org/install.sh | bash
`Aster` init my-garden
cd my-garden
`Aster` run ui/main.axAster is a solo-led project seeking thoughtful collaborators (βGardenersβ) in:
- Proteus β compiler & codegen
- Lupine β standard library expansion
- Rhizome β dependency resolution
MIT Β© 2026 Aster Language