41–50 of 83 posts
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.
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.
As a novice with Rust maintaining a cross-platform library written in Rust, I've found panics/unwinding is one of the most annoying things to figure out in the builds for various platforms. I'm using nostd and panic=abort to keep the library small (around 200kb after being stripped), but it's really not a well-supported setup. Depending on the platform, I get an error that the _Unwind_Resume symbol is not defined (de…
As a novice with Rust maintaining a cross-platform library written in Rust, I've found panics/unwinding is one of the most annoying things to figure out in the builds for various platforms. I'm using nostd and panic=abort to keep the library small (around 200kb after being stripped), but it's really not a well-supported setup. Depending on the platform, I get an error that the _Unwind_Resume symbol is not defined (de…
Try `-Z build-std=core` if you're not already doing it.
As a novice with Rust maintaining a cross-platform library written in Rust, I've found panics/unwinding is one of the most annoying things to figure out in the builds for various platforms. I'm using nostd and panic=abort to keep the library small (around 200kb after being stripped), but it's really not a well-supported setup. Depending on the platform, I get an error that the _Unwind_Resume symbol is not defined (de…
>I get an error that the _Unwind_Resume symbol is not defined (despite it not supposed to be needed) Try `-Z build-std=core` if you're not already doing it.
From the repo[0]: > The project aims to provide a way to easily use Rust libraries in .NET. It comes with a Rust/.NET interop layer, which allows you to easily interact with .NET code from Rust Are there some standout Rust libraries out there? Very curious about the motivation and use cases. [0] https://github.com/FractalFir/rustc_codegen_clr
.net considers the rust code "unsafe" so you can do unmanaged, non-GC stuff in the Rust portion of the code.
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).
Earlier quoted context omitted.
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.
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 than what you think are .NET's issues.
Earlier quoted context omitted.
> 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.
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…
- 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 alternative (which did not take very long).
As I alluded to, the fact that this worked, and was just prevented by licensing makes it a construct solely of proprietary software licensing. It was well documented at the time:
- https://blog.jetbrains.com/dotnet/2017/02/15/rider-eap-17-nu...
- https://blog.jetbrains.com/dotnet/2017/02/23/rider-eap-18-co... news-about-coreclr-on-windows
As for daily driving: I was the first person outside of JetBrains to get hands on Rider. The fact that I don't write C# _daily_ in 2024 does not mean I have no first-hand knowledge of what was happening in 2016-2018, or indeed today.
Earlier quoted context omitted.
>I get an error that the _Unwind_Resume symbol is not defined (despite it not supposed to be needed) Try `-Z build-std=core` if you're not already doing it.
Could you elaborate on why that works, or why it's necessary?
I do know that for regular std-using programs, std has its own panic strategy that it was compiled with, so even if you set your own code's panic strategy to abort, it still ends up pulling in unwind-related code from libstd. The solution to that is to also recompile libstd with the same parameters as your own code, which is what `-Z build-std` does.
I don't know if the same thing applies even to libcore, ie for no_std programs. FWIW, coincidentally I spent yesterday making a no_std panic=abort program for a custom freestanding target, and the only missing symbols it needed from me were memcpy and memcmp, even though the code does do panicking things like slice indexing. That program requires `-Z build-std=core` since it's for a custom freestanding target.
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