10 ms·

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

CharlieDigital 2y ago
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?"
- giancarlostoro 2y ago
  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.
  - bangaladore 2y ago
    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.
    - giancarlostoro 2y ago
      > 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.
      - bangaladore 2y ago
        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/native-aot/fixing-warnings https://learn.microsoft.com/en-us/dotnet/core/deploying/nati...
- jen20 2y ago
  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.
  - kodablah 2y ago
    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/Temporalio/Bridge 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).
- xelamonster 2y ago
  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 2y ago
    [deleted]
  - radicalbyte 2y ago
    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.
    - phs2501 2y ago
      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.)
      - radicalbyte 2y ago
        As @neosunset says we have a lot of good options but I've not come across anything which strictly guarantees thread safety. In practise issues are uncommon and easy to identify / fix. Honestly I'm more interested in code contracts than Rust, as they allow you to make a set of statements of your system which can then be validated statically. I've had very good results using them (and am forever grateful to the colleague who introduced me to them)... and I am interested in Rust (having dabbled with it, only I'm yet to use it in a paying or production project). So sideways as you said - with C# you can usually rely on the GC for memory management, have fast compile times and what I feel is a more flexible model.. and top tier tooling and a huge and wide range of libraries. Rust can be much more efficient and has much better language-level properties wrt threat safety and a more mature story around native code. I'd use Rust for system-level code or places where I'd otherwise think of using C++. I keep having discussions with people who want to use Rust for everything - CLI tools, web services (which are doing pumping), business logic and the like. It's getting tiring. The trade-offs are bad. C#, Go and Java are all far better suited & cover pretty much all the niches. Does Rust have anything to spot resource leaks (i.e. the infamous IDisposable in C#)?
- riquito 2y ago
  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.
- tcfhgj 2y ago
  matrix-rust-sdk -> build a Matrix client in the native platform for Windows
pjmlp 2y ago
In theory, the compiler could do the same as C++/CLI, and output safe Assemblies when specific code patterns aren't used.
- zamalek 2y ago
  AFAIK, the IJW bits of the CLR are exclusive to Windows.
  - neonsunset 2y ago
    And strongly in a "do not use unless you must" category too.
    - pjmlp 2y ago
      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.
      - neonsunset 2y ago
        Give this tool a try: https://github.com/dotnet/ClangSharp?tab=readme-ov-file#generating-bindings 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.
        pjmlp 2y ago
        Thanks for the tip.
  - pjmlp 2y ago
    What is exclusive is the Visual C++ backend, because of the usual politics, C++ stuff is not under .NET team. Likewise the whole WinRT/UWP, .NET Native and C++/CX, were under WinDev umbrella, not DevDiv. Which is why there is this schizophrenic way of how .NET is currently handled on Windows desktop.
neonsunset 2y ago
The concept of "verifiable code" is effectively dead - even C#'s own syntax is sometimes desugared into what one could consider "unsafe" code in terms of feature use. Unsafe code is safe when used correctly, it does not imply the reliance on undefined or implementation-defined behavior :) For all intents and purposes, the non-unsafe subset of Rust is a safe language, and the distinction pretty much does not exist at the IL level.
asveikau 2y ago
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).
- ai_ 2y ago
  You can also just allocate unmanaged memory directly via `Marshal.AllocHGlobal`. Basically the .NET version of `malloc()`

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

giancarlostoro 2y ago
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.
- bangaladore 2y ago
  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.
  - giancarlostoro 2y ago
    > 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.
    - bangaladore 2y ago
      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/native-aot/fixing-warnings https://learn.microsoft.com/en-us/dotnet/core/deploying/nati...
jen20 2y ago
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.
- kodablah 2y ago
  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/Temporalio/Bridge 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).
xelamonster 2y ago
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 2y ago
  [deleted]
- radicalbyte 2y ago
  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.
  - phs2501 2y ago
    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.)
    - radicalbyte 2y ago
      As @neosunset says we have a lot of good options but I've not come across anything which strictly guarantees thread safety. In practise issues are uncommon and easy to identify / fix. Honestly I'm more interested in code contracts than Rust, as they allow you to make a set of statements of your system which can then be validated statically. I've had very good results using them (and am forever grateful to the colleague who introduced me to them)... and I am interested in Rust (having dabbled with it, only I'm yet to use it in a paying or production project). So sideways as you said - with C# you can usually rely on the GC for memory management, have fast compile times and what I feel is a more flexible model.. and top tier tooling and a huge and wide range of libraries. Rust can be much more efficient and has much better language-level properties wrt threat safety and a more mature story around native code. I'd use Rust for system-level code or places where I'd otherwise think of using C++. I keep having discussions with people who want to use Rust for everything - CLI tools, web services (which are doing pumping), business logic and the like. It's getting tiring. The trade-offs are bad. C#, Go and Java are all far better suited & cover pretty much all the niches. Does Rust have anything to spot resource leaks (i.e. the infamous IDisposable in C#)?
riquito 2y ago
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.
tcfhgj 2y ago
matrix-rust-sdk -> build a Matrix client in the native platform for Windows

pjmlp 2y ago

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

zamalek 2y ago
AFAIK, the IJW bits of the CLR are exclusive to Windows.
- neonsunset 2y ago
  And strongly in a "do not use unless you must" category too.
  - pjmlp 2y ago
    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.
    - neonsunset 2y ago
      Give this tool a try: https://github.com/dotnet/ClangSharp?tab=readme-ov-file#generating-bindings 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.
      - pjmlp 2y ago
        Thanks for the tip.
- pjmlp 2y ago
  What is exclusive is the Visual C++ backend, because of the usual politics, C++ stuff is not under .NET team. Likewise the whole WinRT/UWP, .NET Native and C++/CX, were under WinDev umbrella, not DevDiv. Which is why there is this schizophrenic way of how .NET is currently handled on Windows desktop.

neonsunset 2y ago

The concept of "verifiable code" is effectively dead - even C#'s own syntax is sometimes desugared into what one could consider "unsafe" code in terms of feature use. Unsafe code is safe when used correctly, it does not imply the reliance on undefined or implementation-defined behavior :) For all intents and purposes, the non-unsafe subset of Rust is a safe language, and the distinction pretty much does not exist at the IL level.

asveikau 2y ago

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).

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