3 ms·

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 marsha

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 :).
- megadal 2y ago
  > 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. I guess the part I am still missing is when you say Rust in this context, it seems like you're essentially referring to "Rust.NET" really, and not Rust. E.g. it makes it easier to call .NET code from Rust _if_ it's using your .NET target, but Rust for other targets, not so much. (^correct me if I'm wrong here, as the rest of the points made are based on this assumption) This just seems contradictory to the goals of someone using .NET/Rust interop in the first place. If you're bringing in Rust, it's because you want the raw power of native code, not just the ability to easily write Rust code where you absolutely could've just written in your original .NET language (because ultimately, your compiler target is .NET, not executable code itself). I can see many layers of abstraction dealing with this issue, but it still makes me wonder why someone wouldn't just compile Rust to a DLL and call that from .NET. The calls from Rust -> .NET runtime could be useful, however, as I'm pretty sure you can't just load a class library dll in rust and start instantiating things from it. But at the end of the day, I can't see that being possible without loading the .NET runtime in your Rust program, which involves loading all those dependencies, which .NET languages already do very well by themselves so why not just, for example, write a Rust app and a .NET app and use IPC in such a scenario.

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

megadal 2y ago
> 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. I guess the part I am still missing is when you say Rust in this context, it seems like you're essentially referring to "Rust.NET" really, and not Rust. E.g. it makes it easier to call .NET code from Rust _if_ it's using your .NET target, but Rust for other targets, not so much. (^correct me if I'm wrong here, as the rest of the points made are based on this assumption) This just seems contradictory to the goals of someone using .NET/Rust interop in the first place. If you're bringing in Rust, it's because you want the raw power of native code, not just the ability to easily write Rust code where you absolutely could've just written in your original .NET language (because ultimately, your compiler target is .NET, not executable code itself). I can see many layers of abstraction dealing with this issue, but it still makes me wonder why someone wouldn't just compile Rust to a DLL and call that from .NET. The calls from Rust -> .NET runtime could be useful, however, as I'm pretty sure you can't just load a class library dll in rust and start instantiating things from it. But at the end of the day, I can't see that being possible without loading the .NET runtime in your Rust program, which involves loading all those dependencies, which .NET languages already do very well by themselves so why not just, for example, write a Rust app and a .NET app and use IPC in such a scenario.