I've heard about at least two languages that adore threads, and have issues with multi-processing. Perl6 has threads in its runtime helping its GC --- and calling fork kills its programs. I don't know yet if rust has threads _required_ in a fashion that makes it crash if you try to fork().
perl6 cannot fork; and golang behaves badly if you fork in a program that uses goroutines. Ends up unhappy, since shared library manipulation is kinda dependent on the process loader. Oops.
I'm tempted to hope that the Rust lang devs have kept use of threads out of its required runtime. To answer your question, I didn't mean to imply that rust cannot call fork(2), and I hope it isn't true. I meant to say that I wouldn't call Rust a C replacement; it's an effort to solve a problem (threads with shared heap or stack) that C flat doesn't attempt to consider. I love C, and feel obliged to learn Rust.
Rust has a very different design philosphy to c, and in that respect you are right that it isn't a complete replacement. That said, Rust is good for far more than just multithreading. It solves memory safety as well as tgread safety.
It can work but it’s quite unsafe. The standard library doesn’t make any guarantees about fork safety. The language itself doesn’t understand what fork is, and so can’t guarantee anything.