C's unsafety is a common concern, and a common reason to look for alternatives. The subject is debatable, as language comparisons tend to be in general, but here I document my perspective and observations.
The features of C I look for in alternatives:
curl |
sh, inventing its own package management, requiring
nightly builds of everything, etc.Features that C lacks, but are desirable and compatible (to some extent) with its existing features:
cargo), but even using the compiler
(via rustc) from system repositories results in
failures to install most packages, since they tend to aim the
latest version, and there is no dependency resolution. While
the standard library is not quite sufficient even for
relatively basic tasks without additional packages (e.g.,
there is no concurrency without multithreading, unless you use
in-place FFI to access C libraries, but then the code will be
more messy than usual). Idiomatic asynchronous APIs aim
Rust-only sources, not to be called via C FFI. This breaks the
"POSIX-friendly" and "availability" features present in C,
though they could have been preserved, and it has more to do
with the infrastructure than the core language. Related: Rust
without crates.io. Though some libraries (crates) are rather
lightweight, the difference in the numbers of dependencies of
similar ones can be two orders of magnitude
(e.g., argparse has no dependencies, while the
more popular clap pulls 156 additional
packages). Or one can add dependencies using
the --precise option, first finding a version
compatible with an older rustc version on
crates.io, and manually resolve all the dependency versions so
that they work together, doing the package manager's job. The
package index updates are very slow, usually taking about 10
minutes here (though maybe less if used often).