Both "deeper dive into NativeAOT" and "MAUI team's perspective on iOS AOT" sounds good. I am using Avalonia to build an iOS app so both perspectives are valuable.
Stupid question maybe, but isn't it possible to implement some sort of flag in csproj for Text.JSON to automatically generate typeInfo classes inferring their usage from code? .NET usually written as strongly as possible, so inference shouldn't be a big problem.
The typeinfo classes could be automatically generated. The hard part is how to hook up the JsonSerializer to that generated typeinfo classes in a statically verifiable way.
1:02:38 re. taking a library and publishing it for AOT I would like to see the Sqlite library (that is written on C) as an example to publish with AOT I have a Blazor WASM app that uses a readonly Sqlite database of the KJV bible along with Hebrew transation for each word. Dont't know if this makes sense but could you have a Sqlite NativeAOT that just does SELECT
Not sure I agree about “just build on Linux because you would need infrastructure”. In Go or Zig this is trivial, so kinda embarrassing. In rust you add the target and install the infra necessary. Why can’t the dotnet workload cmdline do “setup infrastructure” for AOT scenarios? On Linux and macOS it would setup mingw and on windows it would setup gcc/clang
Why putting this effort down though? C# (a managed language) is very different from a native language. This translation into native code is absolutely non trivial.
NativeAOT supports cross-architecture compilation. Go case quickly becomes useless the moment you need platform-specific crypto, which is more often than you think, or any other OS-specific dependency. You can target NAOT at linux RIDs from under windows by using PulishAotCross nuget package, which uses Zig's build toolchain under the hood. Otherwise, you must compare this to C, C++ and Rust instead, which C#, as compiled by NativeAOT, is much spiritually closer to. It relies on platform linker, the same one your other systems programming languages use, and with the exception of Zig this is an OS-dependent build process.
Official answer RE .NET native AOT cross-compilation is at learn.microsoft.com/dotnet/core/deploying/native-aot/cross-compile The cost to build out the required feature set and infrastructure to enable this in a way that meets our requirements would be significant and unlikely to be prioritized high enough to warrant the investment.
Overkill! So many settings to know about. Is it possible to just analyze the method while coding it and warn if it is not AOT compatible and offer ways to fix it, so that most code we produce can be AOT compatible.
Why are you putting this comment here? They have been very transparent about the goal here. This is a huge accomplishment, and not because of performance. As mentioned in the beginning this has been an effort going on for 2 decades. It is a very complicated thing.
What benchmarks were you looking for? Against other languages/frameworks? I thought they were pretty open about the state of aot in aspnet core, as well as the benefits and disadvantages to using it, at least in comparison to other publishing options
I would like a deep dive into source generators
Regarding building the native libraries. - An episode on building a native library and then calling that from C++ would be awesome.
YES 100% I want to be able to use BepuPhysics from c++ so bad
would love to hear some more on Maui how it works and how and when aot can be useful for Maui
Both "deeper dive into NativeAOT" and "MAUI team's perspective on iOS AOT" sounds good. I am using Avalonia to build an iOS app so both perspectives are valuable.
btw hot tip for magnifying: Win+ESC quites it :)
.NET is getting awesome!😀
Oh nice, excited for this one!
Nice one! Can't wait for native aot for libraries. That sounds very cool
Cool something I’ll practice today!
This is awesome!
Genial, muchas gracias
Stupid question maybe, but isn't it possible to implement some sort of flag in csproj for Text.JSON to automatically generate typeInfo classes inferring their usage from code? .NET usually written as strongly as possible, so inference shouldn't be a big problem.
The typeinfo classes could be automatically generated.
The hard part is how to hook up the JsonSerializer to that generated typeinfo classes in a statically verifiable way.
Good stuff.
Oh. so Michal beats every challenge?
Hallo Michal Strehovský. I bet you can't make RAII for objects to allow allocation does not cause GC pressure. 😁
1:02:38
re. taking a library and publishing it for AOT
I would like to see the Sqlite library (that is written on C) as an example to publish with AOT
I have a Blazor WASM app that uses a readonly Sqlite database of the KJV bible along with Hebrew transation for each word. Dont't know if this makes sense but could you have a Sqlite NativeAOT that just does SELECT
Does winforms support AOT now?
🤩🤩🤩
Not sure I agree about “just build on Linux because you would need infrastructure”. In Go or Zig this is trivial, so kinda embarrassing. In rust you add the target and install the infra necessary.
Why can’t the dotnet workload cmdline do “setup infrastructure” for AOT scenarios? On Linux and macOS it would setup mingw and on windows it would setup gcc/clang
Why putting this effort down though?
C# (a managed language) is very different from a native language. This translation into native code is absolutely non trivial.
NativeAOT supports cross-architecture compilation. Go case quickly becomes useless the moment you need platform-specific crypto, which is more often than you think, or any other OS-specific dependency. You can target NAOT at linux RIDs from under windows by using PulishAotCross nuget package, which uses Zig's build toolchain under the hood.
Otherwise, you must compare this to C, C++ and Rust instead, which C#, as compiled by NativeAOT, is much spiritually closer to. It relies on platform linker, the same one your other systems programming languages use, and with the exception of Zig this is an OS-dependent build process.
Official answer RE .NET native AOT cross-compilation is at learn.microsoft.com/dotnet/core/deploying/native-aot/cross-compile
The cost to build out the required feature set and infrastructure to enable this in a way that meets our requirements would be significant and unlikely to be prioritized high enough to warrant the investment.
How about WinForms?
Try it. Enable the analyzer flag true ( called AOT-compatibility analyzers on the website) and see what it says.
They always forget WinForms like old friends and will eventually be forgotten.
I feel bad for all WinForms devs
I guess normally libraries use many Reflection. AOT was quite specifically built to address cold-start issue for serverless microservices.
Overkill! So many settings to know about. Is it possible to just analyze the method while coding it and warn if it is not AOT compatible and offer ways to fix it, so that most code we produce can be AOT compatible.
Skill issue
youtuber is afraid to benchmark aspnetcore (native aot). Because their programming language and framework will get beaten so hard. hahaha
Why are you putting this comment here? They have been very transparent about the goal here. This is a huge accomplishment, and not because of performance. As mentioned in the beginning this has been an effort going on for 2 decades. It is a very complicated thing.
Hm?
"hahaha huhiu beaten" a no brainer comment without arguments
Huh?
What benchmarks were you looking for? Against other languages/frameworks? I thought they were pretty open about the state of aot in aspnet core, as well as the benefits and disadvantages to using it, at least in comparison to other publishing options