5 ms·

Rust to .NET compiler – Progress update

46 points by sbt567 2y ago

Alupis 2y ago
I'm curious of the utility of writing Rust code but wanting to run it on the CLR. If anything, a GraalVM target would make more sense, as it's already gaining traction for this type of thing (although, usually interpreted langs like python, ruby, etc). Even there, the utility of running Rust on a JVM target also seems dubious. TFA doesn't mention an intended use-case. Perhaps it's an academic endeavor?
- mikasa71 2y ago
  Getting into google Summer of code.
  - FractalFir 2y ago
    [dead]
- vips7L 2y ago
  IIRC graal can already run clang ir so in _theory_ you should be able to run Rust.
  - yarg 2y ago
    https://www.graalvm.org/latest/reference-manual/llvm/Compatibility/ https://www.graalvm.org/latest/reference-manual/llvm/Compati... It can run any LLVM bitcode, but I'm not sure where that leaves you if or when you want to call through from java.
- neonsunset 2y ago
  For the Rust use case, JVM is fundamentally limited in ways that .NET isn't. Perhaps GraalVM does better but IL offers a direct 1:1 for many features that Rust needs, like struct generics.
- wdb 2y ago
  Reuse of existing business logic code. That’s what I do when reusing Swift or Go code in .NET.
- FractalFir 2y ago
  This project did start off as a way for me to learn how Rustc works, but there are legitimate use cases (and I have been approached by people interested in using it). The main goal of the project is allowing people to easily use existing Rust libraries from .NET. I want people to be able to use Rust libs in .NET without even knowing they were written in Rust. Besides the main compiler part, the project also comes with a tightly integrated interop layer. While it is not finished yet, it allows you to do things like holding references to C# classes in standard Rust code. The compiler will also be able to verify your Rust/.NET interop code, ensuring it is safe and reliable. So, someone can take, for example a Rust ML framework or a Rust physics engine, define a few .NET classes and methods (fully in Rust!) and ship a portable .NET assembly for people to use. Since Rust manages memory explicitly, the GC will have less work to do, reducing pauses and speeding execution up. Rust code also heavily uses the stack, making it more cache-friendly. From my benchmarks, the Rust on .NET is faster than C#, but slower than native code. So, the overall idea is to provide an easy way to write safe .NET libraries, which are faster than existing ones, and are as convenient to use as the existing solutions. If you have any questions regarding the project, feel free to ask :)!
megadal 2y ago
How is this is more useful than just compiling Rust into a dll and using that, or better, writing some framework or tooling that automates the process of marshaling/unmarshaling data for a Rust dll? A .NET target for Rust just makes no real sense to me given Rust is basically already interoperable with .NET (or rather .NET is already interoperable with unmanaged native code, which Rust can generate)
- pcwalton 2y ago
  For one, being able to JIT Rust is nice for development, to reduce compile times.
  - megadal 2y ago
    Yeah but you would be constrained basically to a subset of .NET, as it is no longer a native language but a .NET language, so it's not like you'll be JITting huge Rust applications (where compile time is actually high). There are online Rust compilers and interpreters already if you just want to rapid prototype and develop ideas in Rust
    - littlestymaar 2y ago
      > There are online Rust compilers and interpreters already if you just want to rapid prototype and develop ideas in Rust You are responding to one of the key developers of Rust early on[1], who's been working with the language for 14 years at that point. [1] https://github.com/rust-lang/rust/graphs/contributors?from=2010-06-27&to=2014-07-31&type=c https://github.com/rust-lang/rust/graphs/contributors?from=2... and he's still #16 in commits overall today, despite almost no activity on the rust compiler since 2014.
- FractalFir 2y ago
  The goal of my work is to allow for deeper and easier Rust/.NET interoperability. Besides the main compiler part, the project comes bundled with an interop layer, which allows you to easily call C# code from Rust and vice versa. Besides that, the interop layer (which is not yet finished) will also contain support for defining .NET classes from Rust code. The main use case I imagine is using Rust libraries from .NET. This can decrease the GC usage, while still allowing you to easily hold references to managed classes. This is also what the interop layer is geared towards: I want people to be able to quickly write managed wrappers around Rust crates, and for the Rust compiler to verify this glue code is safe, both on the Rust and .NET side. A lot of this is WIP, but in the future I will be able to fully verify the safety of such glue code. Having a pure-il assembly also enables one executable to be used across all targets .NET supports. Adding another pure-IL dependency can be easier than adding one that ships with an unmanaged library. The Rust to .NET translation is also very high-level: it preserves things like argument and variable names, types, field names, etc. You will also be able to catch a Rust unwind in C# code (as a normal exception) and Rust code will be able to catch .NET exceptions. Overall, the goal is to provide more performant .NET libraries, which can be used without even knowing that they are written in Rust. This way, the cost of moving existing codebases to such libraries will be much smaller. Please let me know if you have any other questions, I will be more than happy to answer them :).
withinrafael 2y ago
The author answers the "why" in the FAQ https://github.com/FractalFir/rustc_codegen_clr?tab=readme-ov-file#q-is-this-useless-since-i-can-already-load-shared-libraries-from-c https://github.com/FractalFir/rustc_codegen_clr?tab=readme-o.... I didn't find it very convincing but I'm sure the author will learn a lot of neat things along the way.
jjtheblunt 2y ago
Can’t one compile Rust to WASM, and use Blazor for .NET to WASM, so end up with both in the WASM world?
- giancarlostoro 2y ago
  My understanding about WASM is some things are not specc'ed out fully, so some things don't necessarily line up 100% and is up to implementation specifics or to be interpreted differently, you could have access to functions and such, but you'd have to ensure both implementations line up with the same understandings of returned types like strings involve some tricks that might not be 1:1 between languages compiled to WASM iirc. Not saying it can't be done, just there might be nuance. I could be wrong though, its been a year or two since I ran through the WASM bytecode spec.
deleted 2y ago
[deleted]

46 points by sbt567 2y ago

I'm curious of the utility of writing Rust code but wanting to run it on the CLR. If anything, a GraalVM target would make more sense, as it's already gaining traction for this type of thing (although, usually interpreted langs like python, ruby, etc). Even there, the utility of running Rust on a JVM target also seems dubious. TFA doesn't mention an intended use-case. Perhaps it's an academic endeavor?

mikasa71 2y ago
Getting into google Summer of code.
- FractalFir 2y ago
  [dead]
vips7L 2y ago
IIRC graal can already run clang ir so in _theory_ you should be able to run Rust.
- yarg 2y ago
  https://www.graalvm.org/latest/reference-manual/llvm/Compatibility/ https://www.graalvm.org/latest/reference-manual/llvm/Compati... It can run any LLVM bitcode, but I'm not sure where that leaves you if or when you want to call through from java.
neonsunset 2y ago
For the Rust use case, JVM is fundamentally limited in ways that .NET isn't. Perhaps GraalVM does better but IL offers a direct 1:1 for many features that Rust needs, like struct generics.
wdb 2y ago
Reuse of existing business logic code. That’s what I do when reusing Swift or Go code in .NET.
FractalFir 2y ago
This project did start off as a way for me to learn how Rustc works, but there are legitimate use cases (and I have been approached by people interested in using it). The main goal of the project is allowing people to easily use existing Rust libraries from .NET. I want people to be able to use Rust libs in .NET without even knowing they were written in Rust. Besides the main compiler part, the project also comes with a tightly integrated interop layer. While it is not finished yet, it allows you to do things like holding references to C# classes in standard Rust code. The compiler will also be able to verify your Rust/.NET interop code, ensuring it is safe and reliable. So, someone can take, for example a Rust ML framework or a Rust physics engine, define a few .NET classes and methods (fully in Rust!) and ship a portable .NET assembly for people to use. Since Rust manages memory explicitly, the GC will have less work to do, reducing pauses and speeding execution up. Rust code also heavily uses the stack, making it more cache-friendly. From my benchmarks, the Rust on .NET is faster than C#, but slower than native code. So, the overall idea is to provide an easy way to write safe .NET libraries, which are faster than existing ones, and are as convenient to use as the existing solutions. If you have any questions regarding the project, feel free to ask :)!

megadal 2y ago

How is this is more useful than just compiling Rust into a dll and using that, or better, writing some framework or tooling that automates the process of marshaling/unmarshaling data for a Rust dll? A .NET target for Rust just makes no real sense to me given Rust is basically already interoperable with .NET (or rather .NET is already interoperable with unmanaged native code, which Rust can generate)

pcwalton 2y ago
For one, being able to JIT Rust is nice for development, to reduce compile times.
- megadal 2y ago
  Yeah but you would be constrained basically to a subset of .NET, as it is no longer a native language but a .NET language, so it's not like you'll be JITting huge Rust applications (where compile time is actually high). There are online Rust compilers and interpreters already if you just want to rapid prototype and develop ideas in Rust
  - littlestymaar 2y ago
    > There are online Rust compilers and interpreters already if you just want to rapid prototype and develop ideas in Rust You are responding to one of the key developers of Rust early on[1], who's been working with the language for 14 years at that point. [1] https://github.com/rust-lang/rust/graphs/contributors?from=2010-06-27&to=2014-07-31&type=c https://github.com/rust-lang/rust/graphs/contributors?from=2... and he's still #16 in commits overall today, despite almost no activity on the rust compiler since 2014.
FractalFir 2y ago
The goal of my work is to allow for deeper and easier Rust/.NET interoperability. Besides the main compiler part, the project comes bundled with an interop layer, which allows you to easily call C# code from Rust and vice versa. Besides that, the interop layer (which is not yet finished) will also contain support for defining .NET classes from Rust code. The main use case I imagine is using Rust libraries from .NET. This can decrease the GC usage, while still allowing you to easily hold references to managed classes. This is also what the interop layer is geared towards: I want people to be able to quickly write managed wrappers around Rust crates, and for the Rust compiler to verify this glue code is safe, both on the Rust and .NET side. A lot of this is WIP, but in the future I will be able to fully verify the safety of such glue code. Having a pure-il assembly also enables one executable to be used across all targets .NET supports. Adding another pure-IL dependency can be easier than adding one that ships with an unmanaged library. The Rust to .NET translation is also very high-level: it preserves things like argument and variable names, types, field names, etc. You will also be able to catch a Rust unwind in C# code (as a normal exception) and Rust code will be able to catch .NET exceptions. Overall, the goal is to provide more performant .NET libraries, which can be used without even knowing that they are written in Rust. This way, the cost of moving existing codebases to such libraries will be much smaller. Please let me know if you have any other questions, I will be more than happy to answer them :).

withinrafael 2y ago

The author answers the "why" in the FAQ https://github.com/FractalFir/rustc_codegen_clr?tab=readme-ov-file#q-is-this-useless-since-i-can-already-load-shared-libraries-from-c https://github.com/FractalFir/rustc_codegen_clr?tab=readme-o.... I didn't find it very convincing but I'm sure the author will learn a lot of neat things along the way.

jjtheblunt 2y ago

Can’t one compile Rust to WASM, and use Blazor for .NET to WASM, so end up with both in the WASM world?

giancarlostoro 2y ago
My understanding about WASM is some things are not specc'ed out fully, so some things don't necessarily line up 100% and is up to implementation specifics or to be interpreted differently, you could have access to functions and such, but you'd have to ensure both implementations line up with the same understandings of returned types like strings involve some tricks that might not be 1:1 between languages compiled to WASM iirc. Not saying it can't be done, just there might be nuance. I could be wrong though, its been a year or two since I ran through the WASM bytecode spec.

deleted 2y ago

[deleted]