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

Rust panics under the hood, and implementing them in .NET

fractalfir.github.io

Post reply on HN
Print view View original

71–80 of 83 posts

Re: Rust panics under the hood, and implementing them in .NET

#71

Post by neonsunset »

orf wrote: post #61
neonsunset wrote: post #55

Earlier quoted context omitted.

FWIW .NET has many alternatives to popular Rust packages. Features provided by Rayon come out of box - it's your Parallel.For/Each/Async and arr.AsParallel().Select(...), etc. Their cost is going to be different, but I consistently find TPL providing pretty fool-proof underlying heuristics to make sure even and optimal load distrbituion. Rayon is likely going to be cheaper on fine-grained work items, but for coarse g…

> but C# can never take a such change because it would be massively breaking Out of interest, why?

Unfortunately there is no short answer to this. But the main gist is that improving this to take advantage of all the underlying type system and compiler features would require a new API for LINQ, improvements for generic signature inference in C# (and possibly Rust-like associated types support), and introducing a similar new API to replace regular delegates, used by lambdas, anonymous functions, etc. with "value delegates" dispatched by generic argument to methods accepting them, with possibly a lifetime restriction of 'allows ref struct' which is a new feature that clarifies that a T may be a ref struct and is not allowed to be boxed, as it can contain stack references or references to a scope that would be violated by moving to heap.

There have been many projects to improve this like https://github.com/dubiousconst282/DistIL and community libraries that reimplement LINQ with structs and full monomorphization, but the nature of most projects written in C# means their developers usually are not interested or do not need the zero-cost-like abstractions, which limits the adoption, and for C# itself it would need to evolve, and willingly accept a complete copy of existing APIs in LINQ with new semantics, which is considered, and I agree, a bad tradeoff where the simpler cases can be eventually handled through compiler improvements, especially now that escape analysis is back on the menu.

Which is why, in order to "properly" provide Rust-like cost model of abstractions as the first-class citizen, only a new language that targets .NET would be able to do so. Alternatively, F# too has more leeway in what it compiles its inferred types to, but its a small team and as a language F# has different priorities as far as I know.

Re: Rust panics under the hood, and implementing them in .NET

#72

Post by giancarlostoro »

bangaladore wrote: post #51
giancarlostoro wrote: post #12

Earlier quoted context omitted.

What I think you missed in that statement is that the code is technically still Rust safe, so in theory it wouldn't just be unsafe .NET Code, it would be Rust safe code that happens to run on .NET with a speed up since its less managed. It's kind of genius, if I'm not misunderstanding.

If you go through the hassle of integrating this, you would be better off manually optimizing your C# code to reduce GC allocations, which you can do within the safe subset of C#. This is not targetted towards increasing performance as it seems the entirety of the rust application gets converted to IL, incurring large performance hits across the board. If you do not want JITing, you can already "pre-compile" dotnet c…

> If you do not want JITing, you can already "pre-compile" dotnet code, and you will achieve near-native performance in either case—far better performance than running Rust as IL, as the author indicated.

AOT is still not "there yet" in some cases though? At least that was my understanding. It cannot do every single .NET project out there yet, but it can do some.

Re: Rust panics under the hood, and implementing them in .NET

#73

Post by Nullabillity »

neonsunset wrote: post #53
jen20 wrote: post #48

Earlier quoted context omitted.

A timeline: - The MS Debugger was use in Rider - thus was perfectly functional from a technical perspective. - It was later discovered that the license was proprietary, allowed only for MS products. VS Code is one of those. The extension may legally not be used with VS Codium or other such telemetry-neutering builds. - The debugger was removed, and debugging of Core CLR apps was unavailable while JetBrains found an a…

These events predate .NET Core 3.1, which what I consider the baseline where "the new" .NET gotten good enough for businesses to migrate to. Before that there was a lot of uncertainty, breaking changes and culture shock, the echo of which is still felt to this day. Nonetheless, this holds little influence on the state of affairs in the last few versions, certainly since .NET 5, which, if I understand your first reply…

The difference is that it's still an issue in 2024.

Re: Rust panics under the hood, and implementing them in .NET

#74

Post by neonsunset »

Nullabillity wrote: post #73
neonsunset wrote: post #53

Earlier quoted context omitted.

These events predate .NET Core 3.1, which what I consider the baseline where "the new" .NET gotten good enough for businesses to migrate to. Before that there was a lot of uncertainty, breaking changes and culture shock, the echo of which is still felt to this day. Nonetheless, this holds little influence on the state of affairs in the last few versions, certainly since .NET 5, which, if I understand your first reply…

The difference is that it's still an issue in 2024 .

It's not. Base C# extension for VS Code is free and MIT[0], the closed component, that is a debugger, is free as well. There is an open-source alternative too, and what effectively all debugger implementations do is integrate with debugger API provided by .NET itself, which any new tool can hook into. At the same time, Rider uses its own homegrown debugger, that works even better and has nice time-travel capability.

[0]: https://github.com/dotnet/vscode-csharp (this is _not_ DevKit, which is optional, the actual language support like Roslyn language server is part of the base extension, and you really don't need DevKit which has "extra VS-style accommodations" most of which can be done with different extensions, if that's what you want)

Re: Rust panics under the hood, and implementing them in .NET

#75

Post by bangaladore »

giancarlostoro wrote: post #72
bangaladore wrote: post #51

Earlier quoted context omitted.

If you go through the hassle of integrating this, you would be better off manually optimizing your C# code to reduce GC allocations, which you can do within the safe subset of C#. This is not targetted towards increasing performance as it seems the entirety of the rust application gets converted to IL, incurring large performance hits across the board. If you do not want JITing, you can already "pre-compile" dotnet c…

> If you do not want JITing, you can already "pre-compile" dotnet code, and you will achieve near-native performance in either case—far better performance than running Rust as IL, as the author indicated. AOT is still not "there yet" in some cases though? At least that was my understanding. It cannot do every single .NET project out there yet, but it can do some.

Here are the significant limitations according to MS [1]. Many are strange patterns you would probably not see in any actual code anyway.

[1] https://learn.microsoft.com/en-us/dotnet/core/deploying/nati...

Re: Rust panics under the hood, and implementing them in .NET

#76

Post by orf »

neonsunset wrote: post #71
orf wrote: post #61

Earlier quoted context omitted.

> but C# can never take a such change because it would be massively breaking Out of interest, why?

Unfortunately there is no short answer to this. But the main gist is that improving this to take advantage of all the underlying type system and compiler features would require a new API for LINQ, improvements for generic signature inference in C# (and possibly Rust-like associated types support), and introducing a similar new API to replace regular delegates, used by lambdas, anonymous functions, etc. with "value de…

Thank you! Very interesting

Re: Rust panics under the hood, and implementing them in .NET

#77

Post by phs2501 »

neonsunset wrote: post #55
phs2501 wrote: post #54

Earlier quoted context omitted.

Rust is a step sideways if anything. Yeah, you don't have manual memory management headaches in .NET, but you also don't have Rust's fairly strong compile-time guarantees about memory sharing and thread safety. Which enables stuff like rayon where you can basically blindly replace map with parallel map and if it compiles, it _should_ be safe to run. (I'm not super familiar with the .NET ecosystem, so it's quite possi…

FWIW .NET has many alternatives to popular Rust packages. Features provided by Rayon come out of box - it's your Parallel.For/Each/Async and arr.AsParallel().Select(...), etc. Their cost is going to be different, but I consistently find TPL providing pretty fool-proof underlying heuristics to make sure even and optimal load distrbituion. Rayon is likely going to be cheaper on fine-grained work items, but for coarse g…

Yeah it was specifically the (presumed) lack of Rust's "fearless" concurrency that I was referring to... i.e. we can ram this data through a parallel map, but is it actually safe to do?

(And of course the flip side of Rust here is that you need to be able to figure out how to represent your code and data to make it happy, which provides new and interesting limitations to how you can write stuff without delving into "unsafe" territory... something something TANSTAAFL)

Good info though; thanks!

Re: Rust panics under the hood, and implementing them in .NET

#78

Post by Nullabillity »

neonsunset wrote: post #74
Nullabillity wrote: post #73

Earlier quoted context omitted.

The difference is that it's still an issue in 2024 .

It's not. Base C# extension for VS Code is free and MIT[0], the closed component, that is a debugger, is free as well. There is an open-source alternative too, and what effectively all debugger implementations do is integrate with debugger API provided by .NET itself, which any new tool can hook into. At the same time, Rider uses its own homegrown debugger, that works even better and has nice time-travel capability.…

> the closed component, that is a debugger, is free as well.

Iff you use Microsoft's builds of VS Code. Just like back in 2018.

> At the same time, Rider uses its own homegrown debugger, that works even better and has nice time-travel capability.

So... still useless for the rest of us.

Re: Rust panics under the hood, and implementing them in .NET

#79

Post by neonsunset »

phs2501 wrote: post #77
neonsunset wrote: post #55

Earlier quoted context omitted.

FWIW .NET has many alternatives to popular Rust packages. Features provided by Rayon come out of box - it's your Parallel.For/Each/Async and arr.AsParallel().Select(...), etc. Their cost is going to be different, but I consistently find TPL providing pretty fool-proof underlying heuristics to make sure even and optimal load distrbituion. Rayon is likely going to be cheaper on fine-grained work items, but for coarse g…

Yeah it was specifically the (presumed) lack of Rust's "fearless" concurrency that I was referring to... i.e. we can ram this data through a parallel map, but is it actually safe to do? (And of course the flip side of Rust here is that you need to be able to figure out how to represent your code and data to make it happy, which provides new and interesting limitations to how you can write stuff without delving into "…

> we can ram this data through a parallel map, but is it actually safe to do?

Most of the time - it is, sort of. As in, accessing types that are not meant for concurrent access may lead to logic bugs, but the chance of this violating memory safety is almost nonexistent with the standard library and slim with community ones (for example, such library may use a native dependency which itself is not thread-safe, usually it's clear whether this is the case or not but the risk exists).

The common scenarios are well-known - use Interlocked.Add instead of +=, ConcurrentDictionary instead of a plain one, etc. .AsParallel() itself already is able to collect the data in parallel - you just use .ToArray and call it a day.

Other than that, most APIs that are expected to be used concurrently are thread-safe - from the top of my head: HttpClient, Socket, JsonSerializerOptions, Channel and its Reader/Writer can be shared by many threads (unless you specify single reader/writer on construction to reduce synchronization). Task can be awaited multiple times, by multiple threads too. A lot of C# code already assumes concurrent execution, and existing concurrency primitives usually reduce the need for explicit synchronization. Worst case someone just slaps lock (instance) { ... } on it and gets on with their life.

This is to say, Rust provides watertight guarantees in a way C# is simply unable to, and when you are writing low-level code, you are on your own in C# where-as Rust has your back. But in other situations - C# is generally not known to suffer from race conditions and async/await usually allows to flow the data in a linear fashion in multi-tasking code, allowing the underlying implementation to do synchronization for you.

Re: Rust panics under the hood, and implementing them in .NET

#80

Post by neonsunset »

Nullabillity wrote: post #78
neonsunset wrote: post #74

Earlier quoted context omitted.

It's not. Base C# extension for VS Code is free and MIT[0], the closed component, that is a debugger, is free as well. There is an open-source alternative too, and what effectively all debugger implementations do is integrate with debugger API provided by .NET itself, which any new tool can hook into. At the same time, Rider uses its own homegrown debugger, that works even better and has nice time-travel capability.…

> the closed component, that is a debugger, is free as well. Iff you use Microsoft's builds of VS Code. Just like back in 2018. > At the same time, Rider uses its own homegrown debugger, that works even better and has nice time-travel capability. So... still useless for the rest of us.

> So... still useless for the rest of us.

Why? How does the situation look in Java?

It also seems you have not read the original reply. So to reiterate, there is https://github.com/Samsung/netcoredbg too.

In any case, I assume none of this has any use to you and the reply is posted simply as bad faith engagement, as it continues to happen whenever a piece of software that uses .NET is mentioned, because usually very few people within community have/take issue with the current (rich) tooling options.

Note how many comments here and in similar submissions completely ignore the topic at hand and instead try to criticize the points that their authors assume are an issue with .NET itself.

Post reply on HN