8 ms·
We've been experimenting with NativeAOT for years with ASP.NET Core (which does runtime code generation all over the place). The most promising prototypes thus
by davidfowl 4y ago
We've been experimenting with NativeAOT for years with ASP.NET Core (which does runtime code generation all over the place). The most promising prototypes thus far are:
- https://github.com/davidfowl/FasterActions https://github.com/davidfowl/FasterActions
- https://github.com/davidfowl/uController https://github.com/davidfowl/uController
They are source generated version of what ASP.NET does today (in both MVC and minimal APIs). There are some ergonomic challenges with source generators that we'll likely be working through over the coming years so don't expect magic. Also its highly unlikely that ASP.NET Core will not depend on any form of reflection. Luckily, "statically described" reflection generally works fine with NativeAOT.
Things like configuration binding, DI, Logging, MVC, JSON serialization all rely on some form of reflection today and it will be non-trivial to remove all of it but we can get pretty far with NativeAOT if we accept some of the constraints.
As of right now, we're trying to make sure "motivated people" can play with it, but it's not something that is supported by ASP.NET Core or EF at the moment.
https://github.com/dotnet/aspnetcore/pulls?q=is%3Apr+nativeaot+is%3Aclosed https://github.com/dotnet/aspnetcore/pulls?q=is%3Apr+nativea...
PS: Some of the challenges https://github.com/dotnet/aspnetcore/issues/42221 https://github.com/dotnet/aspnetcore/issues/42221
- merb 4y agoActually system text json does work with source generators and di can work with source Generators aswell.
- davidfowl 4y agoThanks for telling me :). On a serious note though, anything can work with source generators but it doesn't match the style of coding that we'd like (moving everything to be declarative isn't the path we want to go down for certain APIs). Also source generators don't compose, so any source generation that we would want to use would need to take advantage of the JSON source generator (if we wanted to keep things NativeAOT safe). Right now most of the APIs you use in ASP.NET Core are imperative and source generators cannot change the callsite so you need to resort to method declarations and attributes everywhere. That's not an optimization, that's a programming model change.
- merb 4y agoWell in system text json the api keeps the same and you „only“ need to pass an autogenerated meta object its basically the same api you just need to pass another object instead of an generic Parameter. But yeah its a change.
- to11mtm 4y ago> Also source generators don't compose, so any source generation that we would want to use would need to take advantage of the JSON source generator This is the biggest challenge I see, there are times where either Expression.Compile or T4 still 'feels' cleaner than sourcegen.
- jeremycarter 4y agoThanks for your hard work with the .NET community David.
- davidfowl 4y agoThanks for using .NET!
- dyml 4y agoIt’s incredibly exciting to follow your work and the teams! Thank you!