... is due to C++ jumping the shark. The latter is so complex now that no one who has other things to do in life can spend enough time to learn the language & library functionality and the increasingly esoteric syntax to a point that you can approach most modern C++ code without going WT actual F? I've been doing C++ for 25 years and it's how I earn my living (along with some Python and straight C) , but if I was starting out today I wouldn't go within a mile of itm I'd probably head towards Rust too after I'd learnt C.
I've been learning Rust and in some ways find it a little annoying with formatting warnings in the compiler. let my_result = ( my_variable == 1 ) -> produces a warning that parenthesis are unnecessary (didn't run this through the compiler so I think the "code" is written correctly). Sure they are unnecessary but to my eyes this makes it much easier to read that what is being assigned is the result of a comparison, without the parenthesis I'd have to read the line more closely.
At the same time the compiler errors can be very informative. I was somewhat abusing the parse method to parse a terminal string into an int by using unwrap_or after the parse. I was assuming that unwrap_or was just returning the parsed value, but I was getting errors when I tried accessing the original parse error after calling unwrap_or. Turns out the parse's ownership is actually transferred to unwrap_or (something like the unwrap_or clears out the error indicator from the original parse I think it might be?) and the parse result is no longer valid after the unwrap_or call. I should have probably just stored the parse result and checked if it was Ok or Err, but I tend to expect a status variable on either success or fail, and the corresponding result value is only valid if the status is valid. Regardless of my thoughts on how unwrap_or works, the Rust error was very informative that I was abusing how the language worked.