"[Other safe languages] require complex runtime support that doesn't fit in certain contexts (e.g. kernels)."
Complex runtimes are also unsuitable for libraries. If you write a great openssl replacement in Haskell, it's only useful for Haskell applications. Because nobody wants to link the Haskell runtime into many of the applications that use openssl.
For widespread libraries, the choices are basically C, C++, and now (hopefully) rust.
Which is "for widespread libraries, the choices are basically C, C++, and now (hopefully) rust.": as in C++ you can use high-level constructs internally without relying on an extensive runtime, and expose and easy-to-FFI C interface.
Rust still has insufficiencies though, the inability to customise the (library's) allocator is one I think.
Does the custom allocator support allow for runtime customisation e.g. the library user calling it to set allocator functions then starting to use it? And I expect the custom allocator is global?
Currently, it replaces the global allocator. Using multiple allocators is an interface that's still being actively worked on, it's in the RFC stage, so no code has landed yet.
Complex runtimes are also unsuitable for libraries. If you write a great openssl replacement in Haskell, it's only useful for Haskell applications. Because nobody wants to link the Haskell runtime into many of the applications that use openssl.
For widespread libraries, the choices are basically C, C++, and now (hopefully) rust.