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

61–70 of 83 posts

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

#61

Post by orf »

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…

> but C# can never take a such change because it would be massively breaking

Out of interest, why?

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

#62

Post by SAI_Peregrinus »

zamalek wrote: post #35
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…

The last paragraph is particularly important!

Catching panics in Rust is meant pretty much only to avoid unwinding across an FFI boundary, since that would be undefined behavior. Pretty much every other use of `catch_unwind` is a mistake, it's not guaranteed to catch all panics (they can also just abort) so panics are rather different from exceptions. Panics are intended to be useless for control flow, unwinding exists to help debugging, and any panic indicates a bug in the invoking program.

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

#63

Post by ilyagr »

zamalek wrote: post #35
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…

From this perspective, the weird part is that mutli-threaded programs can recover from panics in some of the threads (as long as `panic=unwind`). I suppose it's so practically useful that people made an exception for it, without this feature people would have to do inter-process communication (for better or worse).

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

#64

Post by wabain »

ilyagr wrote: post #63
zamalek wrote: post #35

Earlier quoted context omitted.

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…

From this perspective, the weird part is that mutli-threaded programs can recover from panics in some of the threads (as long as `panic=unwind`). I suppose it's so practically useful that people made an exception for it, without this feature people would have to do inter-process communication (for better or worse).

I think what's really special about the main thread is that Rust (and I believe in some cases the OS) forces the process to exit if the main thread completes. I think the difference in panic handling is mostly down to that. I think the description in the docs for std::thread describe this distinction the most explicitly.[1]

Fundamentally panic recovery works the same way in all threads—for both the main thread and spawned threads the standard library implements panic handling by wrapping the user code in catch_unwind().[2][3] It's more or less possible to override the standard library's behavior for the main thread by wrapping all the code in your main() function in a catch_unwind() and then implementing whatever fallback behavior you want, like waiting for other threads to exit before terminating. In some cases something like this happens automatically, for instance if the main thread spawns other threads using std::thread::scope.[4]

[1]: https://doc.rust-lang.org/std/thread/#the-threading-model [2]: https://github.com/rust-lang/rust/blob/7042c269c166191cd5d8d... [3]: https://github.com/rust-lang/rust/blob/7042c269c166191cd5d8d... [4]: https://doc.rust-lang.org/std/thread/fn.scope.html

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

#65

Post by ai_ »

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

If I read TFA correctly it looks like they're doing codegen to IL (which is analogous to Java bytecode, but for .net), which would probably mean your rust code is subject to GC? It seems like you would get rid of performance benefits of rust. But .net can do unsafe pointer operations and it can pin objects to avoid GC (they call it "handles" iirc).

You can also just allocate unmanaged memory directly via `Marshal.AllocHGlobal`. Basically the .NET version of `malloc()`

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

#66

Post by pjmlp »

neonsunset wrote: post #52
pjmlp wrote: post #28

Earlier quoted context omitted.

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.

Thanks for the tip.

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

#67

Post by jen20 »

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…

A great example of moving the goalpost post-hoc.

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

#69

Post by pjmlp »

layer8 wrote: post #14
giancarlostoro wrote: post #3

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

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.

Yes it did, the complaints were mostly from VB 6 folks complaining about VB.NET 1.0, several VB features like Me objects, being again more dynamic, repl, were eventually added back for those that kept around in VB.NET land.

Not that it matter much nowadays, given that its development has been placed on freeze mode.

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

#70

Post by pjmlp »

breakingcups wrote: post #50
giancarlostoro wrote: post #3

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

I remember when Delphi could briefly compile to .NET.

The guys that worked on that compiler backend keep the tooling alive, naturally it has a different name nowadays.

https://www.remobjects.com/elements/oxygene/

Post reply on HN