Since Rust and Motoko both compile to Wasm, they should be able to interoperate.
What’s the story on that interoperation currently? I imagine Motoko → Rust interop might be more mature than Rust → Motoko interop, since Rust is much more mature and probably has better FFI or other mechanisms.
I’m currently writing a GraphQL library in Rust for the IC, but I would love for Motoko developers to be able to use it (and I’d like to avoid rewriting it if possible, especially since I’m using quite a few Rust libraries that implement a lot of the GraphQL functionality, all of which would have to be rewritten in Motoko).
Thank you, though I’m discussing interop at the language/binary level, not at the canister level. I am writing a library in Rust that the user creates their own structs and functions for, to define GraphQL types and resolvers. Those types and resolvers are handed to an already-existing GraphQL library (written in Rust) that then allows for query execution.
As designed, the user must use Rust if they want to add their own GraphQL types and resolvers. I want the user to also be able to create GraphQL types and resolvers in Motoko. The types I might be able to deal with already, but the resolvers are functions and I do not believe are easily serializable. I am hoping there is a way to import the Rust library’s Wasm binary into Motoko so that the user can then pass in their GraphQL types and resolvers written in Motoko.
This functionality is not something inter-canister calls can achieve, the canister itself needs access to the Rust binary so that it can resolve GraphQL queries. I want both canisters written in Rust and Motoko to be able to resolve GraphQL queries directly within themselves.
I should clarify, perhaps inter-canister calls could achieve this, but I think it could create unnecessary canister complexity and runtime latency, when instead everything could be done elegantly from within one canister, if binaries can easily be imported from Rust into Motoko
You are right, there is no FFI support at the moment. But we can do this as inter-canister calls by providing callback functions as resolvers. You can implement the resolver functions in Motoko and send it to Rust as a function reference. The limitation is that the resolver function cannot be polymorphic, and it adds some latency.
No, nothing came out of it so far besides some discussions. The effort would be quite substantial AFAIK and there are things the team thinks where their time is better spent
I have an idea on how this could be done. @lastmjs@skilesare It would involve making changes to moc and also creating a library of precompiled and preparred packages in Rust. Do you think it would have impact on current Motoko development?
I was thinking about this topic a lot, but I do not know how often this feature would be used.
Well…in my opinion, this is one of the single biggest blockers for Motoko adoption. We don’t need to be able to call any rust module…just getting access to stateless libraries for complicated functions like crypto signing, signature verification, etc would solve a to of ‘library brick walls’ that currently limit adoption.
I don’t think I’d want to stop Luc’s work on stable memory, but its high on the list for me.
Just yesterday someone was looking for DER encoding. Nobody wants to rewrite that in Motoko. It is a thankless job and unless there’s a bounty for it, unlikely to get done.
I’m having issues with signing now. I’m being met with one motoko limitation after another in an attempt to just sign an authenticated transaction in motoko.
