4 ms·

Advanced Rust macros with derive-deftly

21 points by todsacerdoti 1y ago

akkad33 1y ago
Rust macros are hard for me to use and understand. It makes my ide go berserk and all the curly brackets and indentation make them hard to write
CJefferson 1y ago
If the author reads this, maybe for that first macro add an implementation without your package? I don't really know how hard this is to write "straight".
dochtman 1y ago
IIRC derive and attribute macros via declarative macro definitions are coming soon, which probably obviates this? https://github.com/rust-lang/rust/issues/143549 https://github.com/rust-lang/rust/issues/143549
jph 1y ago
Rust macros have so much power, yet with complexity to learn and use. IMHO your derive-deftly is finding a good balance between the power and complexity-- it's pragmatic and immediately useful. This is excellent that you're creating this crate and sharing it. I know your company Pipedream and admire what you're doing there too.
zamalek 1y ago
I like this, only, what are compilation times going to be like?
- echelon 1y ago
  I'm really starting to hate on Rust macros due to the compilation times. The core language is fine, but macros are the mind killer. We're progressively banning macro usage from our Rust monorepo. Macro-heavy dependencies are also going to be pruned eventually. As much as I love Serde, it makes compile times for projects like async-stripe absolutely productivity killing. It interferes heavily with work. Crates.io would be fantastic if it had compile time metrics and macro metrics reported for projects and dependencies.
  - huhlig 1y ago
    I guess it depends on which is more important to you. The compile time cost and runtime savings of compile time reflection, or the compile time savings and runtime cost of runtime reflection. You're going to pay the fee one way or another. I personally prefer compile-time cost as I pay it once.
    - jtwaleson 1y ago
      I understand what you mean but "pay it once" is the wrong description for something that you do hundreds/thousands of times per day as a developer. Every time I save a file in my IDE, the Rust checkers run and are very slow.
      - zamalek 1y ago
        Make sure you tell rust-analyzer to use its own profile (<init_options>.rust.analyzerTargetDir=true). This means rust analyzer and your IDE will have different target dirs (target/debug and target/rust-analyzer), this can prevent flagging resulting from cargo and rust-analyzer fighting over the features etc. I have this set at system/global level in my IDE config. The downside is that you'll use double the disk space.
        jtwaleson 1y ago
        Omg, I've been thinking about how to achieve this. Feel a bit stupid reading it's a standard option.. Thanks! Since earlier this year I've upgraded my hardware, I'm on the wild linker, the Cranelift backend and I've switched from cargo clippy to cargo check for the rust analyzer (with clippy running under a shortkey and as pre-commit). I have a backend and frontend for my project, and the typescript frontend with its sub-second feedback cycle definitely helps for staying in a flow-state. With all of the improvements above, rust is still at 3 to 10 seconds.
  - zamalek 1y ago
    I have tried setting the build dependencies optimization level to higher-than-default in the past, but it seems to achieve nothing. [profile.dev.build-override] opt-level = 3 codegen-units = 1 [profile.dev.package."syn"] opt-level = 3 codegen-units = 1 [profile.dev.package."synstructure"] opt-level = 3 codegen-units = 1 [profile.dev.package."quote"] opt-level = 3 codegen-units = 1 # CTRL+C when it reaches async-stripe, then repeat > rm -r target/debug/build/async-stripe*; time cargo build default, O1, O2, O3: Executed in 47.13 secs Executed in 45.68 secs Executed in 46.07 secs Executed in 46.22 secs sccache will provide a major benefit, especially in combination with `cargo-hakari`.

21 points by todsacerdoti 1y ago

Rust macros are hard for me to use and understand. It makes my ide go berserk and all the curly brackets and indentation make them hard to write

CJefferson 1y ago

If the author reads this, maybe for that first macro add an implementation without your package? I don't really know how hard this is to write "straight".

dochtman 1y ago

IIRC derive and attribute macros via declarative macro definitions are coming soon, which probably obviates this? https://github.com/rust-lang/rust/issues/143549 https://github.com/rust-lang/rust/issues/143549

jph 1y ago

Rust macros have so much power, yet with complexity to learn and use. IMHO your derive-deftly is finding a good balance between the power and complexity-- it's pragmatic and immediately useful. This is excellent that you're creating this crate and sharing it. I know your company Pipedream and admire what you're doing there too.

zamalek 1y ago

I like this, only, what are compilation times going to be like?

echelon 1y ago
I'm really starting to hate on Rust macros due to the compilation times. The core language is fine, but macros are the mind killer. We're progressively banning macro usage from our Rust monorepo. Macro-heavy dependencies are also going to be pruned eventually. As much as I love Serde, it makes compile times for projects like async-stripe absolutely productivity killing. It interferes heavily with work. Crates.io would be fantastic if it had compile time metrics and macro metrics reported for projects and dependencies.
- huhlig 1y ago
  I guess it depends on which is more important to you. The compile time cost and runtime savings of compile time reflection, or the compile time savings and runtime cost of runtime reflection. You're going to pay the fee one way or another. I personally prefer compile-time cost as I pay it once.
  - jtwaleson 1y ago
    I understand what you mean but "pay it once" is the wrong description for something that you do hundreds/thousands of times per day as a developer. Every time I save a file in my IDE, the Rust checkers run and are very slow.
    - zamalek 1y ago
      Make sure you tell rust-analyzer to use its own profile (<init_options>.rust.analyzerTargetDir=true). This means rust analyzer and your IDE will have different target dirs (target/debug and target/rust-analyzer), this can prevent flagging resulting from cargo and rust-analyzer fighting over the features etc. I have this set at system/global level in my IDE config. The downside is that you'll use double the disk space.
      - jtwaleson 1y ago
        Omg, I've been thinking about how to achieve this. Feel a bit stupid reading it's a standard option.. Thanks! Since earlier this year I've upgraded my hardware, I'm on the wild linker, the Cranelift backend and I've switched from cargo clippy to cargo check for the rust analyzer (with clippy running under a shortkey and as pre-commit). I have a backend and frontend for my project, and the typescript frontend with its sub-second feedback cycle definitely helps for staying in a flow-state. With all of the improvements above, rust is still at 3 to 10 seconds.
- zamalek 1y ago
  I have tried setting the build dependencies optimization level to higher-than-default in the past, but it seems to achieve nothing. [profile.dev.build-override] opt-level = 3 codegen-units = 1 [profile.dev.package."syn"] opt-level = 3 codegen-units = 1 [profile.dev.package."synstructure"] opt-level = 3 codegen-units = 1 [profile.dev.package."quote"] opt-level = 3 codegen-units = 1 # CTRL+C when it reaches async-stripe, then repeat > rm -r target/debug/build/async-stripe*; time cargo build default, O1, O2, O3: Executed in 47.13 secs Executed in 45.68 secs Executed in 46.07 secs Executed in 46.22 secs sccache will provide a major benefit, especially in combination with `cargo-hakari`.