At least, compiling is always straightforward. With C, there's a good chance the build will fail for whatever reason (e.g. your OS missing some header files).

Yep, IME rust makes contribution easier because I generally don’t need to hunt for setup instructions which may or may not exist and may or may not work for my system.

And the compiler at least attempts to tell me what’s wrong when it fails to compile (and give suggestion though that is very hit or miss for non trivial case).

The one case where the compiler is singularly unhelpful is when trying to hunt down why a future is !Send tho.

I feel like you could stand to qualify "fun" more here. I don't share your experience - I'll take a Rust project any day - but I'm curious to know what you feel is missing.

(Outside of compile times, which are a well known point)

There’s no reason you couldn’t have a rust jit for development then compile the code for production (or stick with a jit for prod too).

There's no reason? Are you sure about this?

I think you mean there could theoretically be an interpreted Rust, but I don't think anyone has ever made a prototype of a Rust interpreter.

The closest is probably rust-analyzer (the official language server), that maintains internal state and reacts to changes you make, but it doesn't create an executable artifact.

The other is probably the Cranelift Backend (https://github.com/rust-lang/rustc_codegen_cranelift), which can produce debug builds quickly.

I meant no reason from a technical point of view. People might say most of the compilation time is spent in the type/borrow checker, but that's orthogonal. You can JIT potentially incorrect code and postpone static checks for a later time (or run them in parallel).

The cranelift backend itself has a JIT mode.

Honestly it would probably be even faster than unoptimized aot compolation

Some developers need/are used to a fast edit-compile-run loop. The JIT doesn't even need to be optimized, just good enough to improve the developer experience.

What were you waiting on? You shouldn't have run cargo build every change. And cargo check shouldn't take that long.

This is a sort of odd phenomenon, but I've noticed that the Rust software I'm developing professionally is never actually getting run before it's pushed to production. We have some unit tests and run those, and if that's fine then into prod it goes. It's honestly a bit insane when I think about it, but it works...

cargo check will take long once you use macros. And now the advice changes to "well you shouldnt use that many macros", and a new criticism will be made, followed by "well you shouldnt....." and a new...

I dont think this wont even work for most kind of programming. I always do an edit-compile-run cycle when im programming, or I break everything to .so and dynamically reload as much as possible. Very easy with C++ and C.

I am waiting on zig and its in place binary patching. But just saying that you should cargo check instead of running and seeing with your eyes if your change made sense or not or is affecting perf or not is....ridiculous.

I think this kind of development flow works better when you are writing already solved solutions or rewriting code. How on earth are you gonna cargo check a perf issue, or a game or memory leaks???

The fact that i got downvoted says it all, people are in delusional mode

Zig devs are tackling the issue early, Rust devs are living with it, it's just sad

adding to this, People that say cargo check is the answer dont even understand the problem at hand.

Just because the language is compiled does not mean it needs to take 30 business days to compile something.

You can have fast compile times and good performance too. SBCL the common lisp implementation is extremely famous in these circles for its performance. IT IS A BATCH COMPILED LANGUAGE WITH A REPL!!

You cannot use cargo check for perf issues, for memory leaks, for trying to solve a problem that does not have a solution...etc etc.

Even then cargo check will make you bleed if you use macros.