Comment by parliament32
3 months ago
And this sounds great until you get to the laundry list of restrictions. For us the showstopper was you can't use reflection.
3 months ago
And this sounds great until you get to the laundry list of restrictions. For us the showstopper was you can't use reflection.
You can't use reflection with AOT compilation. That's what AOT compilation is. Java has the same limitation for AOT compilation, for example.
Most reflection usage is for JSON (de)serialization and for that you can use source generators, which also offer better performance.
https://learn.microsoft.com/en-us/dotnet/standard/serializat...
These same restrictions exist for Go, the Go team just decided that it was easier to never support these features to begin with which has its pros and cons.
Such as? For the ones I've actually needed from the C# AOT limitations list, you can use reflection and dynamic loading just fine in Golang, with static single-binary compilation and all.
Golang's reflection is severely limited by design, so that there is nothing to restrict during compilation. On the other hand, you lose out on powerful tools such as C#'s System.Reflection.Emit. To note, the biggest library limited by AOT compilation, ASP.NET (which does still work with it if you design around the limitations), is being updated to work better with it (and source generators play a big part of that).
[dead]