How Kasuri compares

This chapter compares architectural properties, not quality. Every language below is excellent at what it was designed for, and each is in production at enormous scale. The question here is narrower: which of them can answer, mechanically, what a given component is able to reach — and what that answer costs.

Section 01What is being compared, and what is not

A fair comparison needs its terms stated, because most language comparisons are unfalsifiable.

• Compared: properties that are decided by the language and its toolchain, that hold for every program written in it, and that a third party can check. Ambient authority, dependency surface, what executes during a build, where the tier boundary is maintained, whether permissions are expressible, whether diagnostics are machine-actionable.
• Not compared: performance, ecosystem breadth, hiring pool, library quality, developer satisfaction, or how pleasant anything is to write. Kasuri would lose several of those outright, and they are not the argument.
• Not claimed: that any of these languages is insecure. Secure systems are built in all of them daily. The claim is that in each one, security is a property of how carefully it was used rather than of what could be written — and that this distinction becomes decisive when the author is a machine producing at volume.

Section 02The comparison

Kasuri's column describes design intent at specification stage. Nothing in it has been demonstrated in a shipped toolchain, because there is not yet a shipped toolchain.

Section 03What a language of this kind costs to build

Component effort, from the record

What that totals

Summing the ranges gives roughly 30 to 100 person-years to reach a credible 1.0, depending almost entirely on two decisions: whether the standard library is broad or lean, and whether the compiler is built as a queryable library from the start or retrofitted later.

Convert at a fully-loaded engineering cost — your figure, not ours. The arithmetic is deliberately trivial so you can substitute:

That is the build cost alone. It excludes the far larger ongoing number: maintenance, security response, release engineering, documentation, and the compatibility burden of every decision that turned out wrong. For the incumbents that ongoing cost has run for decades and is what their ecosystems actually represent.

How the incumbents were funded — what is publicly observable

No dollar figures, because none are published. What is observable is the funding model, and it explains more than a number would.

Python

Volunteer-founded, then foundation-stewarded with corporate sponsorshipThree decades of accumulated contribution. The cost was real and was largely donated, which is why it cannot be totalled and why its sustainability is a live topic in its own community.

Java · C#

Corporate, with large sustained teams over decadesThe two most heavily resourced language efforts in commercial history. Their assurance tooling maturity is a direct function of that spend.

Go

Corporate, deliberately small core teamA broad standard library to 1.0 sits at the 20–50 person-year end of the table above. Go's restraint elsewhere — no build scripts, deterministic resolution — is visible in how few things it chose to build.

Rust

Corporate-incubated, then foundation-stewardedA leaner standard library (5–10 person-years) traded against ecosystem-debt interest paid later, plus a compiler-as-library retrofit that landed in the 5–20 person-year band rather than the 1–3 band.

TypeScript

Corporate, and structurally the cheapest of the fiveIt inherited a runtime, a standard library and an ecosystem from JavaScript, so almost none of the table above applied. That is why it reached adoption faster than any clean-slate effort ever has — and it is the strongest argument against doing what this programme is doing.

Where Kasuri sits

The programme's own constraint set sizes the parts it intends to own rather than rent: a trusted computing base of roughly 15,000–25,000 lines at 2–4 person-years, and a reactive persistence layer at 1.5–3 person-years — the latter only because the storage engine underneath is rented, which is the same decision that kept the two comparable startup builds inside 5–15 rather than beyond it.

Everything else in the table is adopted where adoption is honest: the resolution model and transparency log, the backup and point-in-time-recovery layer, the collector, the observability plumbing. The build-versus-rent decision is made per component, in writing, with a measurable trigger for reversing it.

The stated funding floor for the programme is $150,000–250,000 per year, patient money only. Set against the table above, that is a deliberately slow build — which is the point of the staged gates rather than an apology for them.

Section 04Where the incumbents win, stated properly

The bottom three rows are the ones that decide most real procurement decisions, and Kasuri loses all three by a distance. It is worth being explicit about the rest too.

Go

The closest thing to a structural answer available todayNo build scripts, deterministic resolution against a checksum log, a genuinely low dependency surface, routine reproducible builds. Four of the rows above are already green. Go got the supply-chain question right years before it was fashionable, and any organisation that can standardise on it should take that seriously.

Rust

The strongest safety guarantees in production useMemory safety without a collector is a property Kasuri does not attempt, and its diagnostics are the best in the industry — the closest prior art to the compiler-as-reviewer argument in Chapter 14. Its weakness here is build scripts and an ambient-authority model like everyone else's.

Java / C#

The most mature assurance tooling and governanceDecades of static analysis, profiling, audit and compliance tooling, and enterprise support arrangements that satisfy procurement without argument. A runtime permission architecture was tried here and withdrawn — which is evidence for the retrofit claim, not against the platform.

Python

Unmatched reach and the highest model fluencyIf the binding constraint is what a model can write well today, Python wins outright and it is not close.

TypeScript / Node

One language across client and server, and the largest ecosystemIt is also the only incumbent that already spans the tiers Kasuri is trying to unify, which makes it the fairest comparison arm — and it is the arm the benchmark uses.

Section 05Where Kasuri loses

Section 06Against the other AI-native efforts

Several recent languages and frameworks position themselves around AI authorship. We reviewed the field during the research phase and the honest summary is short: the ideas overlap, the evidence standard does not.

What we did not find was a project that is simultaneously (a) whole-stack, (b) built on removing authority rather than adding detection, and (c) holding itself to published, pre-registered criteria capable of ending it. Any one of those is common. The combination is the gap this programme is aimed at, and if a reader knows of a counter-example we would genuinely like to see it — that is a refutation of the premise, which is more useful to us than agreement.

Section 07What a fair evaluation would measure

If you are assessing this seriously, these are the comparisons worth running — and they are the ones the benchmark is built around, so an unfavourable result is a published result rather than a quiet one.

• Unsound-pass rate. Of the programs that pass their functional tests, what fraction is exploitable? The incumbent baseline is established at roughly half.^[1] This is the comparison Kasuri exists to win, and the one that would falsify it.
• Repair rate under diagnostics. How many tasks does the same model complete unaided versus iterating against the compiler? The cross-language precedent is 22 of 56 against 54 of 56.^[12]
• Cost per solved task. Not per token. A pre-registered secondary, and a stop condition if it loses (Chapter 10).
• Familiarity-adjusted parity. The same model on Kasuri versus the strongest incumbent stack, with the familiarity gap controlled rather than ignored.
• Enumerability. Ask each stack to produce, mechanically, a complete list of what a given component can reach. Only one column above can answer at all — and that is a claim you can test the day an implementation exists.