WoW Lab

WoW Lab

Toolkit

Simulate

Quick SimBest in BagsDrop Optimizer

Rotations

BrowseNew Rotation

Plan

Traits
P

Developer

DocsBibleEngineHooksMCP ServerMetricsUI Showcase

Misc

AboutBlog

© 2025 WoW Lab

  1. Home
  2. Bible
  3. Language Evaluation

Language Evaluation

Why Rust, what languages were evaluated, and the trade-offs involved

February 13, 2026
Edit

Languages evaluated for the simulation engine and why each was considered and ultimately rejected or chosen. The key requirements: raw performance for tight simulation loops, WASM compilation for browser-side validation, memory safety without garbage collection pauses, ergonomic type system for modeling game mechanics, ecosystem for async networking (distributed nodes).

Why not C++ (memory safety, build system complexity, WASM story), why not Go (GC pauses in tight loops, no WASM at the time, less expressive type system), why not TypeScript/JavaScript (performance ceiling, no native compilation for nodes), why not Zig (ecosystem maturity, async story), why not Java/C# (GC, WASM story).

Why Rust: zero-cost abstractions, trait system for spec polymorphism, fearless concurrency with Rayon, first-class WASM target via wasm-pack, Cranelift as embedded JIT compiler, strong ecosystem (tokio, serde, prost), single language for engine + nodes + sentinel + CLI + GUI, compile-time guarantees (no null pointers, no data races), performance parity with C/C++.

The trade-offs accepted: steep learning curve, longer compilation times, borrow checker friction in graph-like game state, less hiring pool than mainstream languages.

Next steps

Rotation Language
Architecture
Rotation Language

Navigation

IntroductionGlossaryReferences

Overview

MotivationArchitectureLanguage EvaluationRotation Language

Mechanics

Game Data

Simulation

Infrastructure

Portal