Please don't get me wrong - I would take safe over non-safe if everything else were equal. It's just that Rust made many other choices that are worse for me than what's in C++. Also, I think it would be very painful trying to explain some of Rust's features to my coworkers (who are generally very smart, but generally not interested in clever programming languages).
> It's that it's really expensive to revisit old assumptions when circumstances change, [...]
That's very dependent on the type of work you do. Over the last 23 years, my job has been to write many small programs to solve new problems. It's not expensive for me because I've aggressively avoided making monolithic baselines. I have medium sized libraries that I drag from project to project, but I can fix or rewrite parts of those as needed without breaking the old projects.
> That's very dependent on the type of work you do.
True, if your code never gets big or old, you can keep all of it in mind and write correct code without too much worry. Though in my experience, it really doesn't need to be very old or very big before tooling starts paying big dividends.
> I have medium sized libraries that I drag from project to project
I'd wonder in particular about those libraries. Certainly you know more about your context. But I expect that there are both contexts where it wouldn't be helpful, and also contexts where it would be substantially helpful but authors don't know what they're missing. I don't have a way of distinguishing the two here.
I think it's a misconception to classify type-safety and memory-safety techniques as 'clever', they should be seen as the bread-and-butter of day-to-day coding. To put it another way, Rust's memory safety is no more clever than C++'s smart pointers, the only difference is what people mistakenly believe about the two.
> I think it's a misconception to classify type-safety and memory-safety techniques as 'clever'
I didn't call Rusts type-safety of memory-safety clever. The clever stuff is lifetime specifications, a multitude of string types, traits as indications to the compiler for move vs copy, Box Ref Cell RefCell RefMut UnsafeCell, arbitrary restrictions on generics, needing to use unsafe code to create basic data structures, and many other things.
If I tried to advocate Rust in my office, many of my coworkers would simply say, "I didn't have to do that in Fortran, and Fortran runs just as fast. Why are you wasting my time?!"
Almost everything you mentioned as 'clever' is trying to achieve either type-safety or memory-safety. To your coworkers I would reply: would you like the compiler to handle error-prone memory deallocations? Or do you want to keep doing it manually and wait till runtime to find potential mistakes?
I don't believe those clever things are necessary for safety or performance. I think many of them are incidental and caused by a lack of taste or just a disregard for the value of simplicity. Rust deserves credit for it's good ideas, but these aren't those, and I believe there will be other high performance (non-GC) languages that are more accessible to non Computer Scientists [1].
> To your coworkers I would reply: would you like the compiler to handle error-prone memory deallocations? Or do you want to keep doing it manually and wait till runtime to find potential mistakes?
They don't really care about memory deallocations - the program will finish soon anyways, and the operating system will cleanup the mess. Sorry, they've already excused you from the office and have gotten back to getting their work done.
Btw, modern C++ programmers don't worry about memory deallocations either. You should find a better bogeyman.
> I don't believe those clever things are necessary for safety or performance. I think many of them are incidental and caused by a lack of taste or just a disregard for the value of simplicity.
Well, I just re-read your list of 'clever' features, and can't really see how any of them is incidental, or in fact how some of them are worse than the exact same features in Swift, which you mentioned.
> ... I believe there will be other high performance (non-GC) languages that are more accessible to non Computer Scientists....
Not sure what to make of this comparison, given that Rust beat Swift in the majority of the benchmark tasks. Also, you have to look at the quality of the compilers themselves. Rust is universally acknowledged to be a high-quality compiler, while Swift (especially together with Xcode) are often bemoaned as buggy and crashy.
> They don't really care about memory deallocations ... the operating system will cleanup the mess.
Well, I have to say they are an extremely lucky bunch. Most systems programmers don't have the luxuxy of writing script-sized programs which use the OS as their garbage collector.
> Btw, modern C++ programmers don't worry about memory deallocations either. You should find a better bogeyman.
I was specifically replying to your Fortran example, but for the sake of argument, to C++ programmers I'd ask, 'Would you like to do high-performance concurrency with statically guaranteed no data races?'
There are two string types in Rust, `String` (growable and heap-allocated) and `&str` (a reference to string data). Anything else is just a shim for FFI.
> There are two string types in Rust, `String` [...] Anything else is just a shim for FFI.
I guess I don't have to worry about the non-Scotsman strings then... You've heard the criticisms about Rust's strings before, and I'm unlikely to tell you anything you don't know.
I think it's especially hasty to criticize Rust's string types in the context of C++, given the standardization of string_view in C++ as an analogue of Rust's &str :P
To me, Rust's &str seems a lot more like const char* (with a size tacked on for bounds checking). But you're the expert, so if I did agree they were the same, then C++ adopting it in the STL is practically proof it's a mistake in Rust.
You never addressed my other "too clever" items in Rust. Does that mean, other than strings, we agree?
> It's that it's really expensive to revisit old assumptions when circumstances change, [...]
That's very dependent on the type of work you do. Over the last 23 years, my job has been to write many small programs to solve new problems. It's not expensive for me because I've aggressively avoided making monolithic baselines. I have medium sized libraries that I drag from project to project, but I can fix or rewrite parts of those as needed without breaking the old projects.