> JIT warmup is real. The first call to any method pays the compilation cost. In a database engine, the first transaction after startup shouldn’t be 100x slower than the steady state.
Correct me if I'm wrong but isn't it what aot was supposed to solve?
Also worth mentioning are VeloxDB and RavenDB, both written in C#. TBF, I haven't used any of them... but aware they exist.
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.
C# is a great language with almost unlimited power and great ergonomics (as the article shows), but the .NET CLR (runtime) is a bit overcomplicated with a distinct "Java smell", and packaging and distribution is still meh.
If they could make the developer experience similar to Go, it would rule the world...
I drank the Go kool-aid, then tried to do some high performance things the Go way: didn't work (channels are slow) and I got over it. Still think Go is great for web backends and the like with production grade stdlib.
> JIT warmup is real. The first call to any method pays the compilation cost. In a database engine, the first transaction after startup shouldn’t be 100x slower than the steady state.
Correct me if I'm wrong but isn't it what aot was supposed to solve?
Also worth mentioning are VeloxDB and RavenDB, both written in C#. TBF, I haven't used any of them... but aware they exist.
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 wonder why he didn't use AOT compiling if he's worried about JIT warmup.
C# is a great language with almost unlimited power and great ergonomics (as the article shows), but the .NET CLR (runtime) is a bit overcomplicated with a distinct "Java smell", and packaging and distribution is still meh.
If they could make the developer experience similar to Go, it would rule the world...
> 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.
AOT is not a panacea and comes with some restrictions/trade-offs that need understood before depending on it in production.
I drank the Go kool-aid, then tried to do some high performance things the Go way: didn't work (channels are slow) and I got over it. Still think Go is great for web backends and the like with production grade stdlib.
Great post with details, not a I'm vibe coding...
> tried to do some high performance things the Go way: didn't work (channels are slow) and I got over it.
What did you choose instead?