Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

.NET Team Survey: Native AOT

github.com

Post reply on HN
Print view View original

61–70 of 103 posts

Re: .NET Team Survey: Native AOT

#61

Post by josteink »

goto11 wrote: post #59
josteink wrote: post #52

Earlier quoted context omitted.

> And now we have a disaster which will dwarf the python 2/3 conundrum. Given that Python 3 has been around for 12 years now, and still doesn't have universal adoption, I kinda doubt this is going to be near as bad a migration as that was. At least .NET 5 will have compatible string-types once you've upgraded your projects :)

> Given that Python 3 has been around for 12 years now, and still doesn't have universal adoption, I kinda doubt this is going to be near as bad a migration as that was. Given that .net is much more entrenched than Python was 12 years ago, I think it going to take a lot longer! Frameworks like WebForms and WCF will not be ported, so projects depending on these will require massive rewrites. This a lot more work than…

> Frameworks like WebForms and WCF not be ported

WebForms is terrible and I see no reason for anyone to pull that monstrosity of a "I wish we had a VB/Windows WYSIWYG app-editor for the web" impedance-mismatch into a new codebase.

Applications which haven't migrated off WebForms yet, probably have little to gain by moving to .NET Core anyway.

WCF has been open-sourced[1] and ported (at least the client libraries) and you have separate community-projects[2] working on porting the rest of the stack to be compatible and usable with .NET Core.

If the community really want's to go full WCF on the new stack, they are empowered to do so.

[1] https://github.com/dotnet/wcf

[2] https://github.com/CoreWCF/CoreWCF

Re: .NET Team Survey: Native AOT

#62

Post by goto11 »

josteink wrote: post #61
goto11 wrote: post #59

Earlier quoted context omitted.

> Given that Python 3 has been around for 12 years now, and still doesn't have universal adoption, I kinda doubt this is going to be near as bad a migration as that was. Given that .net is much more entrenched than Python was 12 years ago, I think it going to take a lot longer! Frameworks like WebForms and WCF will not be ported, so projects depending on these will require massive rewrites. This a lot more work than…

> Frameworks like WebForms and WCF not be ported WebForms is terrible and I see no reason for anyone to pull that monstrosity of a "I wish we had a VB/Windows WYSIWYG app-editor for the web" impedance-mismatch into a new codebase. Applications which haven't migrated off WebForms yet, probably have little to gain by moving to .NET Core anyway. WCF has been open-sourced[1] and ported (at least the client libraries) and…

> WebForms is terrible

Sure, but that is beside the point. You don't make legacy code disappear just by wishing it away.

Re: .NET Team Survey: Native AOT

#63

Post by ta17711771 »

ptx wrote: post #31
josteink wrote: post #28

Earlier quoted context omitted.

You are allowed to change your mind, aren't you? :) The goal for the initial .NET Core project was to have something cross-platform, modular and lightweight to build Linux-deployable cloud-services with. Once that reached a mature state, they could expand scope. And now, after .NET Core 3.x has landed, it has matured so much, that MS can see one single unified path forward which also includes some things which previo…

Right, but I think the complaint was that it was still immature and missing some use-cases covered by the old framework. Anyway, I do hope they succeed and the .NET 5 unification goes smoothly. I want those C# 9 features - but I also need some old third-party libraries to keep working.

Which ones, if you don't mind me asking out of curiosity?

Re: .NET Team Survey: Native AOT

#64

Post by lwansbrough »

jfkebwjsbx wrote: post #42
lwansbrough wrote: post #26

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 I wonder if there’s movement on this internally at Unity.

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

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.

Re: .NET Team Survey: Native AOT

#65

Post by rubber_duck »

tasogare wrote: post #27
pjmlp wrote: post #10

Earlier quoted context omitted.

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

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…

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.

Re: .NET Team Survey: Native AOT

#66

Post by lwansbrough »

pjmlp wrote: post #56
lwansbrough wrote: post #26

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 I wonder if there’s movement on this internally at Unity.

Why should they, IL2CPP and Burst compilers is able to do C++ like optimizations that .NET is still far from being able to (they have actually two nowadays). .NET 5 also doesn't run in all platforms that Unity targets. Rich ecosystems only have to gain from multiple implementations.

> IL2CPP and Burst compilers is able to do C++ like optimizations that .NET is still far from being able to

This is a discussion about .NET AOT (CoreRT) which has been observed to have a considerable performance benefit over IL2CPP/burst (see the attached blog post in my original comment)

> .NET 5 also doesn't run in all platforms that Unity targets.

CoreRT supports C++ codegen, so in the worst case you can use that. But its first class platform support is growing. Though I suspect even then you may see some platform support differences but those can be ironed out. Given the benefits of switching to .NET CoreRT I suspect it would be worthwhile.

Re: .NET Team Survey: Native AOT

#67

Post by pjmlp »

lwansbrough wrote: post #66
pjmlp wrote: post #56

Earlier quoted context omitted.

Why should they, IL2CPP and Burst compilers is able to do C++ like optimizations that .NET is still far from being able to (they have actually two nowadays). .NET 5 also doesn't run in all platforms that Unity targets. Rich ecosystems only have to gain from multiple implementations.

> IL2CPP and Burst compilers is able to do C++ like optimizations that .NET is still far from being able to This is a discussion about .NET AOT (CoreRT) which has been observed to have a considerable performance benefit over IL2CPP/burst (see the attached blog post in my original comment) > .NET 5 also doesn't run in all platforms that Unity targets. CoreRT supports C++ codegen, so in the worst case you can use that.…

I doubt it, given that Burst does optimizations, with a constrained C# subset tailored for replacing lower Unity layers previously written in C++, and is already being used in production.

CoreRT is still a preview tech that has to deal with the full capabilities of .NET Framework, including VB.NET, C#, F# and C++/CLI as generators of MSIL bytecode.

Re: .NET Team Survey: Native AOT

#68

Post by pjmlp »

rubber_duck wrote: post #65
tasogare wrote: post #27

Earlier quoted context omitted.

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…

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/

Re: .NET Team Survey: Native AOT

#69

Post by pjmlp »

lwansbrough wrote: post #64
jfkebwjsbx wrote: post #42

Earlier quoted context omitted.

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

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.

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

Re: .NET Team Survey: Native AOT

#70

Post by headmelted »

tasogare wrote: post #27
pjmlp wrote: post #10

Earlier quoted context omitted.

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

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…

What you’ve just described is absolutely the opposite of what I want.

Mobile apps have very different requirements than desktop apps, not least as the metaphors are wildly different.

macOS, Windows and X all have fairly similar window layouts and behaviours.

iOS and Android have sharply different layouts and behaviours. Yeah there’s a bit of overlap now, but even navigation is different.

Post reply on HN