Re:Rust to .NET compiler – Progress update
by megadal on Friday May 03, 2024 @09:07PM
(#40253980)
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)
Re:Rust to .NET compiler – Progress update
by megadal on Friday May 03, 2024 @09:20PM
(#40254037)
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
Re:Rust to .NET compiler – Progress update
by megadal on Monday May 06, 2024 @11:48AM
(#40275996)
> 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.
Re:Rust to .NET compiler – Progress update
by Alupis on Friday May 03, 2024 @09:00PM
(#40253940)
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?
Re:Rust to .NET compiler – Progress update
by neonsunset on Friday May 03, 2024 @10:08PM
(#40254236)
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.
Re:Rust to .NET compiler – Progress update
by giancarlostoro on Friday May 03, 2024 @09:32PM
(#40254092)
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.
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)
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=2... and he's still #16 in commits overall today, despite almost no activity on the rust compiler since 2014.
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.
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?
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.
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.