One language core, many profiles. From kernels to web apps, without splitting into unrelated languages.
C4 is a language ecosystem built by ADA Dynamics. It is designed around a common language core with different profiles for different use cases. The same syntax, type system, compiler infrastructure, libraries and tooling scale from kernel and embedded development to safe application development and scripting.
The main problem C4 sets out to solve is coherence.
- Why C4
- Profiles
- A note on the name
- Profiles, backends and platforms
- What is shared across profiles
- How the profile system works
- Targets
- The language at a glance
- Ecosystem
- Building a project
- Project layout
- In practice
- Roadmap
- Status
- Contributing
- License
Most software stacks split the work across languages. Kernels and drivers are written in one, servers in another, websites in a third, mobile apps in a fourth, and scripts in a fifth. Every boundary between them costs time: different toolchains, different libraries, different mental models, and code that cannot be shared.
C4 takes a different approach. Instead of one language trying to do everything, or many unrelated languages, C4 is one ecosystem with one core and several profiles. A profile decides what a program may do and what the compiler guarantees. Everything else stays the same.
That means you learn one syntax, use one type system, read one standard library, and move between low-level and high-level work without changing tools.
A profile answers one question:
What is this program allowed to do, and what guarantees does the compiler enforce?
| Profile | Purpose | Guarantees |
|---|---|---|
| C4 (the unsafe profile) | Operating system kernels, embedded software, drivers, runtimes | Full control over memory and hardware |
| C4S (the safe profile) | Applications, services and scripting | Stronger compile-time safety restrictions |
The C4 profile gives you the full power of a low-level systems language, including direct control over memory and hardware.
The C4S profile imposes stronger compile-time restrictions so that whole classes of mistakes are rejected before the program runs. It can target native systems, a virtual machine, or the Web.
Profiles are not separate languages. They share the same syntax, compiler infrastructure, type system, libraries, package ecosystem and tooling. The profile only determines which capabilities and guarantees are available. This lets one ecosystem scale from kernel work to everyday application development without fragmenting into unrelated languages.
The name C4 changes meaning with context:
- C4 can refer to the entire language ecosystem.
- C4 can also refer to the unsafe profile of that ecosystem.
- The safe profile is always called C4S.
When it matters, this documentation says "the C4 profile" for the unsafe profile and "C4" alone for the ecosystem.
Three different questions are easy to confuse. C4 keeps them separate on purpose.
| Concept | The question it answers | Examples |
|---|---|---|
| Profile | What is this program allowed to do, and what guarantees does the compiler enforce? | C4, C4S |
| Backend | What does this program compile to? | Native code, Web, Android |
| Platform | Where does it run? | Linux, Windows, browsers, Android devices |
A profile is not a backend. The same C4S program keeps the same safety guarantees whichever backend you choose. New backends can be added without changing profiles, and new profiles can be added without changing backends.
- One syntax. Code looks the same whichever profile it is written for.
- One type system. Types mean the same thing everywhere.
- One compiler infrastructure. A new profile does not need a new compiler.
- Shared libraries. The same standard library and framework code is reused across profiles.
- A shared package ecosystem. Libraries are shared across the ecosystem, not rebuilt per profile.
- Common tooling. Build, project management and editor support work the same way.
The language core is shared. A profile is a small piece of configuration on top of it:
- A profile kind names the profile.
- A default capability mask lists what that profile is allowed to do.
Adding a new profile means adding a profile kind and a default capability mask. It should never require touching the target, optimization or backend structures. This keeps profiles, targets and optimization independent, so the ecosystem can grow in one direction without breaking the others.
C4 programs compile to the places they need to run.
| Target | What it is for |
|---|---|
| Native (Linux and Windows) | Systems software, servers, command line tools, kernels |
| Web | Browser applications |
| Android | Android applications |
The set of targets is expected to grow. Because profiles are independent of backends, adding a target does not change what any profile guarantees.
C4 is statically typed. It has structs with methods, modules, constants, attributes and explicit types. The following is an illustration of the style:
struct Greeter {
str name
}
impl Greeter {
fn hello()->str{
return "Hello, " + self->name
}
}
Idiomatic C4 uses structs with impl blocks and methods, not loose functions over raw data.
Source files live under src/, and everything is organised into modules:
use framework::shared::widget::Widget
use app::components::ui::label
| Part | What it is |
|---|---|
| C4 compiler | The language and its multi-backend compiler |
| c4std | The standard library: networking (sockets, TCP), files, memory and processes |
| c4ui | A declarative UI framework for the Web and Android, built on a state, action, reducer, effect and view loop |
| c4 HTTP backend | A native HTTP server framework with an application, router, requests and responses |
| c4pm | The project manager, used to create and build C4 projects |
| c4vm | A virtual machine written in C4, with instruction decoding, an MMU, an emulator and ELF loading |
c4ui is a UI framework written in C4 that follows an Elm-style architecture:
- State is a single value describing the whole app.
- Actions describe what happened.
- Reducers compute the next state from an action.
- Effects reach outside the app: network requests, links, phone calls.
- View is a pure function from state to widgets.
One c4ui codebase builds for the Web and for Android.
Projects are created and built with c4pm. Building is a single command:
c4pm --buildAll C4 source files live inside a src/ directory:
my-project/
src/
main.c4
app/
framework/
C4 is used to build real software:
- Wathii, a marketplace app for Nakuru, runs on the Web and Android from one shared C4S codebase, built with c4ui.
- The ADA Dynamics website, including its admin page, is written in C4.
- The C4 profile drives our systems work, including an operating system port currently in progress.
- c4vm is a virtual machine written in C4.
These are design goals and work in progress, not finished features.
- Traits, with operators defined as traits, and static dispatch.
- Precompiled library dependencies and separate compilation.
- A package ecosystem shared across profiles.
- More backends, without changes to profiles.
- A rewritten compiler front end with a richer AST, including generics.
- Further profiles built on the same core.
C4 is under active development and the language is still evolving. Expect breaking changes while the core, the profiles and the compiler settle.
Issues and discussion are welcome. To get in touch, write to cto@adadynamics.org.
C4 is released under the MIT License.
Copyright (c) 2026 ADA Dynamics Ltd
Built by ADA Dynamics Ltd.