Why Sn exists
C++ runtime performance. Scripting-speed development.
Start with iteration time
Sn exists because native development takes too long to turn a code change into something you can run. Its creator encountered that problem while developing SnAPI and its game engine: repeated compile-and-run delays make experimentation expensive.
Sn is a proper systems language, intended for engines, games, real-time systems, embedded firmware, native applications, and operating-system components. Gameplay is a particularly important use case, rather than the boundary of the language.
The intended 1.0 experience
- Runtime performance comparable to or faster than C++.
- Compilation fast enough to make development feel like scripting.
- An interactive native JIT, integrated with the editor workflow.
- Modern syntax that remains familiar to a C++ developer.
- Automatic access to C and C++ libraries.
- Native reflection, typed attributes, and compile-time programming.
These are the product goals for Sn 1.0. The current compiler is under heavy development and does not yet satisfy every goal.
A language for C++ developers
The strongest connection is C++: native values, explicit storage and access, deterministic lifetime, and control over allocation. C#, .NET, Rust, and Zig contributed ideas for a more modern syntax and language experience. Those influences do not imply a managed runtime, a garbage collector, or Rust's general borrow-checking model.
Keep the performance; shorten the feedback loop
The central comparison with C++ is development turnaround: faster compilation and a persistent JIT workflow, while targeting the runtime performance required by real-time software. Claims of runtime parity or improvement need workload-specific measurements. A faster compiler does not by itself prove a faster program.
One official compiler
Sn is closed-source. The project maintains one official compiler and distributes versioned toolchains. A public repository for downloads and issues does not publish the compiler's implementation.