
.NET Team Survey: Native AOT - pjmlp
https://github.com/dotnet/runtime/issues/40430
======
moksly
I’ve been a C# developer for two (almost) decades, how do people even keep up
with these rapid changes in the post Core world and what/when to use them?
This is a serious question by the way.

~~~
jiggawatts
I've honestly given up. The new "open" development style of .NET Core is not
my cup of tea. It's now riddled with MVP features that are 80% complete, bug-
ridden, and undocumented other than couple of blog articles.

The compatibility break with the .NET Framework also removed the biggest
advantage I saw in C#, which was that any code that I wrote would "just work".
Now there's more frameworks, standards, cores, and build flags than I care to
learn, and there are all too many scenarios where it's flat impossible to do
something that was trivial before.

This is the reason, for example, that PowerShell Core is past version 7 but is
still missing many modules, including some key Microsoft ones. If they can't
figure this out, what chance do I have? Why would I bother?

Lastly, I got fed up with Microsoft releasing yet another half-baked GUI
framework. What's the latest one? MAUI? It's yet another attempt at having one
framework to rule them all, which means that it'll inevitably be the lowest
common denominator and not good at anything. Microsoft won't actually bother
making it good enough to write a flagship application in it, and they won't
write any of their own apps with it. It'll be dropped on the floor and
replaced by the next incomplete GUI framework within just a few years, mark my
words. That's if it's ever finished!

~~~
pjmlp
MAUI is Xamarin rebranded.

Even with its half broken implementations, .NET and Java are still the best
options in tooling and managed runtime capabilities.

~~~
tasogare
And it will be crap. What I want, and I'm sure a lot of other devs interested
in making C# GUI multi-platform apps, is an UI framework _à la_ Flutter that
display the same thing everywhere. In the days of Electron apps not having a
native look and feel is not a really problem anymore.

The saddest thing is that Microsoft actually offered that years before:
Silverlight Out-of-Browser applications, that where running the same on
Windows and Mac OS.

~~~
rubber_duck
Silverlight was good for it's time but nowadays I would rather code in
whatever popular JS/HTML framework - the live reload beats any C# flow hands
down in iteration time and the fact that I can just reverse proxy my local dev
env while working on something to a designer speeds up design tweaks a bunch.

~~~
pjmlp
Or just use OpenSilver, thanks WebAssembly.

[https://opensilver.net/](https://opensilver.net/)

~~~
rubber_duck
That sounds like it would make the development iteration even more terrible
than it was - WASM builds were slooow last time I tried it - with webpack in
HMR mode or flutter you get instant feedback - this is probably the biggest
productivity boost in UI development - I've yet to see anything from .NET
offer similar performance, I suspect it would be challenging due to the static
nature of IL.

------
lwansbrough
Man it would be sweet to see Unity adopt CoreRT in .NET 5 and just drop all
the C++ conversion nonsense.

Edit: interesting, someone wrote about this a couple years ago:
[https://xoofx.com/blog/2018/04/06/porting-unity-to-
coreclr](https://xoofx.com/blog/2018/04/06/porting-unity-to-coreclr)

I wonder if there’s movement on this internally at Unity.

~~~
jfkebwjsbx
Why would it be "sweet"? There is no gain for the user.

~~~
lwansbrough
I expect it would replace the need for the burst compiler, and likely reduce
the complexity of the job system (especially its need for special types.)
There is also an observed performance gain switching from IL2CPP to CoreRT,
which would be 100% free.

~~~
pjmlp
Was that performance gain proven with benchmarks across all hardware platforms
that Unity supports as deployment target?

------
Roceh
Unfortunately reflection is so widely used in .Net libraries and core
frameworks that code removal during linking becomes more or a less impossible
without spending A LONG TIME decorating an xml file with code removal
exceptions. I have done it on Xamarin iOS, it is not fun. So one of the prime
dreams of having .net AOT of having an easy way to create a COMPACT self
contained native exectuable dies when it hits real code.

Source generators may solve that going forward, but that is going to take
years to filter out to nuget library land.

There are other advantages of AOT, sure, but I think R2R that is in .Net
already covers a lot of those.

They need to solve the poor linkability of .Net code first IMO. I think
Microsoft realise that, especially if they want Blazor client side to work.

~~~
garganzol
Reflection is not "unfortunate". Actually, it is quite helpful when used
right. And there is a way to shove it with AOT.

I've tried to communicate that to some team members but got the impression
they weren't so interested in solving that. Or maybe they are reluctant to
take a solution from 3rd party, preferring to quickly come up with in-house
code instead.

Well, this would clearly cost them at least 5 years of R&D given they are able
to find the right PhDs in math and compiler theory who are able to crack that.

As for source code generators as a way to solve the reflection dilemma: they
are not going to make a dent as they tied to the specific language (C#), and
not to .NET platform as a whole. This makes them somewhat fragile and largely
fragmented in the eyes of component vendors.

~~~
jmarolf
> As for source code generators as a way to solve the reflection dilemma: they
> are not going to make a dent as they tied to the specific language (C#), and
> not to .NET platform as a whole.

Slight correction: source generators are a _compiler_ feature not a _language_
feature. This may seem like a meaningless distinction, but you can use source
generators in _any_ C# project provided your compiler is new enough. You can
easily use generators in a .NET 3.5/C# 5 project if you want.

------
kyberias
AOT = Ahead Of Time

~~~
aliswe
Phew, thanks ...

