I don't think Rust will ever consider FFI'in with another language "100% safe."

You can use C libraries in Rust, even compiled .so files where you dont have the corresponding C headers.

> Using D code in Rust probably will be much more painful and I am not sure if it can be done 100% safely...

Can you elaborate? Saying it will be "much more painful" without anything further is not especially helpful. I've added D functions to C programs more or less trivially, including compiling to a shared library, with no change to the code.

Because I am not knowledgeable about D runtime I can not say that it will not cause any conflicts with Rust assumptions (thus the use of "probably"). For example, IIRC there are serious issues with integrating Go code into a Rust project. If D code is compiled in the betterC mode, then there should not be any problems.

You can link in and interop fine with C/C++ as long as you link in the D runtime, kind of how you can mix C and C++ by linking in libcxx.

D's betterC mode ensures that the binary can run purely on libc without D's runtime library. It's kind of like being able to link and execute C++ code without needing libcxx.

There are serious considerations for including Go code in a rust project, but it's not like there are any showstoppers - one just can't use the default runtime and must rely on Cgo, and the FFI entry points are not performant. Other than that, it's relatively painless. Far less painful than calling into the JVM IMO.

> Using D code in Rust probably will be much more painful and I am not sure if it can be done 100% safely

You can just as easily declare D code to be extern(C) and have rust treat it as a C library.