Live data from Hacker News

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

fractalfir.github.io

51–60 of 83 posts

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

#51

Earlier quoted context omitted.

You can already do that from .NET itself. My question here is more along the lines of: "what Rust libs are out there that I might be interested in from .NET?"

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 code, and you will achieve near-native performance in either case—far better performance than running Rust as IL, as the author indicated.

In my opinion, the use case for this is minuscule at best.

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

#52
post #28

Earlier quoted context omitted.

And strongly in a "do not use unless you must" category too.

Still easier than dealing with P/Invoke or COM interop for C++ libraries, for C++ skilled devs. Pity that never made the cross platform jump.

Give this tool a try: https://github.com/dotnet/ClangSharp?tab=readme-ov-file#gene...

Just specify the headers to generate bindings for, and then use the generated interop code. Not too different from importing them as it was in the past.

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

#53
post #48

Earlier quoted context omitted.

This is a strange statement. That said debugger also comes with base C# extension, which is free and debugger aside, MIT, in VS Code on all platforms. Xamarin Studio and VS for Mac are deprecated. Given the confidence of your reply, one would assume you'd know this? Unless it's the exact problem I outlined previously, in which case please consider sharing grievances about something you do use actively instead, rather…

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 correctly, is the criticism in question.

Would you like to put it against Go for lacking package manager, Java for being stuck on version 8 or Rust for not having stable language server? /s

Or, to phrase it differently, "this is an issue" - "it was an issue in 2018" - "no, you don't get it, it's a valid criticism because nothing can ever be improved". You see how flawed this argument is?

I'm so tired of these low effort replies here that it's just sad, in technical conversations in other contexts I'd equally defend another language when someone blatantly misconstrues the facts. I don't have a horse in this race at this point, it's simply annoying to try to converse productively when the quality of replies is this low. I should probably spend time elsewhere.

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

#54

Earlier quoted context omitted.

I honestly can't think of any drop-in libraries that would give you much .NET (wow that name sucks to type on mobile) doesn't already give you, though if you're struggling with a particularly slow implementation of something the Rust version is likely faster. I think the more useful case for Rust here is rewriting the heavier or more error-prone parts of your own app logic in it.

Rust is a step back with respect to being error prone, unless you're doing manual memory management in .Net (i.e. unsafe). The use cases I see are going to be things such as sharing a library over multiple platforms. I've done that with Go in the past via cgo.

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 possible there's equivalent tooling for enforced thread safety. I haven't heard much about it though, if so.)

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

#55
post #54

Earlier quoted context omitted.

Rust is a step back with respect to being error prone, unless you're doing manual memory management in .Net (i.e. unsafe). The use cases I see are going to be things such as sharing a library over multiple platforms. I've done that with Go in the past via cgo.

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 grained ones there will be little to no difference.

I think the main advantages of Rust are its heavier reliance on static dispatch when e.g. writing iterator expressions (underlying type system as of .NET 8 makes them equally possible, a guest language could choose to emit ref struct closures that reference values on stack, but C# can never take a such change because it would be massively breaking, a mention goes to .NET monomorphizing struct generics in the exact same way it happens in Rust), fearless concurrency, access to a large set of tools that already serve C/C++ and confidence that LLVM is going to be much more robust against complex code, and of course deterministic memory reclamation that gives it signature low memory footprint. Rust is systems-programming-first, while C# is systems-programming-strong-second.

Other than that, C# has good support for features that allow you to write allocation-free or manual memory management reliant code. It also has direct counterpart to Rust's slice - Span which transparently interoperates with both managed and unmananged memory.

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

#56
post #15

In the past I have worked on Solidity -> Rust compiler, to enable Solidity on WASM VMs. My pain point was emulation of C3 inheritence in Rust, which I actually was able to implement with a few macros. In Rust -> .NET I'm interested in how he does the `DerefMut` trait.

> how he does the `DerefMut` trait. What do you mean by that? A compiler backend isn't even exposed to high level concepts like traits.

I was thinking about code to code translation. You are right.

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

#58
post #8

Earlier quoted context omitted.

That is why CLR used to mean Common Language Runtime, and there were so many languages on the launch event and .NET SDK bundled on computer magazines back in 2001. Then the Windows only focus (for a while there was Rotor), and Microsoft being Microsoft, all that interest faded away and people focused on the JVM, even though MSIL was designed for all kind of languages (well dynamic came later with Iron languages and D…

> Nowadays CLR almost feels to have changed into C# Language Runtime, given the C# centric decision on modern .NET design. Definitely! VB.Net is basically "dead" and F# will never really reach critical mass.

F# features creep slowly into C#, though, I feel. (as those of Scala would creep into Java at a delay)

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

#59

This is really neat, I always wanted to see other languages target .NET much like the JVM was a popular platform to target. Considering .NET is fully MIT licensed I am surprised we dont see more languages that target .NET

Idk if it counts but there is VL, a node based visual programming language for .NET.

https://visualprogramming.net

https://thegraybook.vvvv.org/reference/getting-started/dotne...

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

#60

Earlier quoted context omitted.

.net considers the rust code "unsafe" so you can do unmanaged, non-GC stuff in the Rust portion of the code.

You can already do that from .NET itself. My question here is more along the lines of: "what Rust libs are out there that I might be interested in from .NET?"

matrix-rust-sdk -> build a Matrix client in the native platform for Windows
Post reply on HN