This sentence hits an interesting point that I want to emphasize.
There is two types of complexity, native to language (what you called “complex rust paradigms”), and hiding it behind a lot of code generated in a macro (what you called “behind the scenes code”).
Two nice examples of the former are:
- a trait that has been mostly auto-implemented, and you finish it by providing the rest of the the items.
- By implementing a single trait on your type, you get access to lot more functionality by a lot of blanket implementations provided by FRAME.
These are good abstractions. If you find these hard, or want less of them, I would (opinionatedly) say that FRAME and Rust is not the right tool for you.
But the latter type, the bad abstractions, are those that generate too much code that you cannot even see behind the curtain. The old decl_xxx macros were the best example of this anti-pattern.
Even if there is going to be code auto-generated, the macro syntax should resemble real Rust abstraction sufficiently to make the code understandable.
Derive macros are an example of this. They do generate some code under the rug (as @tomaka phrased it), but are they bad? I don’t think so.
The best example here, in my opinion, is the existing construct_runtime. See this suggestion of how it can be simplified, and made easier to reason about, compared to the existing one. It is still a macro, it still generates code, but, under a more transparent rug, so to speak.