For years I kept building increasingly paranoid distributed systems.
mTLS everywhere.
Passwordless authentication.
DPoP.
Ephemeral keys.
Post-quantum cryptography.
Event-driven architectures.
Session isolation.
Zero Trust.
Capability-based systems.
And yet something always felt fundamentally wrong.
No matter how secure the architecture became, the programming model itself still allowed impossible states to exist.
Tokens could be duplicated.
Sessions could accidentally survive longer than intended.
Ephemeral secrets could still be reused.
Events could theoretically be consumed twice.
Resources that should be single-use were treated as ordinary values.
Then VibeCoding happened.
And while exploring obscure programming languages through pure curiosity, I discovered Austral.
Not Rust ownership.
Not borrow checking.
Not runtime validation.
Actual linear types.
The moment I understood the concept, my brain immediately exploded with one question:
Why is this not everywhere already?
Because the implications are absurd.
Some things simply should not be copyable.
Ever.
A DPoP token should not be clonable.
An ephemeral post-quantum session key should not be reusable.
A payment authorization proof should not survive after consumption.
A one-time capability should not accidentally remain alive in memory.
A session should not silently duplicate itself through references.
And yet most mainstream languages still treat these values as normal data structures.
Linear types completely changed the way I think about systems.
Not incrementally.
Exponentially.
The Realization
The most important insight was this:
Some resources are not data.
They are semantic obligations.
A session token is not “information”.
It is a consumable capability.
An ephemeral key is not “state”.
It is a single-use cryptographic resource.
An event is not “just a message”.
It is a transition in a semantic lifecycle.
And these things should be represented by the type system itself.
Once I realized this, I started seeing entire categories of vulnerabilities as type modeling failures.
Replay attacks?
Resource duplication problems.
Session leakage?
Ownership violation.
Double event consumption?
Non-linear semantics.
DPoP misuse?
Copyable proof artifacts.
At that point I couldn’t go back anymore.
Austral Feels Like Looking Into the Future
What impressed me even more was that Austral is still relatively small and obscure.
Written in OCaml.
Compiling to WASM.
Extremely focused.
Extremely principled.
And somehow carrying ideas that should already exist in every serious systems language.
The funniest part is that discovering the language made me happy precisely because it still lacks many things.
That meant there was room to build.
And I immediately entered a state of complete technical obsession.
What Happened Next
In a matter of days I started building around the ecosystem itself.
I created:
- a fan version of the official website
- a package manager
- multiple packages
- testing utilities
- additional semantic types
- stronger type validations
- JavaScript-like ergonomic APIs
- developer tooling
And then things escalated.
I started building a full API framework around the principles I had been mentally designing for years:
- passwordless authentication
- mTLS
- post-quantum cryptography
- linear ephemeral keys
- linear DPoP tokens
- capability-driven security
- WASM execution
- event-driven semantics
The funny thing is:
linear types suddenly made all those ideas feel structurally correct.
Not “secured through convention”.
Not “validated through discipline”.
Actually enforced.
The Developer Experience Problem
The biggest tragedy of advanced languages is rarely their type system.
It’s their developer experience.
Most developers will never discover ideas like:
- linear capabilities
- affine ownership
- semantic resource consumption
- proof-driven execution
- capability-safe architectures
because the tooling around those ideas is usually painful.
So I accidentally found a new hobby:
Improving Developer Experience for obscure but revolutionary languages.
I want linear types to feel approachable.
Natural.
Useful.
Practical.
I want people to accidentally discover a safer computational model while building normal systems.
That’s why I started implementing APIs intentionally inspired by JavaScript ergonomics.
Because if developers can use linear semantic resources with APIs that feel familiar, the barrier disappears.
And once you understand the implications, it becomes impossible to ignore.
I Don’t Think Linear Types Are “Advanced”
I think they are inevitable.
Especially for:
- tokens
- sessions
- cryptographic material
- event streams
- ephemeral proofs
- authorization capabilities
- distributed behavioral resources
The idea that these resources are freely copyable now feels fundamentally incorrect to me.
And the more distributed systems become:
- event-driven
- proof-driven
- capability-based
- post-quantum
- zero-trust
the more absurd non-linear resource semantics start to look.
VibeCoding Changed More Than Productivity
People talk about VibeCoding as:
“AI writes code for you.”
That’s not the interesting part.
The interesting part is that curiosity suddenly became massively amplified.
You can now explore:
- obscure PL theory
- formal methods
- distributed semantics
- rewriting systems
- type systems
- capability calculi
without spending months fighting boilerplate before reaching experimentation.
And that changes everything.
Because now a random late-night curiosity about an obscure language can completely alter the architecture of your systems.
That’s exactly what happened to me with Austral.
And honestly?
I think I’ve only seen the beginning of what linear semantic systems will become.
Top comments (0)