3 ms·

What about making it easy to import Rust business logic into C# / Swift / whatever GUI language you're using? I get the value of 100% (or 50% or 80%) implement

What about making it easy to import Rust business logic into C# / Swift / whatever GUI language you're using? I get the value of 100% (or 50% or 80%) implementing the UI in Rust; especially for tools that won't benefit from a native UI, or tools that only need light integration into platform-specific UI features. I've also shipped a desktop product that had a 100% native UI and a cross-platform codebase. Today, implementing that cross-platform codebase in Rust and then importing it into native C# and Swift codebases for the Mac and Windows variants would be ideal.

bradrn 4y ago
No experience with Rust, but for a couple of personal projects I’ve written the logic in Haskell and the GUI in C++ (e.g. https://github.com/bradrn/brassica/blob/master/ARCHITECTURE.md https://github.com/bradrn/brassica/blob/master/ARCHITECTURE....). It works pretty well, at least for smaller projects — the basic idea is that the Haskell code gets compiled into a library (static on Windows, dynamic on Linux) which the C++ side can link to. I’d imagine doing the same with Rust would be even easier, since it’s less of a pain to marshal stuff across the language barrier.
bryanlarsen 4y ago
That's a good option. It's easy to make a library in Rust that exports a C linkage, and it's easy to link a C library in most languages. Some languages have richer linkages to Rust (for example Python). A similar option would be to use the native UI with a Rust binding -- for example cacao on MacOS. The advantage of this approach is if your whole team knows Rust they can help with patching and maintenance. It doesn't help at the beginning because presumably the person who knows AppKit also knows ObjectiveC and/or Swift. But once the UI is created a single code base is an advantage for maintenance.
kodablah 4y ago
Having integrated C# and Rust recently[0], I have found that unlike Node w/ neon and Python w/ PyO3 + PyO3 Asyncio, there is no good Rust integration with .NET. Interopterus, rnet, etc leave a good bit to be desired. I ended up writing all the unsafe bindings myself and used cbindgen on the Rust side to make a header and ClangSharpPInvokeGenerator to generate the C# binding. But you still have to manually handle ownership/freeing yourself, e.g. with SafeHandle. The ecosystem[1] could use something better, but nothing is there yet. 0 - https://github.com/temporalio/sdk-dotnet https://github.com/temporalio/sdk-dotnet, specifically https://github.com/temporalio/sdk-dotnet/tree/main/src/Temporalio/Bridge https://github.com/temporalio/sdk-dotnet/tree/main/src/Tempo... 1 - https://areweextendingyet.github.io/ https://areweextendingyet.github.io/
deleted 4y ago
[deleted]
LeFantome 4y ago
It is really simple to call into native code from C# ( .NET ). While I have not done this with Rust specifically, presenting a C compatible interface from Rust should work fine.
- School-Cotton 4y ago
  Exposing a C interface from rust is possible, but a bit of a pain.
- gwbas1c 4y ago
  In programming, never make an assumption that something is "easy." https://news.ycombinator.com/item?id=35701181 https://news.ycombinator.com/item?id=35701181 did just that and explained the results. Personally, I find PInvoke time consuming; and often time a lot of people screw it up. I'm not sure how I'd translate things like lifetimes and ownership into C#: The language just doesn't have those concepts. Lifetimes might make sense as IDisposable, but that could get tedious. I'd be tempted for types that are just "memory" to have finalizers. Ownership may require some kind of locking wrapper.
mamcx 4y ago
This is what I do. Is SUPER productive & easy! I do ALL the UI logic on Rust: Internationalization, formatting, etc and in SwiftUI/JetpackCompose only pain stuff and send/get a single JSON internal FFI endpoint. So my "records" are just: App: {title: "Factura #F10", bg-100:"black", font:"...", ...} Data: Invoice {total:"$ 1'000.000,00", ...} my UI logic only deal with "clicks", dispatch & theming.
kitsunesoba 4y ago
I've considered doing this for cross-platform iOS/Android, but the problem there is that by sharing a functional core between platforms you're forfeiting a number of optimizations on iOS (and potentially Android, but everybody brings their own everything there anyway so it's kind of moot). Point in case, for cross platform networking you're probably pulling in something based on cURL, which is quite functional but as far as I'm aware lacks the optimizations and perks of the iOS networking stack gets you like batching network calls and firing them when the cell antenna is already active to save power, as well as things like transparently multiplexing available connections (e.g. cell and wifi) among other things. Of course these tradeoffs might make sense sometimes, but I think it's important to recognize that a cross-platform core isn't pure upside.

bradrn 4y ago

No experience with Rust, but for a couple of personal projects I’ve written the logic in Haskell and the GUI in C++ (e.g. https://github.com/bradrn/brassica/blob/master/ARCHITECTURE.md https://github.com/bradrn/brassica/blob/master/ARCHITECTURE....). It works pretty well, at least for smaller projects — the basic idea is that the Haskell code gets compiled into a library (static on Windows, dynamic on Linux) which the C++ side can link to. I’d imagine doing the same with Rust would be even easier, since it’s less of a pain to marshal stuff across the language barrier.

bryanlarsen 4y ago

That's a good option. It's easy to make a library in Rust that exports a C linkage, and it's easy to link a C library in most languages. Some languages have richer linkages to Rust (for example Python). A similar option would be to use the native UI with a Rust binding -- for example cacao on MacOS. The advantage of this approach is if your whole team knows Rust they can help with patching and maintenance. It doesn't help at the beginning because presumably the person who knows AppKit also knows ObjectiveC and/or Swift. But once the UI is created a single code base is an advantage for maintenance.

kodablah 4y ago

Having integrated C# and Rust recently[0], I have found that unlike Node w/ neon and Python w/ PyO3 + PyO3 Asyncio, there is no good Rust integration with .NET. Interopterus, rnet, etc leave a good bit to be desired. I ended up writing all the unsafe bindings myself and used cbindgen on the Rust side to make a header and ClangSharpPInvokeGenerator to generate the C# binding. But you still have to manually handle ownership/freeing yourself, e.g. with SafeHandle. The ecosystem[1] could use something better, but nothing is there yet. 0 - https://github.com/temporalio/sdk-dotnet https://github.com/temporalio/sdk-dotnet, specifically https://github.com/temporalio/sdk-dotnet/tree/main/src/Temporalio/Bridge https://github.com/temporalio/sdk-dotnet/tree/main/src/Tempo... 1 - https://areweextendingyet.github.io/ https://areweextendingyet.github.io/

deleted 4y ago

[deleted]

LeFantome 4y ago

It is really simple to call into native code from C# ( .NET ). While I have not done this with Rust specifically, presenting a C compatible interface from Rust should work fine.

School-Cotton 4y ago
Exposing a C interface from rust is possible, but a bit of a pain.
gwbas1c 4y ago
In programming, never make an assumption that something is "easy." https://news.ycombinator.com/item?id=35701181 https://news.ycombinator.com/item?id=35701181 did just that and explained the results. Personally, I find PInvoke time consuming; and often time a lot of people screw it up. I'm not sure how I'd translate things like lifetimes and ownership into C#: The language just doesn't have those concepts. Lifetimes might make sense as IDisposable, but that could get tedious. I'd be tempted for types that are just "memory" to have finalizers. Ownership may require some kind of locking wrapper.

mamcx 4y ago

This is what I do. Is SUPER productive & easy! I do ALL the UI logic on Rust: Internationalization, formatting, etc and in SwiftUI/JetpackCompose only pain stuff and send/get a single JSON internal FFI endpoint. So my "records" are just: App: {title: "Factura #F10", bg-100:"black", font:"...", ...} Data: Invoice {total:"$ 1'000.000,00", ...} my UI logic only deal with "clicks", dispatch & theming.

kitsunesoba 4y ago

I've considered doing this for cross-platform iOS/Android, but the problem there is that by sharing a functional core between platforms you're forfeiting a number of optimizations on iOS (and potentially Android, but everybody brings their own everything there anyway so it's kind of moot). Point in case, for cross platform networking you're probably pulling in something based on cURL, which is quite functional but as far as I'm aware lacks the optimizations and perks of the iOS networking stack gets you like batching network calls and firing them when the cell antenna is already active to save power, as well as things like transparently multiplexing available connections (e.g. cell and wifi) among other things. Of course these tradeoffs might make sense sometimes, but I think it's important to recognize that a cross-platform core isn't pure upside.