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

11–20 of 47 posts

Re: Improving C# Memory Safety

#11

Post by zmj »

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.

There are standard library APIs that let you do memory-unsafe things without the unsafe keyword (CollectionsMarshal, MemoryMarshal). They're useful, but the burden is on the caller to uphold the invariants. This proposal seems aimed at making that kind of contract more explicit and obvious.

Re: Improving C# Memory Safety

#12

Post by pixl97 »

tialaramex wrote: post #8
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.

This moves C# to a more modern systematic understanding of what this keyword is for, but it'll remain very rare in C# the same way it's rare in Rust, and presumably in Swift. The choice of keyword "unsafe" is partly psychological. Turns out if you called this exact same feature "trusted" or whatever the programmers don't have the appropriate feelings about it. They want to write trusted code, they don't want to write…

Initialize liveHandgrenade;

Re: Improving C# Memory Safety

#13

Post by caspper69 »

They are aligning more closely with the Rust 2024 model for unsafety, which requires inner annotations at the point of unsafety in addition to notation of the function (unless it is the safe-unsafe boundary) plus it imposes a requirement for a SAFETY doc notation for describing the specific invariants the caller must enforce to uphold the safety guarantees. Not terribly onerous in my opinion. I maintain a few native library wrappers on nuget, so I will have to do some updates around IntPtr usage, but this doesn’t seem like it will be terribly painful in my case. Thankfully I don’t do much marshalling. Plus you get a nifty badge on nuget for making your library safe.

The blurb toward the end about Rent/return makes me a bit nervous though. They say they’re not going full borrow checker, but rent at least sounds an awful lot like borrow to me. Details were basically non-existent though.

I guess I wonder what the end game is here though. The more they make C# like Rust with a GC, the less incentive people have to use C# except maybe to support legacy work. I am still far more comfortable in C# than Rust, and I believe C# is superior for e.g. web, but over time this advantage could be lessened quite a bit as the Rust ecosystem continues to grow.

Re: Improving C# Memory Safety

#14

Post by Profan »

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.

In a game development context, especially where C++ interop is involved and a lot of code lives across a boundary where memory is owned by C++ but you want to avoid/minimize marshaling overhead or just generally maximize performance, the unsafe keyword is quite handy, but outside of those you can indeed probably get around by approximately never using it.

There's a lot of power C# gives you if carefully curated, making a lot of cases where people previously might have seen C++ as the only option as suddenly quite viable.

... See also the somewhat arcane Unsafe.As etc APIs

Re: Improving C# Memory Safety

#15

Post by caspper69 »

Quothling wrote: post #10
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.

Around here C# is only really used at stagnant middle sized companies with horrible code bases. The sort where the company follow Uncle Bob religiously, while completely misunderstanding everything Uncle Bob ever said. Doesn't mean the language (and it's runtime) can't be good.

Yes, many people instinctively stay away from anything microsoft (except github, typescript and npm). But the stack is solid. I’m always reminded of Stack Overflow and how they built on asp.net and like 7 servers and it scaled very well for years.

Everyone has what they like and what they’re familiar with, and for better or worse, especially for startups it’s rarely .net. But I couldn’t imagine e.g. using js instead on the back end, but that’s just me.

Re: Improving C# Memory Safety

#16

Post by moomin »

pjmlp wrote: post #5
moomin wrote: post #4

Earlier quoted context omitted.

The Windows team is talking to DevDiv again? Satan's putting on his ice skates right now.

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

It would be nice if any display API actually covered the entire API with the exception of the actual OS API…

Re: Improving C# Memory Safety

#17

Post by Weebs »

pjmlp wrote: post #7
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.

Many of us use it in scenarios where others would write a blog post about a rewrite in Rust, C++ or whatever. CLR was designed to support languages like C++, yet many don't learn the knobs.

Any lesser known knobs one should know? I'm considering a .NET backend for my compiler

Re: Improving C# Memory Safety

#18

Post by gertlabs »

C# is one of the best languages we evaluated for LLM problem solving. In fact, many strongly typed, lower level languages perform well in our testing (this isn't to say that the solutions are more maintainable, but the LLMs come up with better ideas when writing C# or Rust than Python). Google models especially, for whatever reason, outperform in C#, not Golang.

Data at https://gertlabs.com/rankings?provider=google

Re: Improving C# Memory Safety

#19

Post by Weebs »

caspper69 wrote: post #15
Quothling wrote: post #10

Earlier quoted context omitted.

Around here C# is only really used at stagnant middle sized companies with horrible code bases. The sort where the company follow Uncle Bob religiously, while completely misunderstanding everything Uncle Bob ever said. Doesn't mean the language (and it's runtime) can't be good.

Yes, many people instinctively stay away from anything microsoft (except github, typescript and npm). But the stack is solid. I’m always reminded of Stack Overflow and how they built on asp.net and like 7 servers and it scaled very well for years. Everyone has what they like and what they’re familiar with, and for better or worse, especially for startups it’s rarely .net. But I couldn’t imagine e.g. using js instead…

A VM with good FFI and structs is pretty unique and all of the tooling around .NET is excellent

F# is a sleeping giant of capability in the FP/ML space, being able to use a lot of the existing tooling

People rightfully point out how it's sort of second class in comparison to C# at times, but its still A tier tooling that few languages have

Post reply on HN