Typical

TypeScript is the gold standard for developer ergonomics. Its syntax is clean, expressive, and intuitive—even beginners can write correct-looking code on day one. The ecosystem is massive, the tooling is unmatched, and the language's type system strikes a rare balance between safety and flexibility. For most web-scale applications, nothing comes close.

But TypeScript wasn't built for the hard stuff.

Typical exists because the world is changing: LLMs are writing more of our code, and the demands on that code are going up. TypeScript's foundations—dynamic quasi-JIT-compiled runtime, JS number model, single-threaded event loop—don't hold up under the weight of high-performance workloads or provable correctness. The problems appear when you move beyond rudimentary server backends:

No real-time guarantees — TypeScript's memory model is garbage-collected and unpredictable. Latency spikes are unavoidable.
No shared memory concurrency — Workers are isolated by design. State sharing is clunky, unsafe, or straight-up impossible without IPC hacks.
Numbers are broken — Everything is (basically) a 64-bit float. No proper integers, no fixed-point decimals, no SIMD. This alone disqualifies it from serious scientific or AI workloads.
The type system still blurs truth — It's expressive, yes, but not fully precise. At the edges—mutability, aliasing, optionality—ambiguity creeps in. You can't build high-assurance systems on it.

Typical fixes this. It keeps TypeScript's feel but swaps the engine underneath: replacing dynamic JS with safe, predictable Rust. You still write const, async, and interface, but now it compiles to something you'd trust in an AI core, a trading loop, or a drone. You get full ownership semantics, multithreading with shared state, region-based memory, zero-cost error propagation—and it's all statically analyzable.

Although Typical compiles to idiomatic TypeScript and can live comfortably within a larger TypeScript project, it has no ambitions of replacing TypeScript on the web. It's what you reach for when TypeScript runs out of headroom.

Rust is a triumph of systems programming. Its ownership model wipes out whole bug classes without a GC. Concurrency is race-free, efficient, and rock-solid. If you're writing an OS or trading engine, it's the gold standard.

But most developers don't want to write Rust.

Rust's strengths come with heavy tradeoffs: high complexity, low iteration speed, and too much cognitive overhead for most teams and use cases.

Steep learning curve — The ownership model is brilliant but brutal. Lifetimes and borrow rules routinely trip up even seasoned devs.
Slow compiles — Runtime performance is great, but compile times are painful—especially in fast-paced teams.
Ergonomic tax — Rust claims ergonomic intent, but explicitness always wins. Great for safety. Awful for iteration.
LLM-hostile — The language's over-eager demands of precision make it hard for LLMs to generate correct, idiomatic code reliably.
Concurrency is too open-ended — Powerful, but too unconstrained. AI agents and high-assurance systems need stricter, safer concurrency models.
Not enough guarantees by default — For truly regulated or real-time systems, Rust still needs external tooling to meet the bar. That's why many teams stick with C (plus contracts or model checking).

Typical doesn't replace Rust—it runs on it.

Typical keeps Rust's safety and performance, but wraps it in a faster, friendlier surface: TypeScript-like syntax, region-based memory, actor-style concurrency, and constraints LLMs can thrive in. It's Rust's power—without the pain.

Go compiles fast. It builds native binaries with decent performance, minimal friction, and top-tier tooling—debuggers, LSPs, and cross-compilation (assuming no cgo) all Just Work™. For many teams, that alone makes it feel productive.

But the language itself is dead weight.

Go's so-called “simplicity” is really just a failure to manage complexity in the design. It avoids modern type theory, rejects ergonomics, and ships with half-baked features (see: generics, pointers, modules). It's a structural language that can't express structure.

Staggeringly low abstraction ceiling — Generics were bolted on as a late-stage concession, and it shows. No sum types, no first-class iterators, and even variable declarations use a bizarre syntax. You're left with hand-rolled boilerplate and interface{} hacks.
Verbose and inexpressive — The error handling pattern is farcical–Go insists on repeating if err != nil until your brain melts.
Standard library is inconsistent — Incoherent APIs, mixed naming conventions, and data races hiding in supposedly “safe” types. It doesn't feel designed—it feels random.
M:N goroutines ≠ simplicity — Goroutines feel ergonomic, but under the hood: scheduler edge-cases, nondeterministic behavior, data-race foot-guns, and unpredictable latency. Not what you want in regulated or real-time environments.
GC is the Achilles' heel — To be fair, Go's garbage collector is one of the better ones. But a GC is still a GC—unfit for large heaps, low-latency systems, or anything needing predictable memory behavior.

Typical fixes all of this.

Go tried to be simple. Typical is simple—but with intention, power, and long-term viability. It has a coherent type system, real control over memory and concurrency, real-time safety, and a surface designed for both humans and LLMs. It's what Go wanted to be, minus the decade of denial.

Python has great libraries. If you're doing data work, chances are someone already wrapped a fast C/C++ core in a Python shell—NumPy, Pandas, JAX, PyTorch. That ecosystem inertia is strong. It's also dead simple to write throwaway scripts.

But the language itself is a liability.

Python wasn't designed for the things it's now famous for. Scientific computing, large-scale systems, AI workloads—these domains bend Python until it breaks, then patch it back together with C extensions.

Numerics are duct-taped on — Without real vectorized ops, operator overloading, or unit-safe arithmetic (remember NASA's $150M Mars crash?), libraries like NumPy exist in spite of Python, not because of it.
The type system is a mirage — Static types arrived late, bolted on as annotations. Type hints are optional, inconsistently enforced, and still feel like a side quest.
Performance is dismal — Even with JITs and C extensions, core Python is slow. Always has been, always will be.
GIL = No threads for you — The Global Interpreter Lock kneecaps any hope of real multi-threading. You want parallelism? Spawn processes and fight the tooling.
The tooling is a mess — Virtual environments, package managers, formatters, linters, type checkers, debuggers—all fractured, fragile, and rarely consistent.

Typical was built to do Python's job—but correctly.

Typical gives you high-level expressiveness and real performance. It has first-class vectorization, unit-safe numerics, expressive types from day one, real concurrency, and a tooling story that doesn't feel like it was cobbled together in a basement. And despite all that power, it's still dead simple to learn. No GIL, no weird install dance, no guessing what's dynamic vs static, and a 1-line "hello world" source file still compiles. For beginners, it's easier than Python. For experts, it scales way further.

Kotlin is one of the most thoughtfully designed mainstream languages in recent memory. Its syntax is clean, the standard library is coherent, and it balances power with approachability. You can tell it was built by people who understood both modern language design and real-world developer pain.

But the JVM is a heavy anchor.

Kotlin's elegance is constrained by the baggage it inherits. The JVM brings decades of complexity, clunky interop with legacy Java APIs, and a garbage-collected runtime that limits its reach.

GC puts it out of bounds — The presence of a garbage collector rules Kotlin out for large heaps, hard real-time systems, or latency-critical domains.
Still carries Java's shadow — Despite Kotlin's modern surface, Java's ceremony, legacy quirks, and ecosystem complexity still leak through.
Ecosystem isn't deep — While growing, Kotlin's reach is still centered around Android and backend services. It doesn't stretch far into systems, scientific, or performance-critical domains.
Concurrency model isn't first-class — Kotlin Coroutines improve ergonomics, but they're cooperative, not preemptive, and lack the semantics required for rigorous concurrency safety.

Typical goes where Kotlin can't.

Typical takes Kotlin's spirit—clean syntax, ergonomics-first design—but unshackles it from the JVM. It gives you deterministic memory, real-time readiness, no GC, and concurrency that's built into the type system. And unlike Kotlin, Typical is optimized for both human cognition and LLM generation.

Bonus: A "compile-to-Kotlin" backend is on Typical's roadmap. So one day, you may be able to write high-performance, statically safe Typical code that runs natively on the JVM.

Swift starts strong. It has a clean core syntax, modern type system, solid performance, and a vision for safer systems programming. On paper, it looks like a general-purpose language with teeth.

But in practice, it's Apple all the way down.

Swift's real-world utility is tightly bound to the Apple ecosystem. Once you stray outside of iOS or macOS dev, the friction piles up fast.

Syntax gets weird fast — The core is nice, but things go sideways: open vs public, opaque generics, and a slew of breaking changes between versions. It's as if Swift keeps reinventing itself without ever stabilizing.
Xcode is the cage — You're effectively locked into Apple's tooling. For anyone not already deep in the macOS cult, Xcode is a janky, bloated, soul-crushing experience. Compiling feels like submitting forms to the Department of Builds and Compilation.
It's a DSL for Apple — Swift was designed to build apps in the Apple ecosystem. That's its center of gravity. Outside that world, it's an also-ran.
No open-source momentum — Swift's presence in the OSS world is a rounding error.
LLMs can't SwiftUI — LLMs can generate SwiftUI. They just can't generate working SwiftUI. The framework's implicitness and magic syntax make success unlikely—ever.
Objective-C baggage lingers — Interop with legacy Apple code means weird pointer semantics, compiler hacks, and other ancient debris still surface.
ARC footguns — Swift ditched GC for ARC, which sounds great… until you hit retain cycles and memory leaks that only show up at runtime, often in production.

Typical doesn't play favorites.

Typical brings Swift's performance and safety goals to the whole software world—not just Cupertino. It offers strong, static memory guarantees, LLM-friendly syntax, and great ergonomics, without the walled garden or version drama. It's a true general-purpose systems language, with none of the fine print.

C# is a genuinely well-designed language with thoughtful syntax, excellent tooling, and a huge install base. But in practice, it still drags around a lot of architectural and cultural baggage that limits its reach—especially in modern infra and high-assurance domains.

Reflection is everywhere — C# leans heavily on runtime type info and reflection. That makes it flexible, but undermines static guarantees. You can't prove much at compile time when half the system wires itself together at runtime. This is a non-starter for regulated domains or safety-critical work.
Garbage collection creates ceilings — GC means you're out of the running for low-latency systems, large heaps, and real-time constraints. That rules out a huge swath of use cases—from trading systems to embedded control loops.
Still feels "enterprise thick" — Modern .NET is lighter than it used to be, but you can still feel the weight: MSBuild, verbose project scaffolding, dependency chains that spiral. Native AOT is a step forward, but it's more retrofit than rethink—it works best if you avoid half the ecosystem.
Tooling lock-in persists — Visual Studio is powerful but heavy and mostly Windows-native. VS Code + OmniSharp is okay, but still doesn't match the frictionless feel of go run, cargo build, or just writing code in vim and shipping it in a container.
Ecosystem never crossed the OSS divide — C# missed the cloud-native wave. While Node, Go, Python, and Rust became the default picks for lean deploys, C# stayed rooted in big-team, long-cycle, Windows-first development. It never quite made the cultural leap.

Typical takes a different path. It delivers the same high-level expressiveness and runtime performance goals, but without reflection, without GC, and without legacy scaffolding. Types are statically checkable all the way down—even in cases that would require runtime hacks elsewhere. That makes it viable for domains where guarantees matter: realtime, embedded, safety-critical, or regulated. And the ergonomics? Closer to Go than to Java. No ceremony, no scaffolding, no IDE handholding. Just write, build, ship.

C is the foundation. It's the lingua franca of systems programming, embedded work, and regulated domains. It earned that status with raw simplicity and decades of trust. But for modern development, it's like building a spaceship with only duct tape and hex wrenches.

No guardrails. No ownership model, no bounds checking, no meaningful type safety. C trusts you completely. Which is fine—until you're debugging a segfault in the field three months after launch. Almost everything is allowed, and almost nothing is safe.
Manual everything. Memory management, error handling, concurrency, build systems—it's all DIY. You can make it do anything, but you'll be wiring it together yourself with global state and #ifdef spaghetti. Every abstraction is handcrafted. Every bug is yours alone.
Ergonomics from another era. #include isn't a module system. Header files are a relic. The language predates modern tooling expectations, and it shows—dependency management, testing, and packaging all feel bolted on. You're basically managing a source tree with copy-paste and hope.
Highly conditional scalability. Managing massive C codebases is only possible when rigid standards, tight processes, and deep domain knowledge is pervasive in the team. Most teams don't work like this. Without language-level structure to enforce boundaries and contracts, scale tends to collapse into chaos.

Typical doesn't try to match C's lowest-level freedom. It draws a line just above the chaos—offering layout control, deterministic behavior, and real-time viability without the landmines. You still write close to the metal, but with a type system that catches mistakes, a static memory model that doesn't hide traps, and a language surface built for teams, not lone hackers. It's systems programming with structure, not scaffolding.

C++ is the language you turn to when performance is paramount and trust is table stakes. It's the incumbent in infrastructure, embedded, games, and real-time systems—and it earned that place. But it has as many problems as it has features.

Too much and not enough. C++ has every feature you can name, and somehow still not the ones people need. Concepts, coroutines, smart pointers, template metaprogramming—but still no memory model that guarantees safety, no clear boundaries for static transparency. It's endlessly deep, but rarely focused.
Glacial Compile-times. Even small changes trigger full cascades of recompilation. Template-heavy codebases can take minutes to build. Incremental iteration—the thing modern teams rely on for flow—is constantly derailed.
LLMs can't use it. The structure of C++ makes it hostile to LLM-acceleration. Satya Nadella said it diplomatically; we'll say it bluntly: LLMs get lost in C++'s complexity, especially around concurrency and metaprogramming. The language was never built with machines in mind, and it shows.
Stuck in legacy. Header files and macros are still the norm. The build model hasn't evolved. Static analysis tools exist, but often require whole ecosystems of config and context just to work right. “Modern C++” often means doing contortions to make the old stuff tolerable.

Typical is built in response to this. A modern memory model. A disciplined approach to concurrency. Guaranteed static transparency. An ergonomic design that produces breakneck development velocity—further accelerated by LLMs—while still paving the way toward formal methods. And when you're prototyping or iterating, Typical compiles straight to TypeScript. That gives you a fast, interpreted path for feedback and testing, without giving up the ability to drop to the metal when you need to.

Zig presents itself as a simpler, saner alternative to C. The syntax is clean. The promises are big: safety without hidden control flow, modern tooling, no undefined behavior. On the surface, it looks like a streamlined path to systems programming. But once you're in, the story changes.

Looks like TypeScript, acts like a compiler thesis. Zig’s aesthetics suggest approachability—but the experience skews arcane. Its semantics are full of under-explained rules, and its compiler errors often require reading the compiler itself. It’s not a general-purpose language; it’s a DSL around one man’s opinion of how software should be written.
Even with GPT-5, you’re on your own. Zig is underrepresented in training data, and its control model breaks LLM assumptions. comptime is powerful but alien, and the language avoids idioms that models have seen before. So they hallucinate, get stuck, or give up. Even the best models flail. Unless Zig’s ecosystem changes dramatically, that’s not going to improve.
Tooling without empathy. Zig reinvents everything—build system, error handling, allocation—but not always in ways that help you move faster. It’s optimized for how one person thinks, not how teams operate. If your workflow isn’t a direct mirror of the author’s, then in his own words: "Zig isn’t for you".
Explicit ≠ clear. Zig’s obsession with manual control often means writing more to get less. Debugging isn’t just hard—it’s opaque. Want to know why something ran at comptime? Good luck. Want to avoid writing your own stdlib-alike? Not happening. The ecosystem is minimal and the conventions are DIY.
Sparse ecosystem, lonely defaults. With few libraries and little shared culture, you’re on your own. Zig rewards deep understanding and total buy-in—but punishes deviation. For prototyping, collaboration, or rapid iteration, it’s not viable.

Typical took a different path. It borrows so much from TypeScript that you may not even immediately realize it's a different language. It doesn't swap decades of historical wisdom for narrow mandates ("all hidden control flow is bad!"). It builds on very familiar ground, and keeps new surface area to a minimum. That makes it deeply compatible with LLMs, which already mostly understand language out of the box. No esoteric idioms, no alien control flow. Just types, structure, and intent the model can follow. You get high-performance systems programming and LLM-native developer experience—not by chasing novelty, but by leaning into what already works.

Java built the enterprise. It still powers huge chunks of the world—banks, telcos, Fortune 500 backends. But as a systems language, it's a non-starter. Its strengths are precisely what make it unsuitable for the kind of work Typical is built for.

Legacy by design. Java has barely evolved compared to modern language expectations. Even Kotlin—the language most invested in Java's ecosystem—treats Java as a liability. Boilerplate, verbosity, and lack of modern expressiveness are treated as facts of life, not problems to solve.
Garbage collection is a dealbreaker. You don't get real-time performance with GC. You don't get deterministic latency. You don't get predictable memory behavior. And if you're working in regulated or safety-critical environments, GC alone disqualifies it. Java was never meant to run close to the metal.
The JVM is a heavyweight anchor. JVM tuning is a discipline unto itself. Managing installs, memory limits, GC profiles, and runtime flags just to get tolerable behavior at scale is friction no one wants. Java doesn't ship—it boots.
Bloat all the way down. Even “simple” Java apps come wrapped in megabytes of class files, reflection metadata, runtime scaffolding, and fragile dependency graphs. It's not just slow to start; it's slow to reason about, slow to iterate, and slow to evolve.
Threading without teeth. Java's concurrency model predates modern multicore design. You get threads, locks, and synchronized, but no guarantees, no ownership, no static safety. Structured concurrency arrived late, and it's still bolted-on—not baked-in.

Typical doesn't try to fix Java. It avoids its entire class of problems by design. No garbage collection. No runtime. No VM. Just code that compiles to a known layout, runs predictably, and scales down to microcontrollers or up to mainframes without dragging an entire virtual machine along for the ride. And because it looks like TypeScript, not Java, it plays nice with humans and LLMs—without needing a 900-page spec to explain why null exists.

Ada is one of the most rigorously designed languages in history. It was built not just for correctness, but for assurance—formal specification, real-time safety, systems-level control. And it shows. The language emerged from a methodical, standards-driven process that prioritized clarity, predictability, and zero surprises. In many ways, Typical owes a debt to that lineage.

But the world Ada was built for is not the one we live in today.

Designed for certainty, not velocity. Ada's grammar and structure enforce discipline—but at the cost of fluency. It's verbose, rigid, and optimized for systems where compile-time audits matter more than anything else. That's not a bug—but it does make rapid prototyping and feedback-driven design harder than it needs to be.
LLMs don't speak Ada. Ada is virtually absent from modern training data. It's structurally very unlike the languages today's models are trained to assist with. The result: LLMs can't help you. They hallucinate, misread, or fall silent entirely. And without broad usage or shared idioms, that's unlikely to change.
Concurrency, the hard way. Ada's rendezvous-style concurrency model is precise and safe—but also heavyweight. It's designed for predictability in high-assurance systems, not for squeezing throughput out of modern multicore or heterogenous systems. If you're optimizing for perf or scalability, it's not the right primitive.
The ecosystem is an island. Ada's toolchain is battle-tested, but isolated. The package ecosystem is sparse. Community conventions vary. And modern integration points—observability, cloud targets, LLM-enhanced tooling—just aren't part of the story. That's fine for embedded avionics. Less fine for most other domains.
The grammar belongs to another era. Ada's syntax is safe and readable—but looks more like Pascal than anything in the modern developer's toolkit. That makes it harder to learn, harder to teach, and harder for tools to intuit. Even seasoned engineers need time to ramp.

Typical channels Ada's obsession with clarity and guarantees—but rebuilds it on modern foundations. It uses familiar syntax, minimal surface area, and deep LLM compatibility to deliver both assurance and momentum. You get the predictability Ada fought for, without giving up iteration speed, ecosystem reach, or toolchain velocity.

COBOL has earned its reputation. For over 60 years, it's powered the most mission-critical infrastructure on the planet—banks, governments, insurers, logistics networks. It was built for a world where uptime was paramount and compute was precious, and it delivered. It still delivers.

It's not broken. But the world around it is changing.

The workforce is vanishing. The people who understand COBOL are retiring. The next generation isn't learning it. Retraining programs haven't scaled. This isn't a temporary talent crunch—it's a structural collapse in continuity.
Tooling hasn't kept pace. While the code still works, the developer experience hasn't evolved. There's no intelligent assistance. No LLM copilots. No dev environments that meet modern expectations. For systems that need to last another 20 years, that's a problem.
Migration is hard because COBOL was actually good. Modern languages don't replicate its strengths well. COBOL has a concurrency and memory model that fits mainframe computing like a glove—sequential determinism, bounded memory lifetimes, predictable tasking. But "modern" languages take a less disciplined approach to memory and concurrency. That's why “rewrites” often fail: the target languages simply weren't built for this.

Typical, paradoxically, offers a path forward because it respects the past.

It shares COBOL's priorities: safety, predictability, and auditability. But it brings those values into the modern era—designed for today's developers, tools, and workflows.

Its region-based memory model mirrors COBOL's explicit, bounded storage—making memory behavior predictable and verifiable.
Its threads-as-types concurrency supports structured, deterministic tasking—much like the synchronous control flow COBOL developers are used to.
And it compiles to Rust, giving you modern safety and performance, while maintaining the kind of runtime discipline COBOL was built on.

Most languages force you to choose between certainty and progress. Typical is the rare exception that gives you both. It enables COBOL systems to evolve mechanically, gradually, and safely—preserving the semantics, while upgrading the foundations.

Typical isn't about forgetting COBOL. It's about finishing what it started—with a language ready for the next 60 years.

The AI-Native Language.
Authored By AI.

LLM Code Writing Is Plateauing

Syntax For All

Beyond Existing Languages.

Unapologetically Docs-First

Built for Decades. Not Sprints.

No New Stacks. It's Just Rust.

MIT-Licensed Open-Source

LLM+SEA

Testimonials From GPT-4o

The AI-Native Language. Authored By AI.