I love (and heavily use) source generators, but the development experience is godawful. Working with the raw Roslyn types is painful at best and this is compounded by them having to be written against .NET Standard, severely limiting the use of newer .NET functionality.

Eventually I want to write a good baseline library to use for my source generators -- simplifying finding definitions with attributes, mapping types to System.Type, adding some basic pattern matching for structures -- but haven't found a way to do it that's general enough while being very useful.

It's a lot less ergonomic but there are source generators in C# :

https://devblogs.microsoft.com/dotnet/introducing-c-source-g...

That said, for more complex results, you'd typically load a serialization on start.

I can see the value in this tool, but there must be a fairly limited niche which is too expensive to just have as static and run on start-up and cache, but not so large you'd prefer to just serialize, store and load.

It also needs to be something that is dynamic at compile time but not at runtime.

So it's very niche, but it's an interesting take on the concept, and it looks easier to use than the default source generators.

D was already doing it in 2010 thereabouts, an then there is the whole reader macros in Lisp and Scheme.

A key difference is that in this C# package, `[Comptime]` is an attribute (annotation? not sure on the C# term) applied to methods. In Zig, the `comptime` keyword can be applied to pretty much any expression. In the C# package, if you want to do factorial at runtime and at compile time, (I think, from reading the README) you need to define the same function twice, one with `[Comptime]` and once without. Contrast this to Zig, where if you have a regular runtime factorial function, you can just execute it at compile time like:

    const x = comptime factorial(n);

Another limitation of the C# package is it only works with primitive types and collections. Zig comptime works on any arbitrary types.

There's also Nim, it shines even more in compile time and has proper compile time macros :)

Boo and Nemerle both were really showing what was possible in .NET back in the early days. I still miss the metaprogramming they had, not to mention their pattern matching (which C# has closed the gap on, but is still way, way short.)