Why does C# require source generators for AOT-compatible JSON serialization, whereas languages like Go manage without it?

[Egbert-Jan]

From what I understand, C# relies on reflection for JSON serialization, but reflection isn’t available in AOT compilation. That’s why we have to specify what types we want to serialise on a JSON context. However, languages like Go seem to perform JSON serialization and deserialization without needing to explicitly specify all the types at compile-time. Why is this?

I also know that Blazor, despite using reflection, has a relatively small footprint. How is this possible? What makes this approach different from AOT in C#, and why can't we achieve something similar with AOT applications?

[AustinWise]

AOT does support reflection, just not all types of reflection. This limitation comes from trimming, which is done as part of AOT compilation. It can also be done without using AOT. See docs here.

So then we can ask "why is reflection based System.Text.Json serialization incompatible with trimming and we have to source generators instead". I think this document about the original trimming design and this document about Json serializer sheds some light. In .NET 5 the .NET people were trying to make JsonSerializer compatible with trimming and AOT. But that was not the only goal; they also wanted to improve startup time and memory usage. The design they settled on to achieve this goal was Source Generation. It may be possible to write a serializer that uses reflection and is trimming & AOT compatible, but it probably would not meet the performance goals.

I don't know enough about Go or Blazor to answer the other parts of your questions. I suspect that Go is more conservative in what reflection data is keep around during linking, based on the conservatism of it's dead code elimination.