It can be made to function more like C with #![no_std]. However that is an even less than batteries included experience than C.
Rust is absolutely a C replacement.
Whether C heads want to use it is a more complicated question. But some are very much into it (e.g. Brian Cantrill).
> It can be made to function more like C with #![no_std]. However that is an even less than batteries included experience than C.
std assumes you have a heap and IO, which most C environments do.
no_std removes all that (leaving only libcore as baseline), however you can re-add a dependency on "alloc" to get allocations and most of the standard collections back (all but hashset and hashmap, because no secure RNG).
You can also / instead fill your needs with third-party crates more dedicated to restricted or freestanding environments, like heapless (https://crates.io/crates/heapless).
For example C's qsort lives in the standard library, whereas in Rust although [].sort() needs alloc, the [].sort_unstable() is a core feature!
str::split_once(['5', '7']) will split a string at the first digit 5 or 7... You need considerable work to do that in C, and doing it modifies the string. In Rust it's a core feature.
Of course Rust is relying on the fact that none of the machine code is emitted unless you use these features, indeed split_once is fully generic, the types used only come into existence because you called the function. So presumably this was not practical as the fundamental language for writing Unix fifty years ago.
I think we should avoid saying "replacement" in general because eliminating all lines of C isn't a goal worth pursuing, C doesn't need to die for Rust to succeed, and there's room enough in this world for a hundred safe systems languages fulfilling different niches. I think a lot of people feel attacked & invalidated by the idea of a "C replacement" that isn't C compatible, like we're telling them their skills are no longer necessary or valuable, which is untrue & leads to flamewars and misunderstandings.
(Of course some C projects could abuse the preprocessor in ways that make it infeasible to even replace a C function with a Rust equivalent, but that's incredibly rare. And Rust has macro facilities of its own.)
It's true that there is a path to integrating Rust into C projects and potentially replacing C in that project, I just see lots of threads on HN derailed by the statement "Rust is a C replacement", and I think using more nuanced language would help.
things.into_iter().skip(1).each(|wtf| { are_you_kidding(wtf) })?
Compared to a more reasonable language, like, say, Perl: map { do_something($ARG) } @things[1..$#things];[0] https://en.wikipedia.org/wiki/Safe_navigation_operator
[1] e.g. it doesn't have let..else, macros, raw-idents, complicated type signatures, turbofishes, ... which could make the code a lot weirder
If you read the perlvar perldoc (perldoc perlvar or https://perldoc.perl.org/perlvar), you will see it is the English form of $_. You just need to:
use English;Rust's #![no_std] mode corresponds to what C calls freestanding mode, and Rust is relatively unusual in many modern languages in actually designing some sort of freestanding mode.