Common Code Language

Define shared models once.

CCL is a small language for describing data models that can be generated into code for multiple programming languages. It is built for teams that want one clear source of truth instead of duplicated structs, classes, and serialization glue.

What it is A schema-like language for code generation, not a general-purpose programming language.
Primary use Keep shared models consistent across servers, clients, and generated libraries.
Design bias Minimal syntax, explicit attributes, and codegen-oriented workflows.

Know the target status before you dive in.

The quickest question many people have is whether their language is stable yet. This list shows which generators have full codegen now, which ones are actively being built, and which ones are still in planning.

Need details for a specific target?

Open the language pages to see codegen status for Go, GDScript, C#, Python, JavaScript, TypeScript, C, C++, Rust, Zig, and Lua.

Browse language docs

The language is small on purpose.

CCL is for situations where the data contract matters more than language-specific syntax. If your project shares models across multiple targets, the goal is to describe those models once and let generators produce the repetitive parts.

Define shared models once

Describe the shape of your data a single time, then generate code for multiple runtimes instead of retyping the same model definitions everywhere.

Stay intentionally small

CCL focuses on model definitions and code generation. It is meant to be easy to scan, easy to review, and hard to overcomplicate.

Keep serialization explicit

Attributes make serialization choices visible at the language level instead of hiding them in generator-specific side channels.

A fit for teams that value consistency over ceremony.

The best use case is shared model definitions that need to stay aligned across different languages or runtimes. If that is not your problem, you can usually tell quickly and move on without getting lost in the docs.

Backend and client teams

  • Use one source of truth for shared request and response models.
  • Avoid schema drift across languages and services.

Tooling-minded engineers

  • Treat model definitions as architecture, not as scattered boilerplate.
  • Keep generated code flowing from versioned source files.

People evaluating fast

  • Understand what CCL is in a few minutes.
  • Decide quickly whether it matches your project before diving into reference docs.

Use the docs intentionally.

The landing page should help a new visitor answer “is this relevant to me?” immediately. After that, the docs split into short paths instead of one giant wall of technical detail.

Start with the docs hub

Go to Docs for the project overview, installation, and the language basics.

Jump to reference when you already know the tool

Use CLI reference and attribute docs when you need specifics without rereading the introductory material.

Check the roadmap before planning around a target

Read the roadmap for completed milestones, active work, and planned language and input-format support.

Primary next step

If you are evaluating CCL, read the language overview and the getting-started page before diving into generators or internals.

Open getting started