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

31–40 of 83 posts

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

#31

Post by pjmlp »

neonsunset wrote: post #10
pjmlp wrote: 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…

While "C# Language Runtime" as a joke term certainly exists, most runtime improvements benefit all languages that target it, individual changes would have different impact on different languages but that's expected. It is likely further devirt and escape analysis work will have greater impact on F# for example.

As mentioned, I am waiting for .NET 9 final release notes in November.

Also a solution for code generators, analysers, interceptors usage in .NET libraries and how to consume them from F#, some day, if ever.

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

#32

Post by ilyagr »

I find the relationship between mutlithreading and panics' default behavior confusing.

In a single-threaded program, a panic is not supposed to be "caught" and aborts everything. If the main thread panics, the program stops.

But in a multi-threaded program, a panic terminates only the thread it happened in, and the program is allowed to handle that case without termination.

I'm guessing that setting `panic=abort` changes this behavior, but I'm not sure.

Docs: https://doc.rust-lang.org/std/macro.panic.html#current-imple..., the third sentence of https://doc.rust-lang.org/std/thread/fn.spawn.html

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

#33

Post by [deleted] »

xelamonster wrote: post #25
CharlieDigital wrote: post #6

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?"

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.

[deleted]

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

#34

Post by kodablah »

jen20 wrote: post #23
CharlieDigital wrote: post #6

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?"

One example is the core Temporal.io client, which is implemented in Rust, and wrapped by (most of) the other SDKs including .NET. I imagine this pattern will become more common for fat clients where it is desirable have a single implementation with idiomatic language bindings.

Correct, granted it's more complicated than "clients". At least Node.js (Neon), Python (PyO3), and Ruby (rb-sys/magnus) have nice supported bridge wrappers. The .NET-to-Rust interfacing in the Temporal .NET SDK required pure C FFI and P/Invoke and being careful about GC and lifetimes during interop. Can see the bridge at https://github.com/temporalio/sdk-dotnet/tree/main/src/Tempo....

I can say with regards to panics, .NET is very nice to wrap Rust panics into `SEHException` classes (though of course we strive to be completely panic free).

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

#35

Post by zamalek »

ilyagr wrote: post #32

I find the relationship between mutlithreading and panics' default behavior confusing. In a single-threaded program, a panic is not supposed to be "caught" and aborts everything. If the main thread panics, the program stops. But in a multi-threaded program, a panic terminates only the thread it happened in, and the program is allowed to handle that case without termination. I'm guessing that setting `panic=abort` cha…

Your assumptions about panic=abort are correct, it will simply terminate the entire process. The single thread and multithreaded behaviors are technically the same. A thread can observe the panic of another, as such, in a single threaded app, which thread would observe the panic in the main thread? There is no other thread to do that.

What you could do is create a single new thread and pretend as though its the main thread, observing any panics on the original main thread.

Edit: your mental model should be to avoid thinking about panics (beyond avoiding them in the first place). Panics are supposed to be extremely rare, and typically something that would be difficult to recover from. They are not exceptions; they are not designed to be caught. The difficulty in dealing with them is a feature that prevents anti patterns. If something panics you have a bug.

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

#36

Post by jen20 »

neonsunset wrote: post #27
bangaladore wrote: post #22

Earlier quoted context omitted.

What does Rider use? I assume it's not a proprietary MS one? Or did they license it?

They use their own in-house implementation. There's an OSS alternative from Samsung https://github.com/Samsung/netcoredbg but I haven't heard of anyone using it. In general, the debugger is not intentionally made unavailable but rather the "properietary" one is just the original Visual Studio debugger extracted into a standalone package adapted to cross-platform. Other than that, CoreCLR exposes rich debugger API, an…

> debugger is not intentionally made unavailable

> rather the "properietary" one

The fact that it is proprietary intentionally makes it unavailable for use outside of Visual Studio and Xamarin Studio - this actually caused debugging to be unavailable in Rider for a while a few years ago before they built their own.

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

#37

Post by danielovichdk »

moomin wrote: post #24
layer8 wrote: post #14

Earlier quoted context omitted.

Microsoft didn’t manage to have Visual Basic target .NET without turning its semantics into C# with different syntax, so this will be interesting to see.

Anyone remember J#?

IronRuby?

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

#38

Post by debugnik »

neonsunset wrote: post #10
pjmlp wrote: 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…

While "C# Language Runtime" as a joke term certainly exists, most runtime improvements benefit all languages that target it, individual changes would have different impact on different languages but that's expected. It is likely further devirt and escape analysis work will have greater impact on F# for example.

> most runtime improvements benefit all languages that target it

And most CIL ABI additions to the CLR driven by C# totally break them, because the C# ecosystem adopts them immediately (recently even breaking changes in the shared framework!), and there's no modern equivalent to the Common Language Specification.

Plus, no library writer would care if there was a CLS 2.0 because every CLR language other than C# and F# is in maintenance mode or simply abandoned.

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

#39

Post by riquito »

CharlieDigital wrote: post #6
jasonjayr wrote: post #5

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?"

I'm sure that .NET has all libraries you'll need and to absolutely need one from a different language, whatever it is, it's a pretty niche case (e.g. perhaps the extremely good Rust `regex` library is faster, but it would hardly be worth the extra complexity in the general case).

I think is more common that you have some in-house library in a different language (Rust in this case) and you want to reuse them without rewriting them.

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

#40

Post by zamalek »

zamalek wrote: post #13
pjmlp wrote: post #9

Earlier quoted context omitted.

In theory, the compiler could do the same as C++/CLI, and output safe Assemblies when specific code patterns aren't used.

AFAIK, the IJW bits of the CLR are exclusive to Windows.

I guess another option would be to store the native code as an assembly manifest stream, and cast that to a delegate at runtime. That would achieve much the same thing as IJW without the proprietary bits.
Post reply on HN