Reducing boilerplate code

[mmagician]

To compile even a simple program, a lot of boilerplate is needed, e.g. for the counter contract:

#![no_std]

#[global_allocator]
static ALLOC: miden::BumpAlloc = miden::BumpAlloc::new();

#[cfg(not(test))]
#[panic_handler]
fn my_panic(_info: &core::panic::PanicInfo) -> ! {
    loop {}
}

bindings::export!(IncrementCounterNote with_types_in bindings);

mod bindings;

use bindings::{exports::miden::base::note_script::Guest, miden::counter_contract::counter};
use miden::*;
<only now starts the actual logic>

Looking through some other projects in the space and how they handle compilation from high-level languages, I came across the Leo tutorials: https://www.youtube.com/watch?v=PM_NBNti9H0
where writing Rust-like language requires almost no boilerplate (I assume they need to do similar things as here but that are handled under the hood). It would be amazing to provide a similar experience for Miden.

[bobbinth]

Somewhat related to this, do we have somewhere a high-level description of the "end state" that we want to get to eventually? There were some examples in #12 and #333 (and maybe somewhere else), but I think they are quite obsolete by now.

Would be great to sketch out how we think writing accounts, notes, and tx scripts could look like long-term.

cc @Dominik1999 and @huitseeker.

[greenhat]

I think the latest was @bitwalker proposing a user-facing interface trait (#[interface]) + #[component] pattern so users write “normal” methods (self-based) while generated code wires them to the Guest trait - #436 (comment)

We also have #336

[greenhat]

The following, largest part of the boilerplate will be hidden behind our macro for sure:

#[global_allocator]
static ALLOC: miden::BumpAlloc = miden::BumpAlloc::new();

#[cfg(not(test))]
#[panic_handler]
fn my_panic(_info: &core::panic::PanicInfo) -> ! {
    loop {}
}

bindings::export!(IncrementCounterNote with_types_in bindings);

mod bindings;

I foresee the greatest challenge for our builders will be working with the WIT interface being the source of truth in the Wasm Component Model (CM), i.e. from which the Rust bindings (mod bindings for bindings.rs) are generated. We could explore the idea of generating the WIT interface from our macros. This would create a Rust -> WIT -> Rust workflow and I'm not entirely sure if it would be easier to work with.