I would like to take the time to introduce Linwei Shang (@lwshang). Linwei has been working on the SDK team for a while now, more importantly he has been working to improve the Rust Canister developer experience.
The most notable changes are:
dfx now recognize “rust” type canisters
dfx new --type=rust to start new project with Rust canister
For more details, please check out the following links:
Hi all, I’m Linwei, a software engineer in the SDK team.
It’s my pleasure to support IC developers around the world, especially those who want to develop IC dapps in Rust.
Let me know if you have any questions or advices about Rust Canister Development.
I need to figure out how to perform an asynchronous operation from within a function that is not async. I have a dependency that has an API that requires a synchronous function. From within that synchronous function I need to call asynchronous functions such as to do a cross-canister call. This doesn’t work and I really need to find a workaround.
I seem to run into a lot of issues with Rust futures when trying to get already-existing Rust libraries to run on the IC. Async code doesn’t just work, and I wish it would.
It’s certainly nice to have this option, but I feel the rust projects / workflows still need some love. Unfortunately the default binary coming out of dfx new --type rust + deploy can’t be handled by the live IC out of the box. That’s frustrating for the newcomers, especially since the tutorials and quick start guides are a bit incomplete on these issues.
Rick (from DSCVR) has shared some startup scripts, where they use the size optimization tool, and others already had the flow running from past versions of dfx, but I think it’s a bit disappointing for new-comers to start a new project (with defaults) and be met by an error right out of the gate.
I’d suggest either promoting the “ic-cdk-optimizer” tool to the default install, or updating the docs with clear instructions highlighting that this would be a required step, or work with the team to support larger uploads on the replica, out of the box.
Hi @lastmjs, those two issues are realized by our team. We are considering them together with other upcoming improvements in Rust CDK. We want to provide a consistent develop experience.
@lastmjs, one workaround could be to model your effects as data.
That way, you would return a value from the synchronous function that represents the asynchronous operation you want to perform. You would then interpret the value in an asynchronous context to run it.
I think I get what you’re saying but unfortunately I don’t think that will work. I have a very specific API that I must adhere to, boa the JavaScript engine provides me a way to basically hook up an FFI so that I can expose a Rust function as a JavaScript function.
The Rust function must be asynchronous because that is what the API expects. I basically give boa a Rust function and a name, and then from a JavaScript environment I can call that name and have the Rust function execute.
It seems like either boa needs to accept an async function, or the IC needs to allow me to resolve a future from within a synchronous function.
One more thing on DID generation, when Im browsing a repo, reading the DID lets me know what an application is trying to achieve. So the fact that rust devs need to write their DID means it will be part of the repository, so I would like to keep this as a feature. Next, I believe these DID files + comments will be used to generate documentation for your IC projects. So if Motoko could by default drop the DID to the repo it would be nice.
For anyone else, I’ve created a very small example where you can try to tackle the issue. Just clone the repo and you can try to get it to work: GitHub - lastmjs/test-ic-boa-async
I agree, having it checked in is awesome, but generating it would be really nice. I plan to do this with Azle (TypeScript) and I don’t foresee any issues with generating the Candid, so not sure why Rust wouldn’t be able to do it as well.
and I set up auto-generation on my IC Canvas project because I cannot be bothered to hand-code a candid declaration. If you tag your methods, you can use the export_service() pattern to auto-generate: canvas/api.rs at main · krpeacock/canvas · GitHub
We definitely need to document this flow and add it to our Rust examples
I think we want to support both. A developer can choose to start with writing the did file and then generating the types and methods in the host language (similar to protobuf). Or they can start with writing the methods in the host language and then generating the did file.
Can we lift the binary size limit? I believe it’s 2MB right now. That’s really small. It’s becoming a problem for the users of Sudograph, as once their GraphQL schema reaches a certain size they simply can’t deploy their database anymore.
@lwshang thought you may have an idea… or if a constraint set at lower layers (i suspect it is a constraint at lower layer… but one you can communicate down the stack)
It’s good news for Rust developer. thank you. can we add function which generating candid file while cargo-candid build? I think we can add new utility cargo-candid. @diegop@lwshang
