Who Cyrus is for#
Systems developers moving off C
Cyrus provides the control of C with generics, a real module system, algebraic types, and `defer`-based resource cleanup. If C's lack of these constructs has led to hand-rolled workarounds in your codebase, Cyrus gives a path forward without adopting a garbage-collected language or Rust's ownership model. Mutability, pointer indirection, and type casts are all explicit at the call site.
Skip if:
You need Windows or macOS support at this time. The current compiler only targets Linux (x86_64).
Embedded and OS-level engineers
Cyrus supports inline assembly, `extern` for C ABI compatibility, `naked` functions for interrupt handlers, pointer arithmetic, and custom allocator strategies. Zero hidden runtime overhead and fully manual memory control make it usable in contexts where a garbage collector or managed runtime is not acceptable.
Skip if:
Your target platform is not Linux (x86_64). Multi-platform support is in the roadmap but not yet available in the current release.
Developers building performance-critical CLI tools
For teams writing high-performance CLI tools, compilers, parsers, or infrastructure utilities in Rust but experiencing friction with the borrow checker for data-structure-heavy code, Cyrus offers a similar performance ceiling with fewer lifetime constraints. The LLVM backend produces native binaries with no external runtime dependency.
Skip if:
Your team is productive with Rust and not experiencing borrow-checker friction. Cyrus trades safety guarantees for a simpler ownership model, not a safer one.
Compiler engineers and language researchers
Cyrus is self-hosting: the compiler is being rewritten in Cyrus itself. The project documents its design rationale and deliberate omissions in the README and on the project website. Developers interested in compiler construction have a live LLVM frontend written in Rust to read, contribute to, and study alongside the official documentation.
Skip if:
You need a stable, production-ready language with ABI guarantees. Cyrus is pre-self-hosting and breaking changes are expected during the current development phase.
The problem it solves#
Systems programming requires precise control over memory, allocation, and execution flow. C provides that control but lacks a real module system, generics, and type safety for common patterns, so teams accumulate wrapper libraries and header workarounds to compensate. Rust solves those ergonomics problems but introduces a borrow checker and lifetime annotations that many teams find restrictive, particularly for data-structure-heavy work or embedded firmware where ownership patterns do not fit neatly.
The gap is that the middle ground is mostly unoccupied. Developers who want C-level control without C's ergonomics deficits, but who do not want Rust's ownership rules for straightforward systems work, have limited choices. Existing options either bring a garbage collector (Go), a heavy runtime (Java, .NET), or require a paradigm shift (Rust). Teams end up spending time fighting tooling instead of writing the low-level code that actually matters.
How it solves it#
LLVM-Based Native Compilation
Cyrus compiles ahead-of-time through LLVM to optimized native machine code, producing deterministic performance characteristics. Full interoperability with C code is available via the C ABI, so you can call C functions from Cyrus and expose Cyrus functions to C projects without writing glue code. The compiler accepts `extern(c)` on both sides of the boundary.
Manual Memory Management with Defer
Memory is managed explicitly through manual allocation patterns and custom allocators. The `defer` keyword schedules cleanup at scope exit in LIFO order, keeping resource management flat and readable. There is no garbage collector and no hidden ownership system. Custom allocators (stack, bump, libc) are first-class via the `Allocator` interface, so you can swap strategies without changing calling code.
Strict Explicit Type System
Strong static typing with no implicit conversions between types. Safe widening (for example, `int32` to `int64`) happens automatically, but any operation with risk of data loss or signedness mismatch requires an explicit `@cast`. Generics are monomorphized at compile time for direct static dispatch with zero runtime abstraction cost.
No Hidden Semantics
Mutability is declared with `const` or `var` at the definition site. Pointer indirection uses `->` explicitly, so every memory boundary crossing is visible in the source. There are no hidden allocations: every heap allocation requires calling an allocator explicitly. No monkey-patching, no implicit type coercions, no silent behavior behind compiler-driven assumptions.
Bidirectional C ABI Interoperation
Call C functions from Cyrus or expose Cyrus functions to C code using `extern(c)`, with no additional tooling or FFI wrappers required. This makes incremental migration from existing C projects feasible and allows reuse of the C ecosystem without rewriting libraries. Inline assembly, `naked` functions, and union type punning are also supported for low-level system interfaces.
Algebraic Types and Pattern Matching
Enums support unit variants, tuple variants, struct variants, and valued variants. Pattern matching uses a `switch` statement with case destructuring. Generics work across functions, structs, unions, enums, and interfaces, all type-checked at compile time without instantiation. Interfaces support both static (monomorphized) and explicit dynamic dispatch via the `dynamic` keyword.
Strengths and trade-offs#
Strengths
- No GC, No Borrow CheckerCyrus deliberately omits both garbage collection and Rust's borrow checker. You get deterministic memory management and full control over allocation strategy without the cognitive overhead of lifetime annotations. This is the primary differentiator for teams who find Rust's ownership model too constraining for data-structure-heavy or embedded work.
- Explicit Semantics ThroughoutEvery operation with a side effect is visible in the source: mutability via `const`/`var`, pointer indirection via `->`, explicit casts via `@cast`, explicit allocations via an allocator call. No silent coercions, no hidden vtables on struct access, no implicit type transformations. Predictability is a design goal, not a side effect.
- Modern Language Features on a Proven Compiler BackendGenerics, algebraic types, interfaces with static and dynamic dispatch, modules, and `defer` for deterministic cleanup, all built on the LLVM infrastructure. The backend produces native binaries using the same optimization pipeline as Clang and Rust, so performance characteristics are comparable to C at the machine level.
- MIT License, No Usage RestrictionsThe MIT license places no restrictions on commercial use, modification, or redistribution. You can use Cyrus to build commercial products, fork the compiler, or incorporate it into proprietary toolchains. The project is under active development with the most recent push in August 2026.
Trade-offs
- -Linux-Only Compiler at Current ReleaseThe current Cyrus compiler supports Linux (x86_64) only. Windows and macOS support is planned after the self-hosting milestone is complete. Teams working on macOS or targeting Windows cannot use Cyrus for production work until multi-platform support ships.
- -No Stable ABI Between VersionsCyrus does not guarantee a stable ABI between releases. Calling conventions, type layouts, and optimization strategies may change to improve performance. For cross-language boundaries, the project recommends using the C ABI (`extern(c)`) and treating the Cyrus-to-Cyrus ABI as an internal implementation detail.
- -Pre-Self-Hosting, Breaking Changes ExpectedCyrus is actively working toward its self-hosting milestone, rewriting the compiler in Cyrus itself. Several planned features are not yet implemented: slices, full generic instantiation safety (currently behaves like C++ templates, not Rust-style), attributes, and a test framework. Teams should expect breaking changes during this phase.
- -No Compiler-Enforced Memory SafetyData races, dangling pointers, and use-after-free errors are possible and are not prevented by the compiler. The runtime enforces bounds checking, null pointer detection, and integer overflow, and sanitizers (ASan, TSan) are supported for debugging. The design trades safety guarantees for direct machine access and simpler code without ownership rules.
Cyrus vs alternatives#
Cyrus vs Google Firebase
Cyrus is a systems programming language; Google Firebase is a managed backend-as-a-service platform providing realtime databases, authentication, hosting, and cloud functions. They are not direct competitors, but they represent opposite design philosophies: Firebase abstracts away infrastructure and runtime; Cyrus exposes every allocation, dispatch, and execution decision to the developer.
Firebase is the right choice when you want a managed backend without configuring servers. Its hosted database, auth layer, and cloud functions handle scaling automatically, with Google managing the runtime environment. The cost scales with usage, and you are bound to Firebase's pricing model and managed infrastructure.
Cyrus is for teams building the infrastructure layer itself. Writing a backend service, a database engine, a compiler, or an OS-level tool requires the kind of control that a managed BaaS cannot provide: manual memory management, custom allocators, inline assembly, bare-metal compilation to a self-contained native binary, and zero runtime overhead.
| Criterion | Cyrus | Google Firebase |
|---|---|---|
| Type | Systems programming language | Managed backend-as-a-service |
| License | MIT | Proprietary |
| Self-hosted | Yes (Linux x86_64) | No |
| Runtime overhead | None | Node.js managed runtime |
| Memory model | Manual, explicit allocators | Managed by runtime |
| Cost | Free (nightly binary or build from source) | Pay-per-use (free tier available) |
Firebase is still the better choice when you want production-ready backend services without managing infrastructure, need real-time client sync across devices out of the box, or are building a mobile app that requires authentication and push notifications without writing a server. Those are use cases Cyrus does not address.
Cyrus is the better choice when you are building the kind of system that would sit below Firebase: bare-metal services, native binaries, infrastructure tooling, or compilers where runtime overhead is a hard constraint and you need full visibility into memory and execution.
What it's built on#
- Languages
- PythonRust
FAQ#
Is Cyrus safe like Rust?
No, not by design. Cyrus explicitly omits Rust's borrow checker and ownership system. Data races, dangling pointers, and use-after-free errors are possible. The runtime enforces bounds checking, null pointer detection, and integer overflow, and ASan/TSan sanitizers are supported for debugging. The trade is deliberate: Cyrus prioritizes direct machine access and code without lifetime annotations over compiler-enforced memory safety.
What platforms does Cyrus support?
The current Cyrus compiler supports Linux (x86_64) only. Windows and macOS support is planned after the self-hosting milestone, which involves rewriting the compiler in Cyrus itself. A nightly binary is available for download, and building from source is documented on the project website at cyrus-lang.ir.
How does Cyrus manage memory without a garbage collector?
Memory is managed explicitly. You allocate memory using an allocator (libc, arena, or custom) and free it yourself. The defer keyword schedules cleanup at scope exit in LIFO order, keeping resource management readable and flat. Custom allocators implement the Allocator interface, so you can swap between strategies (arena vs. libc) without changing the calling code.
Is Cyrus ABI-stable?
No. Cyrus does not guarantee a stable ABI between versions. Calling conventions, type layouts, and optimization strategies may change between releases to improve performance and code quality. The project recommends using the C ABI (extern(c)) for all cross-language boundaries and treating the Cyrus-to-Cyrus ABI as an internal detail that may evolve.
How does Cyrus compare to C and Rust?
Cyrus positions itself between C and Rust. It has the explicit control and direct memory access of C, with a modern type system (generics, algebraic types, modules, no silent coercions) that C lacks. Unlike Rust, it has no borrow checker or lifetime annotations, so there is no ownership-based safety. It is closer in ergonomics to a modernized C than to Rust's safety-first model, targeting developers who want control without the complexity of lifetimes.
Similar open-source tools#
Kuzzle
Self-hosted backend with real-time API and search built in
limen
Composable authentication for modern Go backends
Neovim
Hyperextensible Vim-based editor with Lua plugin support
Modelence
Full-stack framework for building production-ready web apps
CodeEdit
Native Swift code editor for macOS with no Electron overhead
dograh
Open source voice agent builder with telephony and BYOK AI support