I think we'll have to agree to disagree. It's illustrative that a seemingly simple C program can't be easily ported to Rust. If it could be, someone would have already done it -- it's been a few hours.
It's also illustrative to examine exactly what the hangups are. You might even get more Rust converts if you acknowledge that there are serious engineering burdens to overcome when deciding to use Rust.
For the record, it's not the anti-Rust sentiment which people find annoying, it's the treatment of programming languages as though they were football teams.
If you want to make a case against Rust, then let's get concrete: why is one Turing-complete compiled language that can make arbitrary syscalls not capable of compiling down to the same assembly as another?
That would be an interesting discussion; this is not.
You can dig into it, but the details are mostly only relevant to people designing computer languages and tooling.
Aka Compilers, as long as the machine code is equivalent to the source code their output can be wildly different. However, someone needs to actually write them which means both linguistic differences and the sheer effort that was actually put into the compiler are both significant. You shouldn’t assume that every language is operating on an even playing field because their simply not. The obvious solution of compiling to a second language is never quite as capable as using the language directly.
> Compilers, as long as the machine code is equivalent to the source code their output can be wildly different
I don't understand what this means: the output of a compiler is the machine code from the source code, no?
Also, Rust uses LLVM as a backend, which has benefited from lots of work given its use for C, C++, ObjC, Swift, &c. Compiling the C with Clang/LLVM might give a more interesting insight into the differences between Rust and C.
> The obvious solution of compiling to a second language is never quite as capable as using the language directly.
I'm not sure what you mean by this, or rather how it's related to what we're talking about?
You get different machine code using different compilers on identical pieces of source code. In theory the results of running that source code should have equivalent results even if one is more efficient than another. If for example one compiler uses a ASM instruction that another never uses then nothing the programmer does can get the second compiler to be as efficient as the first. The same is true of various optimizations etc, sometimes a compiler is just better.
Bring a different language into the picture and things get even more divergent.
> how it’s related
It’s specifically in reference to rust use of LLVM not being sufficient to guarantee equivalence. Many languages target the JVM, that does not make them equivalent.
> You get different machine code using different compilers on identical pieces of source code.
Ah, right - well I'm certainly not denying that. (I'm familiar with the topic, to be clear: I've written compilers. I just wasn't clear what exactly you were saying.)
> It’s specifically in reference to rust use of LLVM not being sufficient to guarantee equivalence.
Formally, no. In practice, given that fact, given the experience of the maintainers of both languages, and given the 'compilability' of both languages, it would be surprising if there were a 10x gulf between them.
That's not what the quoted statement is doing.