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

Improving C# Memory Safety

devblogs.microsoft.com

Post reply on HN
Print view View original

41–47 of 47 posts

Re: Improving C# Memory Safety

#41

Post by EFLKumo »

wvenable wrote: post #32
SideburnsOfDoom wrote: post #6

> The unsafe keyword is being redesigned OK, I see a lot of C# code often and over a long time. I see the "unsafe" keyword used approximately never. I'm sure that this is useful for some cases. But not everyday things for most of us. If we did use it, it would be carefully isolated in a library for a specific purpose.

> I see the "unsafe" keyword used approximately never. The core libraries of .NET are written in C# and it's like a completely different language: https://github.com/dotnet/runtime/blob/main/src/libraries/Sy... One might not make use of it application code but these features a major part of the platform itself.

Good language has a unique flavor, and better language allows for diverse tastes and usages

Re: Improving C# Memory Safety

#42

Post by lucas_t_a »

scott01 wrote: post #34
reactordev wrote: post #30

Earlier quoted context omitted.

This is why C# is superior to C++ for game development (not the graphics low level, but the game play higher level). Being able to use Events, ECS, Reflection, Dynamic code is a god send. I have written game engines in C# and I still find myself defaulting to it anytime I think about Vulkan. I even published my own bindings for it. The best thing about .Net unfortunately is also one of its worst. The deployment and p…

I respectfully disagree — a lot of conveniences that C# provides produce GC trash which will cause frame spikes. I remember having had to add a non-allocation string.contains alternative at one project. Lambdas and linq also have this problem, or if a string is passed through native-c# boundary. Language itself is really nice though :)

C# is too much of a you hold it wrong language, you can easily avoid the problem you describe, but it is such a pain, i do like the fact that the language constantly improves in all directions so it definitely does not remove its positive sides when you do a thing in the right way

Re: Improving C# Memory Safety

#44

Post by pjmlp »

EFLKumo wrote: post #40
pjmlp wrote: post #5

Earlier quoted context omitted.

One can only hope. C++/WinRT is in maintenance, and you will notice the WinUI 3.0 does most of their demos, and gallery with C#.

In terms of XAML UI, C++/WinRT struggles. When it was released, C++ just lacked good reflection methods, and many practices that were easily achieved in C#, such as MVVM, data bindings, were difficult to migrate. I think this prevented C++ from re-entering modern Windows development practices.

On the contrary, C++/CX was (still is) a great development experience, for the very first time, Microsoft hat something that could rival C++ Builder.

Instead an small group rioted, came up with C++/WinRT with support from management and complete disrespect for paying customers.

Now a decade later, C++/WinRT in in maintenance, the roadmap vision shown at CppCon 2017 unfulfilled, and the same team is now having fun with Rust in windows-rs.

> This isn't meant as a negative statement. cppwinrt has reached all of its goals and is generally considered complete and largely bug-free (1). Whether WinRT/WinUI/WinAppSDK is the future is debatable. My experience has shown me that the Windows operating system is at its best when you embrace the Windows API as a whole, including Win32/COM/WinRT, and not just the latest shiny wave. You can see this in action with the popularity of projects like win32metadata and windows-rs that support both WinRT and non-WinRT APIs seamlessly.

Quote from the devs on Github.

Thanks for nothing, I guess.

Re: Improving C# Memory Safety

#45

Post by EFLKumo »

pjmlp wrote: post #44
EFLKumo wrote: post #40

Earlier quoted context omitted.

In terms of XAML UI, C++/WinRT struggles. When it was released, C++ just lacked good reflection methods, and many practices that were easily achieved in C#, such as MVVM, data bindings, were difficult to migrate. I think this prevented C++ from re-entering modern Windows development practices.

On the contrary, C++/CX was (still is) a great development experience, for the very first time, Microsoft hat something that could rival C++ Builder. Instead an small group rioted, came up with C++/WinRT with support from management and complete disrespect for paying customers. Now a decade later, C++/WinRT in in maintenance, the roadmap vision shown at CppCon 2017 unfulfilled, and the same team is now having fun wit…

Making a XAML UI is fundamentally authoring a WinRT interface, I guess. And for cppwinrt, Microsoft's solution is like describing in so-called MIDL .idl files, compiler generating cpp stubs, copying these stubs and filling in implementations. After static reflection introduced in cpp idk if this process could become better, but Microsoft just left cppwinrt in maintenance mode, it's impossible I guess.

On the Rust side, IMO the windows-rs even has not thought about authoring new com interfaces, only consuming or impl-ing existing ones. In fact the experience of consuming windows apis in rust feels good if one would like to get rid of C++. Rust with NAPI or BoltFFI etc. offers an maintaining-friendly option for cross-platform app authors to interact with the OS more deeply. So in conclusion the situation right now is that windows apis just become not so unapproachable, while in-depth things keeping comfortable only with C# or .NET.

Re: Improving C# Memory Safety

#47

Post by northlondoner »

SideburnsOfDoom wrote: post #6

> The unsafe keyword is being redesigned OK, I see a lot of C# code often and over a long time. I see the "unsafe" keyword used approximately never. I'm sure that this is useful for some cases. But not everyday things for most of us. If we did use it, it would be carefully isolated in a library for a specific purpose.

Compiler will enforce this. You won't be able to build without `unsafe` keyword. AFAIU.
Post reply on HN