5 ms·

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

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