Discussion
Why I'm Building a Database Engine in C#
jaen: 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...
Rohansi: > 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.
hnrodey: AOT is not a panacea and comes with some restrictions/trade-offs that need understood before depending on it in production.
nitwit005: I would be less worried about the GC pause, than the need to reserve some memory for garbage collection. Any reduction in available memory is going to tend to mean a hit to performance.
benterix: > 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?
landl0rd: AOT is a little fussy in real-world usage particularly for things like reflection. You can probably force it to work but it may make your code much uglier.Span<T> is more important for performance TBH JIT warmup isn't a huge issue for a long-running process
CharlieDigital: > ...but it may make your code much uglier Flip side is that if you use more source generation, it may end up making the code more terse/"prettier" where it matters and avoid the reflection hit.AI agents seem fairly good at generating source generators so there doesn't seem to be a reason to not use them.
landl0rd: I actually really like the CLR developer experience next to java ngl. I reach for C# in lieu of java (less J2EE SingletonBeanFactoryManagerInstance slop) but particularly F# is pretty nice to use. Haskell has bad tooling, OCaml is getting better thanks to JaneStreet (and if OxCaml gets wide adoption unboxed types are a big perf win) but if nothing else lack of a Rider-esque debugger is just a big time sink.
