Description
Thank you for responding to our .NET Native AOT survey (#40430)! We had over 1,400 responses. We are in the process of analyzing results and will soon start to reach out for specific follow-up. Nearly a quarter of the respondents provided their contact information. Thank you! Given the large number of responses, we will not be able to follow-up with everyone. We included some of our analysis and follow-up questions below, let’s keep the discussion happening on this thread.
Here are the raw aggregated results.
Which of the following languages do you primarily use to complete day to day work?
Follow-up questions:
- F# showed up in a number of places in the survey, what kind of F# applications would you like to use with Native AOT?
- Which characteristic or feature of another language/platform would you like to see in a Native AOT solution for .NET.
What have you done in CoreRT (experimental project)?
Follow-up questions:
- Please tell us your success or failure story if you’ve used CoreRT. We are very interested in specific stories of CoreRT’s strengths and limitations, both ones you overcame and did not.
- Were you able to get an application functionally working to your satisfaction, but didn’t deploy it in production for other reasons? If so, what were those reasons?
- What platforms (eg. x86, x64, game consoles, mobile) are you looking to target?
Overall, how satisfied or dissatisfied are you with CoreRT?
Shout out to the dotnet/corert contributors that completed the survey – thank you for your contributions.
What, if anything, do you find frustrating or unappealing about CoreRT?
Lack of official support came through loud and clear. In addition, there was significant feedback around the lack of onboarding process and the complexity of dealing with Reflection.
Follow-up questions:
- For the aspects of CoreRT that you found most challenging, how much would they need to improve for you to recommend CoreRT to someone else? Please be as specific as possible.
- Is there a comparison to another technology you could make along the lines of “I wish CoreRT was like Rust (for example) in this specific way” that would make you want to use CoreRT more?
Why do you use a native AOT technology?
Follow-up questions:
- We hear from users that some of these characteristics are 100% required and others are more nice-to-have. It would be great to see ordered listed of these characteristics (with a clear call out of the must-have ones) so that we can see clustering of high-value characteristics. Feel free to add characteristics that were not listed in the survey that are important to you.
- If you build native libraries with native AOT, is there a specific set of calling languages that you support / cater to?
Does the lack of officially supported native AOT option prevent you from using .NET more?
Because of the missing native AOT option, what environment(s) do you use instead?
If you had/have AOT as an option, which workload(s) would you want to use?
The survey contained a rich set of insight into GUI and Games development – thank you!
Follow-up questions:
- Please tell us more about the cloud scenarios you are targeting. If you are using Docker, do you value small container images? How do you achieve that? If you create cloud infrastructure components, do have specific requirements beyond what one would expect for a web application/service?
- For the games scenarios, do you just need Native AOT, or are there other parts of .NET that you would want improved to satisfy the requirements you have?
- For embedded scenarios, what are the specifications for the hardware you are targeting? Are these low resource/constrained environments?
Which GUI(s) do you work with?
Which of these tasks are a part of your production debugging workflow?
Which of the following best describes your primary role or work environment at your organization?
