What is "it" here which you believe has been advised against? Please try to be specific.
> As for data races, great that it fixes data races among threads
Yes, it is pretty good. It was pretty great the last few times you "forgot" about this too.
"In addition, unsafe does not mean the code inside the block is necessarily dangerous or that it will definitely have memory safety problems: the intent is that as the programmer, you’ll ensure the code inside an unsafe block will access memory in a valid way."
Although it appears I stand corrected in regards to Rustonomicon, as it seems to adopt the position that unsafe should apply to more than memory corruption bugs and failed to find the sentence I was looking for.
> Yes, it is pretty good. It was pretty great the last few times you "forgot" about this too.
I never forget about it, from my point of view they are oversold, and will keep arguing they aren't enough for distributed computing deployment scenarios with heavy use of acess to process external shared resources.
Fearless concurrecy isn't something I care about when accessing database rows from multiple threads across database connections, writing to NUMA regions across process and so forth, shared storage,....
Races are still bound to happen in such scenarios, if care is not taken, and fearless concurrency is of little help in such cases.
As for data races, great that it fixes data races among threads, yet it does nothing against shared resources in distributed computing, which are what really matter in the age of microservices and protection against spectre like attacks.