Correct me if I'm wrong but isn't it what aot was supposed to solve?
Span<T> is more important for performance TBH JIT warmup isn't a huge issue for a long-running process
> ...but it may make your code much uglier
AI agents seem fairly good at generating source generators so there doesn't seem to be a reason to not use them.
C# is pretty powerful and capable of lower level usage, such as in the examples given... not to mention a pretty nice interop with C-style libraries. It looks like the intent here might be a custom database engine for service integrations... not necessarily a full rdbms in and of itself.
I've been working with C# for most of my career, almost 25 years, since .Net 1.0. One of the huge things that I love about Rust is the lack of a runtime framework. I don't need to figure out how to bundle / ship / install a framework at runtime.
(I also like Cargo better than Nuget, but that's a very subjective opinion.)
Which leads to probably the biggest tradeoff:
> Typhon is an embedded...
It's probably hard, (or impossible) to use Typhon outside of the dotnet ecosystem. Granted, it's been years (since the 1.0 days) since I built a .dll that a native application could pull in, there are complications when you "impose" dotnet into an application that isn't dotnet. These don't happen when your library is 100% native, which you get with C/C++/Rust.
Rust has a runtime, it's just tiny and auto-bundled (for now). Modern .NET's support for self-contained bundling has gotten pretty good. AOT is getting better too, and AOT-ready code (switch Reflection for Source Generators as much as possible, for instance) can do some very heavy treeshaking of the runtime.
Also, yeah native embedding has gotten somewhat easier in recent years depending on the style of API you want to present to native code. Furthermore both Godot and Unity (differently) embed .NET/C# as options in game development. I certainly expect Typhon is primarily targeting Godot and/or (eventually) Unity (when it finishes switching to coreclr to support more of these features) embedding (but maybe also Stride, a fully C# game engine).
Personally I'm not worried about the micro optimization, I'm more a "why are you attempting to compete with sqlite" person.
GC is like auto transmission, it's an inevitable natural evolution of programming languages.
I think the future of programming languages will have hybrid modes of GC and manual, similar to today's hybrid auto transmission automatic and manual in state-of-the-art hypercar [1]. I considered D language as pioneer in this innovative approach.
My hypothesis is that GC can be made deterministic like manual memory management, just like how ICE auto industry minimize the manual transmission. Heck, no manual for EV.
Hopefully the new io_uring facility with BPF controlled can enable this deterministic GC [2],[3].
[1] Here’s how Koenigsegg’s new manual/automatic CC850 gearbox work (2025):
https://www.topgear.com/car-news/supercars/heres-how-koenigs...
[2] BPF meets io_uring (2026):
https://lwn.net/Articles/847951/
[3] How io_uring and eBPF Will Revolutionize Programming in Linux (2020):
https://www.scylladb.com/2020/05/05/how-io_uring-and-ebpf-wi...
If they could make the developer experience similar to Go, it would rule the world...
You can already AOT compile .NET software to an executable to run on whichever platform you need, just like Go.
Libraries need to be published into a package manager (NuGet) which is more friction than just importing from Git repos but it's not that bad.
I've never used go, am curious
Great post with details, not a I'm vibe coding...
What did you choose instead?
I'm not sure authors of Cassandra, ElasticSearch, MongoDB (and more...?) ever had the slightest twinge of uncertainty about whether a managed memory env would cause far more problems than it fixed, even with less native tooling than in C#. Java bros DGAF