3 ms·
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 s
by 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 agoIf 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 agoHere 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...