I used to contribute to a C# project aimed at Linux users[0], and one of the personally annoying aspects was requiring the .NET runtime. It's a lot like how Java programs require a JVM, except worse because OpenJDK is a blessed implementation in a way that Mono never was.
When I saw that .NET 7 included AOT, I immediately downloaded it to play around. It's clearly not fully baked (missing macOS support), but what is there is great. AOT makes C# a direct competitor to Go for projects that don't need to wring every last cycle out of the CPU, and it doesn't have the same squeamishness about language complexity that characterizes Go.
The only part of .NET 7 that really bothers me is the compilation process. I couldn't find any compile-to-obj command with flags and such, instead there's a `dotnet` command that takes its input via a monolithic `.csproj` XML file and spits out a fully-formed binary. Trying to integrate C# into a Unix-style build pipeline (make/Bazel) doesn't seem straightforward in the current SDK.
> Trying to integrate C# into a Unix-style build pipeline (make/Bazel) doesn't seem straightforward in the current SDK.
Basically, don't do that. "dotnet build" invokes "msbuild" which is a build system analogous to make. If you want a remotely peaceful life, just lay out the project the way Microsoft expect you to and let it do its thing.
You can invoke Roslyn "csc" from the command line, but some of the more obscure bits of tooling (e.g. building "self contained" executables) are only implemented as .dlls that are msbuild Task objects.
Msbuild isn't too bad once you've got over the culture shock that (a) everything is XML rather than tab-delimited makefiles and (b) you've got a glossary of terms that maps to things you know https://learn.microsoft.com/en-us/visualstudio/msbuild/msbui... and (c) you get the binary log viewer https://msbuildlog.com/, which is a fantastic tool that gives you total observability of every detail of the build process. Of which there is a lot.
Separate thought: .net AOT is still very much experimental. All sorts of things are silently incompatible with it, either in the "refuses to build" or the "crash at runtime" way. I'd only use it for small projects built from the ground up to be AOT.
It's certainly true that most things aren't AOT-compatible out of the box -- this is basically due to the heavy ecosystem reliance on reflection.
BUT, it definitely shouldn't be silently incompatible. We've spent a lot of time building "trimming warnings" (https://learn.microsoft.com/en-us/dotnet/core/deploying/trim...) that should flag any and all incompatibilities.
If there's some incompatibility, a warning should be generated. If there isn't that's likely a bug on us (https://github.com/dotnet/runtime). But conversely, if there are no warnings, you should be guaranteed that the app should be AOT-compatible.