Hacker News Reader

Comment by gwbas1c | Hacker News Reader

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.

View on HN

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

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.

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.

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, specifically https://github.com/temporalio/sdk-dotnet/tree/main/src/Tempo...

1 - https://areweextendingyet.github.io/

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.

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.

In programming, never make an assumption that something is "easy."

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.

Exposing a C interface from rust is possible, but a bit of a pain.

Reply on news.ycombinator.com