In my experience, the compile process usually consists of "cargo build"

A advantage of Rust is that usually you spend way less time debugging, because the compiler prevents many mistakes from compiling in the first place.

Regarding compile times, Rust has a different approach. Instead of a fast cycle of run and see if it broke, it's more of following compiler nags until the program is correct and runs on the first try. Incremental (cached) compile times aren't too bad these days.

Needless to say I didn't restrict myself to pass-by-value (compatible -> structs with ptrs are problematic as well) style, which seems quite restrictive

I don't have a similar evaluation for C <-> Rust, but I suspect the result would be even more skewed in Rust's favor: sure, you might be writing individual lines faster in C, but the lack of iterators, generics, traits and RAII, and the relative difficulty to use dependencies means that you will waste a lot of time reinventing the wheel, often suboptimally.

The eventual rust code+debug+maintain speed will be higher than the equivalent C speed, for the same reason.

This means that rust is slower for vanity projects that won't be used in practice, or for low quality products with an attitude a la hack it- ship it - hide for customers - start next mess. The scary part: this is actually an existing corner of our market.

I have many years of experience in both, and I can confidently say that for experienced programmers Rust is both quicker than C to get something useful working, and to get projects polished and production-ready.

Rust has a useful standard library (compared to C). You have hashmaps, btrees, or vectors with lots of helper methods all available in less than it takes to hand-roll a linked list.

Rust has lots of high-level crates that you can leverage. You need to fetch some JSON? It's a few lines of code to get it into a native struct, type-checked for you. You can have it running in less than it takes to craft a Makefile.

Rust is also productive for robust code. You don't fiddle with malloc, so the whole `goto cleanup` code is gone, and you don't spend any time chasing memory corruption, leaks, or unexpected NULLs. And these are often static guarantees, not something to fuzz out of a stanitizer.

If you need code to be multi-threaded, it can be as easy and high-level as OpenMP, but you get a compile-time guarantee of no data races, even in 3rd party code you use. Some errors pointed out by the Rust compiler have saved me what could have been weeks of heisenbug debugging.

It's normal that you move slower when writing an unfamiliar language, and Rust certainly has a steep learning curve. But once you learn it, Rust feels closer to high-level scripting languages than C.

That said, cargo check is fast, and my general experience with Rust is that it generally works once it compiles. People getting into more advanced features might have different experiences.

1. A flash download is not involved

2. I hardly debug. I seem to be in a minority here, but my linter really does catch pretty much everything. I don't blindly write code, I always ponder my approach first.

So basically, the compile times pull me out of the flow.

One trick I like is to have a 2nd terminal watching the file(s) I'm editing, triggering a make/run on each save; building and running is then a single keypress away:-

  while [ 1 ]; do
  inotifywait -e move_self foo.c
  cc foo.c -o foo && ./foo # or 'make && ./foo'
  done