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".
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.
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.
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.
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.
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.
IIRC derive and attribute macros via declarative macro definitions are coming soon, which probably obviates this?
https://github.com/rust-lang/rust/issues/143549
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".
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
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.
I like this, only, what are compilation times going to be like?
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.
I have tried setting the build dependencies optimization level to higher-than-default in the past, but it seems to achieve nothing.
default, O1, O2, O3: sccache will provide a major benefit, especially in combination with `cargo-hakari`.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.
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.
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.
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.