Fifteen years of SnAPI
I have spent 15 years developing SnAPI. I set out to build a better cross-platform foundation: APIs that work across platforms, a build system that supports them, and platform provisioning that does not have to be reinvented for every project.
That work became SnAPI and SnBuild. As I built the game engine, the cost of development iteration became impossible to ignore. It is a problem familiar to engine developers and the people using their engines: change some code, compile, run, test the behavior, and do it again. A small change can mean a much larger interruption.
The delay changes how you work
Game development depends on experimentation. You change a value, adjust a system, try a different approach, and see what happens. When compilation interrupts that cycle, you spend more time waiting between decisions. The cost keeps returning throughout the project.
After years of work, that repetition brings frustration, wasted time, and real heartache. The performance needed by an engine is valuable. The time lost getting back into a running program is not.
I wanted C++ runtime performance with dramatically faster compilation. That is where Sn started.
Develop with the immediacy of scripting
The goal is a systems language that feels familiar to a C++ developer but uses a more modern syntax. Compile quickly enough to try an idea immediately. Keep a native JIT session running, update compatible code, and continue working with the application's state. Produce a native executable when it is time to distribute the program.
The intended runtime performance is comparable to or faster than C++. The intended development experience is much closer to scripting. Those two goals are the reason for the language; neither is an optional finishing touch.
Sn also brings native reflection, typed attributes, compile-time programming, and automatic C and C++ interoperability into that picture. Modern syntax takes ideas from languages such as C#, Rust, and Zig, while C++ remains the main point of familiarity.
A systems language, with games at its origin
Sn grew out of a game engine, but its scope is a full systems language. Engines, games, embedded software, operating-system components, and other real-time applications need native performance and control over resources.
At a minimum, I want gameplay in the SnAPI ecosystem to be written in Sn. Whether the SnAPI libraries themselves are eventually ported to Sn or used through C++ interoperability is still undecided. That decision does not need to be settled to explain why the language exists.
The larger cross-platform project
SnAPI provides the cross-platform libraries. SnBuild addresses builds and automatic platform provisioning. Sn adds the language and an intended canonical package manager. These are related parts of the work, but they are separate products, with their own responsibilities.
Sn is closed-source, with one official compiler. Public releases will be built from selected Git tags, and public GitHub Issues will provide a place to report bugs and give feedback.
There is more work to do
This is the direction for Sn 1.0. The language is currently under heavy development. The compiler does not yet meet every feature or performance goal, and progress is made regularly.
I want people to be able to download official versions, try them in their own work, and report what happens. The useful test of this project is whether it makes the next change easier to write, compile, and run.