Live data from Hacker News

.NET Team Survey: Native AOT

github.com

81–90 of 103 posts

Re: .NET Team Survey: Native AOT

#81
post #38

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…

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…

> 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.

Re: .NET Team Survey: Native AOT

#82
post #20

Earlier quoted context omitted.

C# has long supported it on UWP side, but now with .NET 5 there is an ongoing discussion if they will still support it or not. The whole MDIL (Windows 8/8.1) and .NET Native (Windows 10) came from WinDev, not DevDiv, hence why it has its own idiosyncratics regarding .NET support. Now with .NET 5, it seems they are gearing towards just a better NGEN, thus shipping a kind of AOT/JIT mixed mode image, which isn't being…

Interesting, they are removing WinRT support from .NET 5 CoreCLR and instead adding a system that lets the Windows team plug in the marshaling stuff: https://github.com/dotnet/runtime/issues/35318 coreclr.dll is currently half a megabyte smaller than the 3.1 release.

It is based on the same ideas as C++/WinRT, which I am still bitter about, because it represents a productivity drop versus C++/CX as the ones pushing for it are hoping that ISO C++23 eventually gets the features that enables the VS tooling with C++/CX today.

So you are back to manually copying files around and writing IDL files with Notepad like experience as if using ATL style development in 2020.

Most likely C#/WinRT seems to follow the same fate in productivity drop.

Re: .NET Team Survey: Native AOT

#83
post #57
post #2

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.

Keep in mind that, although I partially agree with you, other platforms are way-worse than .NET. think about nodejs mess and client-side ecosystem, where things break almost at any minor release. Dev world is going fast, and I think that the choice for .NET is to embrace change or die as an old platform. My2Cents.

Your comment about the JavaScript client side ecosystem is fair, and I could even provide numerous examples of libraries introducing breaking api changes in minor releases.

However it is unfair and simply untrue to somehow also tar nodejs with that brush. Upgrading a nodejs project by a major version usually never needs any code changes

Re: .NET Team Survey: Native AOT

#84
post #68

Earlier quoted context omitted.

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.

Or just use OpenSilver, thanks WebAssembly. https://opensilver.net/

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.

Re: .NET Team Survey: Native AOT

#85
post #2

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.

> how do people even keep up with these rapid changes in the post Core world and what/when to use them? You wished that the dev world moved slower. Sorry, things move fast nowadays. The .NET team decided to stay relevant, by moving fast to keep up. That's just how it is.

As a desktop developer I really miss the Big Bang releases and slow pace yes. We are doing a 2-year transition between 4.7.1 and 4.7.2 now! What goes on beyond that is just a fog. Some of our third party dependencies are probably never going to be ported core while many others are starting to lose maintenance on netfx. Being in the position of having to maintain a netfx desktop app for the coming 10-20 years is looking bleak.

Re: .NET Team Survey: Native AOT

#86

Earlier quoted context omitted.

> how do people even keep up with these rapid changes in the post Core world and what/when to use them? You wished that the dev world moved slower. Sorry, things move fast nowadays. The .NET team decided to stay relevant, by moving fast to keep up. That's just how it is.

As a desktop developer I really miss the Big Bang releases and slow pace yes. We are doing a 2-year transition between 4.7.1 and 4.7.2 now! What goes on beyond that is just a fog. Some of our third party dependencies are probably never going to be ported core while many others are starting to lose maintenance on netfx. Being in the position of having to maintain a netfx desktop app for the coming 10-20 years is looki…

Then stay on the LTS releases. They come roughly annually.

Re: .NET Team Survey: Native AOT

#87

Earlier quoted context omitted.

As a desktop developer I really miss the Big Bang releases and slow pace yes. We are doing a 2-year transition between 4.7.1 and 4.7.2 now! What goes on beyond that is just a fog. Some of our third party dependencies are probably never going to be ported core while many others are starting to lose maintenance on netfx. Being in the position of having to maintain a netfx desktop app for the coming 10-20 years is looki…

Then stay on the LTS releases. They come roughly annually.

Starting with .Net 5, there will be one major release exactly once a year, and one LTS release exactly once every two years.

(see https://devblogs.microsoft.com/dotnet/introducing-net-5/)

Re: .NET Team Survey: Native AOT

#88
post #21

Earlier quoted context omitted.

The whole point of .NET Core is to bundle the framework with the application.

I thought the whole point was to become cross platform. You can install the runtime on its own. Bundling an application and the framework isn't a requirement.

Or maybe there isn't a single "the whole point" and it can be useful for different reasons to different people?

Re: .NET Team Survey: Native AOT

#89
post #87

Earlier quoted context omitted.

Then stay on the LTS releases. They come roughly annually.

Starting with .Net 5, there will be one major release exactly once a year, and one LTS release exactly once every two years. (see https://devblogs.microsoft.com/dotnet/introducing-net-5/ )

.NET 5 is a no go for those of us who are stuck on netfx. There is no compatibility.

Re: .NET Team Survey: Native AOT

#90

Earlier quoted context omitted.

As a desktop developer I really miss the Big Bang releases and slow pace yes. We are doing a 2-year transition between 4.7.1 and 4.7.2 now! What goes on beyond that is just a fog. Some of our third party dependencies are probably never going to be ported core while many others are starting to lose maintenance on netfx. Being in the position of having to maintain a netfx desktop app for the coming 10-20 years is looki…

Then stay on the LTS releases. They come roughly annually.

The problem isn’t the framework so much as libraries and their dependencies. A required update to one library might require a bump in a second library and that library drops netfx support and supports only core/net5 in that bumped version. Stuck between a rock and a hard place.
Post reply on HN