How were you able to figure out everything to exclude and things that need to be source generated? I have an app but have not been able to work through all that yet for my aws lambda.

You are not the first to bring this up 😂

@@nickchapsas is it "Dome train" as in "get that into your thick dome"?

Its like a Golang with steroids lol

@@gordonfreimann not exactly, I don't want to go into details, but since C# is compiled to IL some optimization can be made at the start of application (this is why startup is relatively long), whereas if you have fully interpreted language like JS it is almost impossible. JIT is a bit of a different story and, yeah, it is quite similar.

​@@EzequielRegaldo Wouldn´t necessarily say so, go is from the ground up built for this. So everything it can do just works without thinking about "can this be AOT compiled". The go compiler is also crazy fast at compiling. It´s not even close in that department (like seriously the go compiler is orders of magnitude faster). Runtime I don´t know... test it for your usecase I guess. For the most part I´d expect go to edge out c#. Both c# and go are much faster than my performance requirements pretty much all the time. I did not actually end up using go for anything that I want to keep alive though. But not because I think c# is hands down better, but because it would be more friction to keep it alive when I don´t use go regularly. I have to use c# at work so I can´t exactly forget the syntax. I would with go if I don´t use it for a few month. The main thing I wanted was a smaller file size for containers. So this change is gonna do exactly that.

@@shioli3927 aot c# uses 30-40 mb, isnt huge difference

1) Is there anything we can do to make the application fail at startup time? The compiler will emit warnings if you are compiling for NativeAOT and it detects code patterns that are problematic. You can actually see just such a warning in the video (it's the big block of yellow text). If you want the compilation to fail entirely, just enable the "treat warnings as errors" feature in the project file.

@@GumbootMan thank you! This is a good practice in general, also outside of the AOT scenario

@@GumbootMan It would be great to add some attribute that would allow you to tag an assembly as AOT compatible/incompatible, so that we could see an error at compilation. Would be great for libraries that rely on reflection, or runtime compilation.

​@@nocturne6320 that's exactly how the warning systems works. Libraries that have been annotated as trimmable and had their APIs decorated with the appropriate attributes will result in analyzer based warnings at design time & compile time when the consuming project is marked for PublishTrimmed or PublishAot

No this will never happen. My courses will always be exclusive to my own platform

Just released ones

It’s does support Linux and with .NET 8 it supports MacOS too

Yes but you'll be debugging a native app at that point which is a different experience

Yes, everything into that since file

We'll take a very close look at that in the next NativeAOT video :)

@@nickchapsas Exciting!

You cannot test using the usual approaches once you've published native AOT. Typically you'll write your tests as normal with the testing framework of your preference and run those tests in non-AOT mode. How you approach automated functional testing of the native AOT app output will depend a lot on the type of project it is (web UI, web API, grpc, etc.)

@@DamianPEdwards Yes, that is what I was saying and it is a big no-no for me.

It’s native code so just like native code

You can read assembler instructions via IDA for example, but can't get source code.

You can statically link some Linux native dependencies. What native dependencies were you trying to link?

Sure just compile it for Linux. Both Windows, Linux and MacOS are supported for both x64 and ARM64

​@@KimBrusevoldTV You can actually use a docker image to build it in the docker image as well. That's how AWS allows you to build NativeAOT Lambdas form windows for Linux

I’ve been using it for 2-3 years now and I’ve been very happy with it. I sit on it for 10-18 hours a day

I can really recommend the Herman Miller Embody if you can afford it :)

Yeah you can always pass csproj parameters through the CLI.

@@nickchapsas We don't recommend that approach as the PublishAot property set in the project file will also enable the trimming and native AOT analyzers, resulting in warnings during design-time (in the editor) when you call APIs that can cause incompatibility issues with native AOT. So yes, technically possible by passing the property value as stated, but as designed it's intended to be but in your project file.

@@DamianPEdwards thanks! that's a very important clarification of the use and effect of AOT on the application design

Sure

There’s still a garbage collector in there

He says exactly that in the video. Did you even watch it?

@@drewfyre7693 Yes. I was simply addressing the clickbait in the thumbnail

It’s 10 time faster startup, not runtime like mentioned in the video.

@@nickchapsas To be fair, the thumbnail does say "10X FASTER AND SMALLER .NET APIS". 😄

@@phizc Gotta get them clicks somehow

I think there's need for real time applications, and I do believe that such low level functionnality is a step to achieve that. It's been long I have not used xslt, but I remember that the xslt processor can be extended. There may be an extension library to achieve XSLT 3.0.

It does

How do you define security here given that it’s a very broad term that could mean anything

@@nickchapsas I mean, we can't revert a code generated as AOT so easily then revert a code using JIT, there is some tools where we could revert a JIT compiled application and see the code behind it...

Because C# is not C++? It's designed to run in a runtime as managed code, with garbage collection... It's designed to be agnostic of processor architecture. Also it;s Microsoft's answer to Java and the JVM

AOT means "Ahead Of Time", the opposite of JIT "Just In Time".

@@GumbootMan Before C# came out, I had a background in C and C++. I'm not saying compiling to native code is trivial, but it isn't that hard. It's just that the mindset behind .NET has been going in another direction for reasons I never quite understood. And now changing that design to more easily compile to native code may be hard.

@@HikingUtah Right, compiling to native code isn't that hard. The JIT is doing that already, you "just" need to run that as part of the compilation process. I'm saying that's not the problem, the problem is dealing with dynamic features like runtime code generation, reflection and runtime assembly loading. These features have been there since .NET 1.0 (I'm pretty sure) so it's not really a change in direction. Of course you may argue that these features are more trouble than they're worth but MS doesn't really have the luxury of ignoring them now that they are so widely used.

AOT = Awesome Optimization Tricks

lol ok boomer

Seems like a good reason to be weaned off reflection and move on to source code generation