Automatically generate candid from rust sources

I am getting this error

> didc bind can.did -t rs 
error: 'rs' isn't a valid value for '--target <target>'
        [possible values: did, js, mo, ts]

Is that a newer version?
I have v 0.1.0


Yes, please download the latest release, which is v0.1.3: Releases · dfinity/candid · GitHub


Generating service descriptions says:

After you develop a service in a language like Rust, however, there’s currently no way to automatically generate the service description in Candid. Therefore, if you write a program for a service in Rust or C, you need to write the Candid interface description manually

The doc is correct in the sense that we don’t have a user-friendly solution to automatically generate Rust bindings yet. didc can generate a Rust binding, but in many cases, you still need to hand-tune the output, for example, to derive more traits, add lifetime, add Box/Arc. Will update the doc once we have a configurable way to guide the binding generation.

There may be confusion: Paul linked to “generating service description”, i.e. going from rust to Candid. Yan seems to talk about going from Candid to Rust.

For Rust-to-Candid, we do have some macros, don’t we? The Candid guide should be updated to reflect that.


Ah, right. Rust-to-Candid is fine. We plan to include that macros into the CDK, so that users don’t need to write them anymore.

any tentative timeline for this? including docs


Any update on automatically generating the Candid from Rust? It would be so nice for Rust/custom canisters to have the same experience as Motoko where all of the Candid generation is hidden away unless the developer explicitly wants to write a Candid file by hand.

This would help the Azle and Kybra CDKs a lot.

1 Like

We prioritized this work in 2023 Q2. If everything goes well, we will get it in April.


So excited for this!!!

Hey! April is now over, any update on this?

Will be part of the new CDK release: export candid by chenyan-dfinity · Pull Request #386 · dfinity/cdk-rs · GitHub


To clarify, will this allow developers to remove the candid property from their dfx.json file?

What we’re after is removing that requirement and having dfx automatically retrieve Candid from Rust (and custom canisters that use Rust), unless the developer explicitly specifies a Candid file.

The main goal is that developers no longer need to use the candid_method attributes to generate the did file.

You can use the generated did file as the final did file, so the candid field in dfx.json will be optional. It’s still recommended that the developer provides the final did file for better readability. dfx build can check if the provided did file is out of sync with the generated did file.

1 Like

So will we still have to run wasmtime or something ourselves to get the generated did file? Or will we simply be able to upgrade dfx and remove the candid property? It looks like there’s still commands that the developer will need to run to generate this?

Just trying to understand, will dfx be able to generate and find the did file on its own? Will it be automatically included in the public metadata section?

Yes, dfx will run wasmtime and store the did file in the metadata if the canister type is Rust. The build script is for custom type projects.

1 Like

Okay I understand, and that’s great. Can we get the same functionality somehow for custom canisters that use Rust? Azle and Kybra create Rust canisters, but we use the custom type to insert our own build process. Otherwise we won’t be able to take advantage of this.

1 Like

The build script in that PR should work for custom canisters?

But that build script requires wasmtime and ic-wasm, both dependencies we would need to figure out how to install automatically for Azle and Kybra devs. These dependencies and extra build steps cause complications for our CDKs, if dfx can do it all that provides a really nice experience for us.