I care to disagree. I'd much rather fight with my compiler than play the game of "oops, I segfaulted, let me recompile with -g so I can rerun with gdb so I can figure out where I crashed." Or more minor stuff, like trying to track down which header file actually contains the implementation of, say, struct mcontext_t so I can remember how to set the value of RSP in a signal handler.

I've grown to enjoy the Rust programming far more. Having a language, and associated tooling, that's woken up to the 21st century is far more enjoyable. (Really, why is it acceptable that a major language in 2023 still defaults to providing absolutely no diagnostic information on a fault?)

Clearly that's a matter of taste. The popularity of rust shows that some people prefer writing it to writing C or C++, otherwise they'd just write C or C++. And yeah, personally I'd rather spend time fixing compile time errors, directly in the editor as I type, than hunting segfaults with gdb later.

Personally — and I know this isn't a good philosophy for secure software, I'm just commenting purely on the enjoyability aspect — I much prefer the logic game of hunting memory errors over the frustration of one of my tools refusing to do what I'm telling it to do.

Fighting with the compiler just means you have the wrong frame of thinking. Once you learn how to express things in ways that are verifiably safe, there is no fighting because you’ll get it mostly correct the first time.

I agree, but I think you should then look at SPARK2014 [1]. Rust just has better marketing and a bigger company behind it, but SPARK2014 is simpler and has been delivering Rust's bullet list for almost 10 years.

[1] https://www.adacore.com/about-spark

Why on earth did they add 2014 to the name? It’s like putting an expiry date on it before it even takes off.

It is more a version thing, and I always put it in the name to differentiate from Apache's Spark. That and the all-uppercase letters.