Manifesto

Why kern exists

The case for a European backend language built for the world developers actually live in today.

Every major backend language was designed before GDPR, before large language models, before container-native infrastructure, and before European digital sovereignty became a legal and economic priority.

They all require you to bolt these things on -- as libraries, middleware, and external tools -- in different languages, with different error models, governed by American corporations.

Kern is the first backend language designed after all of these became requirements.

Designed after the
requirements existed.

Feature Python Go Node.js Rust Java Kern
Readable syntax Yes Verbose JS baggage Complex Verbose Yes
Single binary No Yes No Yes No Yes
Native async Bolted on Goroutines Yes Complex No Yes
Type safety Optional Yes No Yes Yes Yes
Null safety No No No Yes No Yes
GDPR built in No No No No No Yes
AI native No No No No No Yes
Container native No No No No No Yes
European governed No No No No No Yes
Learning curve Low Medium Medium Very high High Low
Error handling Exceptions Values Exceptions Values Exceptions Values

Why kern exists

1

Nobody has solved the full stack in one language

Go gives you performance. Python gives you readability. Node gives you async. TypeScript gives you types. Every team picks two or three and accepts the tradeoffs of the rest.

Kern is the first language designed from scratch with all four -- because it started after all four existed and could learn from each of them.

readable.kern
# Readable like Python
fn process(users: List<User>) -> Result<Report>:
    active = users.filter(fn(u) -> u.active)
    return Ok(Report(count: active.length))
types.kern
# Type safe like TypeScript -- nullable is opt-in
name: str   = "Marie"   # can never be null
alias: str? = none      # explicitly nullable
async.kern
# Async like Node -- native event loop
task1 = spawn fetch_users()
task2 = spawn fetch_orders()
users  = await task1
orders = await task2
build.sh
# Fast like Go -- compiles to a single native binary
kern build my-api.kern -o my-api
./my-api   # no runtime, no interpreter, no dependencies

All four. One language. No compromise.

2

GDPR compliance is currently a library bolted on

Every European company using Python, Go, or Node.js manages GDPR compliance manually. They bolt on libraries, write custom middleware, train developers, audit code. It fails constantly because nothing in the language itself prevents a developer from passing personal data to the wrong place.

In Python, this compiles, runs, and silently violates GDPR:

violation.py Python
def send_email(user):
    analytics.track(user.email)  # personal data sent to analytics -- GDPR violation
    send(user.email, "Welcome!")

In Kern, this is a compile error:

send_email.kern
fn send_email(user: User):
    analytics.track(user.email.value)
    # ERROR E0091: PersonalData<str> cannot be passed
    # without a valid ConsentRecord
    # Hint: use user.email.access(reason: "...", consent: record)

The only way to use personal data in Kern:

send_email_safe.kern
fn send_email(user: User):
    email = user.email.access(
        reason:  "send welcome email",
        consent: user.consent_record
    )
    analytics.track_event("signup")   # event only -- no PII
    send(email, "Welcome to Kern!")

No other language in the world enforces GDPR at the type system level. This alone justifies Kern's existence. The EU spends billions on compliance failures that Kern makes structurally impossible.

3

AI is now a backend requirement -- nobody treats it as one

Every modern backend needs LLM inference, embeddings, or RAG pipelines. In Python you glue together LangChain, an OpenAI SDK, Pinecone, and FastAPI -- four different APIs, four error models, four rate limit strategies, no type safety between them.

In Go or Rust you build everything yourself.

In Kern:

rag_pipeline.kern
import std.ai.rag as rag
import std.ai.llm as llm
import std.ai.embed as embed
import std.ai.vector as vector

pipe = rag.pipeline(
    embedder: embed.local("nomic-embed-text"),
    store:    vector.qdrant("my-docs"),
    model:    llm.ollama("mistral")     # local, private, European
)
await pipe.index_directory("./docs/")?
answer = await pipe.query("How do I deploy to production?")?
print(answer.text)

A production RAG pipeline in eight lines. European providers by default. Privacy enforced. Every AI call audit-logged for EU AI Act compliance.

Kern's AI defaults are European by design:

Cloud LLM Mistral France
Local LLM Ollama Fully private
Vector DB Qdrant Germany
Embeddings nomic-embed-text Local

And GDPR enforcement extends to AI. You cannot accidentally send personal data to an LLM:

ai_gdpr.kern
email: PersonalData<str> = user.email

await llm.mistral().complete(prompt: email.value)
# ERROR E0091: PersonalData<str> passed to AI model without consent
# This is a compile error -- it never reaches production
4

Container management belongs in the language

Every backend developer writes shell scripts, Dockerfiles, and YAML to manage infrastructure. These are in completely different languages from the application code. Errors are only caught at runtime. Tooling is fragmented across a dozen different CLIs.

In Kern, infrastructure is a first-class language feature:

deploy.kern
import sys.container
import sys.compose

async fn deploy():
    app = compose.stack("production", [
        compose.Service(
            name:  "db",
            image: "postgres:16-alpine",
            env:   {"POSTGRES_DB": "myapp"},
            volumes: ["db-data:/var/lib/postgresql/data"]
        ),
        compose.Service(
            name:    "api",
            image:   "myapp:1.0",
            ports:   ["8080:8080"],
            depends: ["db"]
        )
    ])
    await app.up()?
    log.info("Production stack running")

The same language, the same error handling, the same type system -- for your application code and your infrastructure code.

Kern's container runtime is built to become fully native on Linux -- speaking directly to the kernel via namespaces, cgroups, and overlayfs. No Docker dependency. No Podman dependency. Just Kern and Linux.

5

European sovereignty is not a political argument -- it is a legal and economic one

This is the argument people dismiss as political. It is not.

The legal reality: Under the US CLOUD Act, data stored on American-owned infrastructure -- including GitHub, npm, AWS, Azure, and GCP -- can be accessed by US authorities without a European court order. This applies even if the servers are physically located in Europe.

The economic reality: European companies pay approximately €100 billion per year to American cloud and software vendors. Open source software contributes €65-95 billion to EU GDP annually -- and almost all of it flows through American-controlled infrastructure.

The practical reality: When a European startup's GitHub repository is flagged under a bad-faith DMCA claim, there is no recourse under European law. When npm goes down, every European Node.js deployment is affected. When Microsoft changes GitHub's terms of service, European open source projects comply or leave.

Kern's entire supply chain is European:

Component Provider Country
Source codeCodebergGermany
Package registrypkg.kern-lang.eu (OVH/Scaleway)France
CI/CDWoodpeckerGermany
DNSdeSECGermany
Static hostingCodeberg PagesGermany
Default cloud LLMMistralFrance
Default vector DBQdrantGermany
Default local LLMOllamaOpen source

No GitHub. No npm. No AWS. No Cloudflare.

No other programming language can say this. Not even the ones created by European individuals. PHP was created by a Danish-Canadian and is governed by the Apache Foundation (USA). Erlang was created at Ericsson (Sweden) but is governed globally. Ruby was created in Japan. None have European governance as a founding principle.

How kern compares

Kern vs Go

Go is excellent. It is the language Kern respects most technically.

Where Go wins

Massive ecosystem, 15 years of production hardening, Google backing.

Where Kern wins

example.go Go
// Go -- valid code, runtime crash
var user *User = nil
fmt.Println(user.Name)  // nil pointer dereference -- panic

// Go error handling in real codebases
data, err := readFile(path)
if err != nil { return nil, err }
result, err := parseJSON(data)
if err != nil { return nil, err }
config, err := validate(result)
if err != nil { return nil, err }
example.kern
# Kern -- null structurally impossible
user: User = get_user()
print(user.name)   # cannot be nil -- the type system guarantees it

# Error propagation -- clean
data   = read_file(path)?
result = parse_json(data)?
config = validate(result)?

Go has no GDPR enforcement. Go has no AI native stdlib. Go is governed by Google. Kern addresses all three.

Kern vs Python

Python's readability is why Kern's syntax looks like Python. This is intentional and honest.

Where Python wins

Enormous ecosystem, NumPy/pandas/scikit-learn, fastest prototyping.

Where Kern wins

process_user.py Python
# Python -- GDPR violation ships silently to production
def process_user(user):
    log.info(f"Processing {user.email}")  # PII in logs -- GDPR violation
    analytics.identify(user.email)         # PII in analytics -- GDPR violation
    send_to_ml_pipeline(user.email)        # PII to ML -- GDPR violation
    # Python: all valid, compiles, ships, you get fined
process_user.kern
# Kern -- every access is tracked and requires justification
fn process_user(user: User):
    log.info("Processing user " + str(user.id))   # ID only -- OK
    analytics.identify(str(user.id))               # ID only -- OK

    email = user.email.access(
        reason:  "send confirmation",
        consent: user.consent_record
    )
    send_confirmation(email)   # now OK -- access logged, consent verified

Python is also 5-10x slower for HTTP workloads, requires a runtime and virtualenv for deployment, and has no real concurrency due to the GIL.

Kern vs Rust

Rust is the most technically impressive systems language available. Kern respects it.

Where Rust wins

Absolute peak performance, memory safety without GC, embedded systems, OS development.

Where Kern wins

Rust is famously difficult to learn. Compile times are painful. The ecosystem for backend web development is thin. There is no GDPR enforcement. There is no AI native stdlib.

Kern is not trying to replace Rust for systems programming. Kern is for the 95% of backend developers building APIs, services, and data pipelines.

Kern vs TypeScript / Node.js

TypeScript is the current best practice for Node backends. It is a genuine improvement on JavaScript.

Where TypeScript wins

Largest package ecosystem in the world, JavaScript familiarity, real-time applications, zero-friction deployment on Vercel and Netlify.

Where Kern wins

example.ts TypeScript
// TypeScript -- null still escapes the type system
const user: User | null = getUser()
user.name  // TypeScript allows this -- runtime crash if null

// TypeScript -- GDPR is entirely your problem
const email = user.email    // just a string -- no PersonalData tracking
sendToAnalytics(email)       // compiles fine -- GDPR violation
await openai.chat(email)     // compiles fine -- GDPR violation + AI data leak

TypeScript compiles to JavaScript -- you always carry V8 overhead. npm is American. The Node.js Foundation is American. Kern is governed in Europe.

What to say when
someone pushes back

"The ecosystem is too small."
True -- and every language that exists today started with no ecosystem. Go had no ecosystem in 2009. Rust had no ecosystem in 2015. The question is not the size of the ecosystem today. The question is whether the foundation is correct. Kern's standard library at launch is more complete than Go's was at v1.0 -- because we had 15 years of learning from Go, Python, Node, and Rust before writing a single line.
"Just use Go with GDPR libraries."
A library cannot enforce a compile-time constraint. A type system can. You cannot accidentally pass PersonalData<str> to the wrong function in Kern. You absolutely can in Go -- every day, in production, at companies that then receive GDPR fines. Adding a library does not change this. Only changing what the compiler allows changes this.
"European sovereignty is a political argument, not a technical one."
Tell that to the European companies that lost access to their GitHub repositories under bad-faith DMCA claims. Tell it to the teams whose npm dependencies were yanked without notice. Tell it to the public sector organisations whose legal teams have told them to reduce US cloud dependency but cannot because every language's toolchain runs on American infrastructure. Infrastructure governance is a technical and business risk. It has a cost. Kern removes that cost.
"Who will maintain it?"
The same institutions that maintain Linux, PostgreSQL, Python, and Firefox -- an open foundation funded by EU grants. The Sovereign Tech Fund (Germany) already funds programming language infrastructure. NGI and Horizon Europe fund exactly this kind of critical digital infrastructure. Kern is applying to all three.

Kern is the first backend language designed for the world developers actually live in today. GDPR compliance is enforced by the type system -- you cannot accidentally send personal data to the wrong place, because the compiler will not let you. AI is in the standard library with European providers by default, privacy-aware, and EU AI Act compliant. Container management is a first-class language feature. The entire toolchain -- from git forge to package registry to CI to hosting -- runs on European infrastructure governed by Europeans. You do not choose Kern instead of Go or Python. You choose Kern because no existing language was designed for the legal, technical, and sovereignty requirements that every European backend developer faces today.

Honest about what kern is
and what it's not

Kern is for

  • European companies subject to GDPR who are tired of compliance being a manual, error-prone process
  • Public sector organisations mandated to reduce US cloud dependency
  • Developers who love Python's readability but need Go's performance
  • Teams building AI-powered backends who want European providers and privacy by default
  • Anyone who believes critical digital infrastructure should not be governed by a single American corporation

Kern is not for

  • Data scientists who need NumPy and pandas -- use Python
  • Systems programmers building operating systems -- use Rust
  • Teams with ten years of Go investment -- switching has a cost, stay with Go
  • Projects that need Windows support -- Kern targets Linux (production) and macOS (development)

Kern is honest about what it is and what it is not.

Get started

terminal
# Install
$ curl -fsSL https://kern-lang.eu/install.sh | bash

# Your first Kern program
$ cat hello.kern
fn main():
    print("Hello, Europa!")

# Run it
$ kern run hello.kern
Hello, Europa!
Source: Codeberg
Packages: pkg.kern-lang.eu
License: EUPL-1.2
Governed: European Open Foundation

Built in Europe. Built to last.