Concrete
Concrete keeps authority, ownership, and trust boundaries visible.
If a function allocates, reaches the filesystem or network, crosses into foreign code, or depends on trusted internals, Concrete wants that fact to remain visible. The language is for programs whose behavior needs to stay legible under review, not for hiding operational reality behind convenience.
Visible In The Source
fn fetch_manifest(url: &String, cache_path: &String)
with(Network, File, Alloc) -> Manifest {
let body: String = http::get_text(url)?;
defer drop_string(body);
let hash: Hash = sha256_text(&body);
verify_manifest_hash(&body, &hash)?;
fs::write_string(cache_path, &body)?;
return parse_manifest(&body)?;
}
From the signature and body alone, a reviewer can already see network authority, file authority, allocation, cleanup, verification, and persistence.
And The Compiler Can Report The Same Distinction
verify_manifest:
caps: none
alloc: no
trusted: no
fetch_manifest:
caps: Network, Alloc
alloc: yes
trusted: no
Concrete is designed so these distinctions are not just present in the source, but mechanically reportable. That makes authority drift and allocation drift easier to review than in languages where those facts are mostly conventional rather than first-class.
Why This Matters
Concrete is aimed at systems code where hidden authority, hidden cleanup, and fuzzy trust boundaries make review harder than it should be. It is for people auditing systems code, security-sensitive tools, and infrastructure where hidden costs or hidden authority make review materially worse.
That means explicit capabilities instead of ambient authority, explicit ownership and cleanup instead of hidden runtime machinery, and explicit trust boundaries between ordinary safe code, trusted internals, foreign code, and proof-oriented subsets.
Why It Is Different
Concrete is not trying to maximize convenience by erasing operational facts. It is not moving toward GC, invisible finalization, or a large managed runtime. It is not a proof-only project, and it does not blur together safe code, trusted implementation techniques, and foreign unsafety.
Low-level pointer manipulation and foreign calls can exist, but they stay isolated behind `trusted` and `with(Unsafe)` boundaries instead of disappearing into ordinary code.
