News

Microsoft Survey: Developers Held Back by Lack of 'Native AOT' in .NET Core

• By David Ramel
• 08/31/2020

Lack of native ahead-of-time (AOT) compilation in .NET Core is a sore spot for Microsoft, which just published results of a survey indicating this missing option is holding developers back from using the framework more.

The survey followed numerous complaints from developers, some coming in the comments section about recent .NET 5 preview releases.

Previous to these preview releases, Microsoft, in announcing the upcoming .NET 5, had said: "The default experience for most .NET 5 workloads will be using the JIT-based CoreCLR runtime. The two notable exceptions are iOS and client-side Blazor (web assembly) since both require ahead-of-time (AOT) native compilation."

For an example of the complaints about that strategy, in the comments section of July's Preview 7 announcement, a developer said:

Your team cannot be trusted, you kept being evasive/ignoring questions related to AOT, then you finally spoke with .NET 5 preview 5 saying we'll hear more about AOT for preview 7, here is preview 7 and not a single word about AOT.

In response to such comments, Microsoft conducted a survey on native AOT to get the full story, and published the results last week. One of the questions asked "Does the lack of officially supported native AOT option prevent you from using .NET more?" Among the five answers to that question, the one picked by the largest percentage of developers (35 percent) was: "I would like to write more projects in .NET, but am not able to due to missing native AOT option."

Note that in the context of this survey, "native AOT" has a specific meaning. As Microsoft said in announcing the recent Preview 8:

We've seen a lot of comments on previous preview posts asking about the relationship between single file apps and ahead of time (AOT) compilation. AOT is a spectrum. The ready-to-run code that dotnet publish generates (when you set PublishReadyToRun to true) is an example of AOT. When you publish ready-to-run images, the build generates machine code for you, ahead of time, instead of the JIT doing it at runtime. Most people will likely accept this as a definition of AOT. However, many people mean something more specific when they say AOT. They want a solution that has the following characteristics: extremely fast startup, no IL present (for size and obfuscation reasons), a JIT is (at most) optional, and binary size is as small as it can be. We use the term 'native AOT' to describe that point on the AOT spectrum. The single file solution we have in .NET 5.0 doesn't satisfy this definition of AOT. It's a big step forward, but it isn't 'native AOT'. We recently published a survey on Native AOT to get more feedback on that modality. We're looking through the results now and will include them in our 6.0 planning effort.

Those results, numbering more than 1,400 responses, are presented in the Survey: Native AOT [results] GitHub issue.

The survey also asked developers about the experimental .NET Foundation project, CoreRT, a repo that contains the .NET Core runtime optimized for AOT. That project is right upfront in saying: "This is an experimental project. We have no plans to productize it in its current form. More details in CoreRT future plans."

The survey said 439 respondents had tried compiling a .NET application using the CoreRT toolchain. When asked "Overall, how satisfied or dissatisfied are you with CoreRT?" 38 percent of respondents said they were neither satisfied nor dissatisfied, while 36 percent said they were satisfied.

"Lack of official support came through loud and clear," Microsoft said in the post.

Other highlights of the survey results include:

• "Because of the missing native AOT option, what environment(s) do you use instead?" -- Go/golang and Rust were among the top answers, followed by a whole bunch of others.

  

• "Why do you use a native AOT technology?" -- Fast startup time was No. 1, followed by "size of the executable."
• "If you had/have AOT as an option, which workload(s) would you want to use?" -- Command-line tools was the No. 1 answer to this question, followed by GUI and ASP.NET.
• "Which GUI(s) do you work with?" -- WPF, WinForms and Xamarin were the top three responses.
• "Which of the following languages do you primarily use to complete day to day work?" -- This was overwhelmingly C#, followed by C/C++ in a distant second place, after which Go, F# and Rust were pretty closely grouped together in subsequent responses.

While it remains to be seen if CoreRT will emerge as an officially supported native AOT option, those aforementioned "CoreRT future plans" are still being commented on.

One of the most recent comments -- posted before the survey results were released -- reads: "When are we getting results for this survey? I want to use CoreRT in my project, but due to not having official support for it, I didn't get approval for using CoreRT."