When Rust hurts
&gt; Remember that paths are raw pointers, even in Rust. Most file operations are inherently unsafe and can lead to data races (in a broad sense) if you do not correctly synchronize file access.<p>This is a reality that our operating systems have chosen for us. It&#x27;s bad. The way Unix does filesystem stuff is both too high level for great performance, and too low level for developer convenience and to make correct programs easy.<p>What would it look like to go higher level? For example:<p>- Operating systems could support START TRANSACTION on filesystem operations, allowing multiple operations to be performed atomically and with isolation. No more having to reason carefully about which posix file operations are atomic, no more having to worry about temp file TOCTOU etc.<p>- fopen(..., &#x27;r&#x27;) could, by default, operate on a COW snapshot of a file rather than on the raw file on the filesystems. No more having to worry about races with other processes.<p>- Temp files, like database temp tables, could by default only be visible to the current process (and optionally its children) or even the current thread. No more having to worry about temp file races and related issues.<p>That sort of thing. Maybe implemented like DBOS: <a href="https:&#x2F;&#x2F;dbos-project.github.io&#x2F;" rel="nofollow">https:&#x2F;&#x2F;dbos-project.github.io&#x2F;</a>. Or, you know, just get rid of the whole idea of processes for server-side applications. Was that really a good idea to begin with?<p>&gt; However, if the locks you use are not re-entrant (and Rust&#x27;s locks are not), having a single lock is enough to cause a deadlock.<p>I&#x27;m a fan of Java&#x27;s synchronized, and sometimes wish that Rust had something higher-level object-level synchronization primitive that was safer than messing with raw mutexes (which never seems to end well).