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).
You get a lot more in core (and thus no-std) than the free standing C language.
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 you & GP are using different senses of replacement ("drop in replacement" vs. "replacement for greenfield projects"). You might consider Rust to be the latter (with qualifications, eg, excluding certain architectures & proprietary programming environments) but it's explicitly not the former (it's interoperable with C, but not compatible with C).
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.
Rust is absolutely a "drop-in" replacement to C in most cases even for existing projects, it was absolutely built with that goal in mind. You can go as fine-grained as replacing a single function with a Rust-coded version (even using bindgen to ingest existing C headers) - though that generally involves unsafety because you're dealing with general pointers, extern calls and such. Even Checked C cannot prove these things 100% safe, it just catches common misuse.
(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.)
We're using different senses of "drop in", it's a bit of a vague term. Rust is interoperable with C (it can do C FFI) but it is not compatible with C (C code is not Rust code and Rust code is not C code). Compare this to a language like Carbon or C++; that is what I'd call a "drop in replacement", because they are compatible, using the definitions I've provided. If FFI were sufficient, Python would be a "C replacement."
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.
By that standard, Carbon is not compatible with C or C++, and neither is Cppfront. One could argue that C-style uses of pinned data or possibly-aliased pointers are not idiomatic in Rust and are a pitfall for interop with the Safe subset; nonetheless these uses can be expressed in the language.
"Perl" and "more reasonable language" don't belong together. It's a complete oxymoron. The Rust syntax is entirely compositional, other than the || delimiters (which introduce a fresh binding to the subsequent block), and the ? which involves abnormal control flow.
I assume GP posted ironically because the Rust snippet is mostly pretty bland function and method calls, the only weird-ish bits are the postfix "?" (which have become very common[0]) and the block syntax[1], while they're using 3 different sigils in a Perl snippet I'm not even sure makes sense (though it's probably valid because perl) e.g. from what little I've retained of perl (against my will) "@ARG" is an array with the command line arguments, $ARG does not exist, this just passes `undef` repeatedly to `do_something`.
> 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'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.
