I think the author is correct about the compile / test ratio being drastically shifted in rust vs other languages. One thing to have in mind regardng this, is that in larger companies testing may be performed by a dedicated team. Hence, a shift to rust will give the impression of a much higher workload for the developers. In reallity the workload should be pretty much the same since the bugs from testing still needs to be fixed, but that will be spread out over a larger time span due to going by the test team first.

The first figure showing color-coded effort is close, but I would say Rust’s blue “business logic” portion should be smaller. Pattern matching and linear data types can encode a state machine so much more accurately than C. You’re more likely to get the business logic right the first time if you know what patterns to use.

Man, this might even motivate me to stop putting it off and just jump on the train.

Some of this applies to Go too. But it has easier learning curve to begin with.

I think this article is spot on. A lot of people I know were turned off from Rust because the compiler was so much stricter than what they were used to, which tends to frustrate experienced devs quickly, in my experience. But it’s not that the compiler is overly strict; the errors it catches would almost always become problems later. It’s just that reducing the number of compile-time errors doesn’t feel like progress as much as reducing the number of run-tine errors, because you haven’t actually run the program successfully.

Once you use Rust for a long time, you adapt to the compiler and can get things to compile much quicker. That’s where the satisfying part of programming in Rust comes. You get to where you write code and it just works, first try.