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

31–40 of 47 posts

Re: Improving C# Memory Safety

#31

Post by ameliaquining »

masklinn wrote: post #23
caspper69 wrote: post #13

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…

> 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. Since they state outright that they're not going for a borrow checker, I would assume they're going for "second class references": the borrow checker is both powerful and complicated because refe…

C# already has second-class references; this is essentially what the ref keyword does. It's actually a bit more expressive than what Hoare suggests he'd have done (you can return ref structs and you can store them in other ref structs), but it doesn't have full-blown Rust-style lifetime annotations.

Re: Improving C# Memory Safety

#32

Post by wvenable »

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.

Re: Improving C# Memory Safety

#33

Post by pjmlp »

gertlabs wrote: post #18

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

Google is mainly a user of Java, Kotlin, Python and C++.

Go might be have been created by three Google employees, two of which UNIX idols, but the language isn't that widely deployment outside anything to do with Kubernetes.

See how much Go related content shows at Google IO. If I am not mistaken, it got a single talk this year.

Re: Improving C# Memory Safety

#34

Post by scott01 »

reactordev wrote: post #30
gertlabs wrote: post #18

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

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 :)

Re: Improving C# Memory Safety

#35

Post by reactordev »

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 :)

I think you need to revisit your biases

Re: Improving C# Memory Safety

#36

Post by benol »

pjmlp wrote: post #33
gertlabs wrote: post #18

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

Google is mainly a user of Java, Kotlin, Python and C++. Go might be have been created by three Google employees, two of which UNIX idols, but the language isn't that widely deployment outside anything to do with Kubernetes. See how much Go related content shows at Google IO. If I am not mistaken, it got a single talk this year.

It's widely used in Cloud. Within Cloud you there is a policy to use it for all new products.

Re: Improving C# Memory Safety

#37

Post by EFLKumo »

pjmlp wrote: post #33
gertlabs wrote: post #18

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

Google is mainly a user of Java, Kotlin, Python and C++. Go might be have been created by three Google employees, two of which UNIX idols, but the language isn't that widely deployment outside anything to do with Kubernetes. See how much Go related content shows at Google IO. If I am not mistaken, it got a single talk this year.

Go is actually widely adopted in web backends and desktop apps. You might just miss some scenarios. And from my naive perspective, Go is a strong type alternative than TypeScript though it has a unique idiom syntax, but for most web devs this could be a reason to adopt Go, e.g. Wails instead of Electron in desktop.

Re: Improving C# Memory Safety

#38

Post by pjmlp »

benol wrote: post #36
pjmlp wrote: post #33

Earlier quoted context omitted.

Google is mainly a user of Java, Kotlin, Python and C++. Go might be have been created by three Google employees, two of which UNIX idols, but the language isn't that widely deployment outside anything to do with Kubernetes. See how much Go related content shows at Google IO. If I am not mistaken, it got a single talk this year.

It's widely used in Cloud. Within Cloud you there is a policy to use it for all new products.

It certainly isn't reflected on Google IO cloud product talks, though, unless it is something directly related to Kubernetes.

Re: Improving C# Memory Safety

#39

Post by pjmlp »

EFLKumo wrote: post #37
pjmlp wrote: post #33

Earlier quoted context omitted.

Google is mainly a user of Java, Kotlin, Python and C++. Go might be have been created by three Google employees, two of which UNIX idols, but the language isn't that widely deployment outside anything to do with Kubernetes. See how much Go related content shows at Google IO. If I am not mistaken, it got a single talk this year.

Go is actually widely adopted in web backends and desktop apps. You might just miss some scenarios. And from my naive perspective, Go is a strong type alternative than TypeScript though it has a unique idiom syntax, but for most web devs this could be a reason to adopt Go, e.g. Wails instead of Electron in desktop.

Outside Google, yes I guess.

Well I for one, think that using node, Python, Ruby on the backend is an anti pattern anyway.

And I certainly don't want to use a language that makes me feel like coding in Java 5, that was 20 years ago.

Re: Improving C# Memory Safety

#40

Post by EFLKumo »

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

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.
Post reply on HN