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 2 days ago | parent [-]

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 2 days ago | parent [-]

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 a day ago \| parent [-]
		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.