I don't see any reason why the same thing [1] could not be implemented in Rust.
EDIT: I got caught by an off-by-one there, the second fastest solution (doing JIT compilation) is actually [2].
I just enjoy dosing the Rusties with reality every so often.
If you write a Rust version that can beat the C version, I'll donate $500 to Watsi. Good luck!
Aka troll.
If it were, you'd claim the prize. If you really want to hurt a troll, wouldn't you try to separate them from their $500?
That's not what the quoted statement is doing.
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.
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.
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.
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.
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.
The RESF is a bad meme.
The recent Linux mutex security bug is an example. That's not a memory safety bug. Surely Rust doesn't help? But Rust's mutual exclusion design relies on the Rust type system to give us safer locks, in Rust you protect things by having "lock the mutex" be the way you get the reference to the protected object. Thus when the faulty code locks the wrong mutex in Rust it would get the wrong object, and either not compile (you lock variable A and then you're trying to change B but you don't even have B) or not work (you always lock variable A, then change variable A, but your code should change B, it does not work, trivially reproducible bug in your code)