"No so easy to use" does not mean no re-use. For this reason I really like how Elm interacts with JavaScript. The language requires to define so-called ports th

"No so easy to use" does not mean no re-use. For this reason I really like how Elm interacts with JavaScript. The language requires to define so-called ports that provide explicit bindings to-from JS world. Thus it is not worth the efforts to call into JS function that does some trivial stuff. But interacting with bigger libraries is straightforward. As a big bonus guarantees of Elm's type system survive interaction with those libraries (unless the JS code in those libraries is malicious), so one does no need to know the details of those libraries to reason about Elm code. Note that from this point of view rewriting C runtime library in Rust is not good as it creates too tight coupling between C and Rust worlds, requiring to write in a rather unnatural style in Rust. Besides, a lot of Musl essentially translates C calls into kernel ones when Rust typesystem brings no advantages.