Philosophy
Kairo is built on a set of core principles that guide every language decision. Understanding these principles will help you understand why Kairo makes the choices it does.
Core Principles
1. Control Without Complexity
You should be able to do anything the hardware supports - without the language getting in your way. But “power” doesn’t mean “pain.” Kairo gives you control over memory, performance, and abstractions without drowning you in ceremony.
This means raw pointers are available when you need them. Inline assembly is supported. You can reach through every abstraction layer. But you don’t have to.
2. Ergonomics ≠ Abstraction
A language can be ergonomic without hiding what’s happening. Kairo’s syntax is clean and expressive, but it never obscures what the machine is doing. When you write Kairo, you should be able to predict - roughly - what code the compiler will emit.
3. Interop First
The systems programming world runs on C and C++. Billions of lines of existing code can’t be thrown away. Kairo treats interoperability as a first-class feature, not an afterthought.
Calling C functions requires no wrappers. Calling C++ requires minimal glue. The ABI is predictable and controllable.
4. Performance is Non-Negotiable
Zero-cost abstractions. No hidden allocations. No background GC. Predictable performance everywhere.
If a feature can’t be implemented with zero runtime overhead, it either doesn’t get added or it’s made explicit (e.g., you must opt into a garbage-collected heap, not inherit one).
5. Community Driven
Kairo is governed by the Kairo Software Foundation, a community-driven nonprofit. The language evolves through open proposals (KIPs - Kairo Improvement Proposals) and community consensus.
No single company controls Kairo. No single individual can unilaterally change the language.
The interop hypothesis
Most languages treat C++ interop as a compatibility feature. Kairo treats it as the core design constraint. Every decision — the token-level compilation model, the BCIR safety layer, the build system — follows from the question: what would make C++ and Kairo genuinely indistinguishable at the boundary?
Who Kairo Is For
- Systems programmers who want C++ power with modern ergonomics
- Game developers who need predictable frame times without GC pauses
- Embedded developers who need bare-metal control
- Students learning memory management and systems concepts
- Performance enthusiasts who can’t accept garbage collection pauses
- Open source contributors building the next generation of systems software
Design Trade-offs
Every language makes trade-offs. Here are Kairo’s:
| We chose… | Instead of… |
|---|---|
| More expressive generics | Simpler type system |
| Optional borrow checking | Mandatory borrow checking |
| First-class C++ interop | Clean slate FFI |
| Familiar syntax | Novel syntax |
| Incremental safety | All-or-nothing safety |