I have been told that Rust is both safer and faster than C++. If that is true, how can that be even possible? I mean, a safer language means that more code is written inside the compiler, right? More code means more instructions for the processor to process.
In this case, I'm thinking about arrays. In C and C++, you can violate the range without any errors or warnings. You only get garbage values back. But in Rust, the compiler won't compile the program.
No, I'm not a Rust user. I'm a C user.
You seem to have quite a bit of misconceptions, which I'll address alongside your question. If anything is still unclear, please feel free to comment on this answer so I can address it
Yes, Rust is safer.
Safety is one of Rust raison d'être, after all. Specifically, outside of unsafe blocks, Rust is memory safe and type safe, that is:
Furthermore, a number of operations that would be Undefined Behavior in C or C++ have well defined semantics in Rust instead, such as signed integer overflows.
Memory Safety -- which underpins Type Safety -- is generally further split into two categories:
Rust achieves Temporal Safety by compile-time checks. This does mean a bit more code in the compiler1, but there's no run-time footprint -- whether memory or instructions -- so it's "free" at run-time.
Rust achieves Spatial Safety with a combination of library-provided abstractions, and run-time checks. For example, iteration in Rust is achieved by for x in collection. For an array this boils down to pointer increment -- just like in C or C++, so no run-time overhead -- except that since the user doesn't manipulate the pointers directly, it's safe.
Apart from that, there are various run-time checks: bounds-checks for index access2, null-checks for Option, etc... those may or may not be optimized, and thus may lead to a slight run-time overhead. The "trick" of Rust, however, is that if performance really matters (as profiled) and the optimizer is not managing to optimize well-enough, it's always possible to try and massage the code (front-loading a bounds-check, for example) or in the worst case to delve down to unsafe Rust, and thus achieve the required performance target with only localized "Here Be Dragons" code.
1 Rust compile times are on-par with C++, hence quite slower than C, but the safety checks (borrow checks) are an insignificant part of that. Extensive use of generics, traits, and type-inference make the language much more difficult to compile, and the compilation model (full crate at a time) makes parallelization trickier. Still, work is in progress to parallelize the rustc front-end, which should bring compile times down substantially... in a few years.
2 Rust does NOT check indexes at compile-time in general but checks them at run-time instead. A branch itself is typically not a problem at CPU level, if well-predicted. The real impact of bounds-checks is that unless optimized out, they prevent auto-vectorization and a number of other optimizations. This is why front-loading a bounds-check (before the loop) can be so effective performance-wise: it may unlock all those optimizations.
Idiomatic Rust is likely faster.
First of all, in a "pedal to the metal" situation, all 3 languages can achieve the same performance. Heck, all 3 languages allow embedding assembly, if it comes to that.
So, what we are really asking, is whether idiomatic (not pessimized, not maximally optimized) code may be faster in one language or another, and in those conditions Rust has a certain number of advantages.
The first and foremost advantage of Rust is one of culture. The Rust community is very concerned about performance. This may seem trivial, but it has deep implications. Most notably, Rust code is always compiled from source, and there is no stable ABI (yet). This means that even the standard library provided data-structures can be remodeled extensively as long as their API is left untouched, and leads to Rust having the best-performing HashMap3 of all languages in its standard library:
std::unordered_map.By comparison, the C++ standard library implementations of std::unordered_map cannot be changed4, nor can their std::regex implementations...
The second advantage of Rust is trust5: the Rust developer can put their trust in the compiler, and count on it to prevent users from accidentally fiddling with private data or violating soundness:
And finally, the Rust language has a few tricks up its sleeve that may lead to better code out of the box:
char* (and co) performance pitfalls.noalias (the LLVM equivalent of __restrict) being used profusely and automatically, as &mut T is __restrict T*.Option<bool> is 1 byte (like bool) and Option<NonNull<T>> (an option non-null pointer to T) is the same size as *mut T (a possibly null pointer to T).(It's not all roses, though, the defined behavior of signed integer overflows prevent a number of integer-based loop optimizations... though the impact of that is likely low)
3 Bryan Cantrill, who used to be a C kernel hacker at Sun Microsystems, was surprised the first time he naively translated a little C program he had around to Rust to get a feel of the language. Being its first Rust foray, he expected his lack of proficiency in the language would result in slow code... but his Rust program ran faster than his C one, on top of being shorter! He double-checked the output, and after concluding both were correct, did the only thing that made sense: he profiled them. It turns out that in his C program he had hand-rolled a quick hash-map implementation, since dependencies are so annoying in C, while in Rust he had just used the standard one... and his quick C implementation was quite naive. Nowadays, Bryan Cantrill is a Rust kernel hacker ;)
4 And that's on top of inheriting a crippling "memory stability" guarantee from std::map, in order to be more of a drop-in replacement.
5 You can't spell Trust without Rust.
The assumptions are wrong twice:
About the claim on faster and safer, there is an extensive study comparing performances of languages that concludes with a benchmark that Rust can be faster and more energy efficient than C++. At the same time, you can't have it all and it appears that for this specific benchmark, C++ is more memory efficient.
But general statements about language performance and safety are always misleading:
My advice: choose the language that is the most suitable for the kind of problems you are trying to solve.
Disclosure: I'm not a Rustler
To look at this a different way, Fortran is:
restrict keyword, although the two concepts are related.Does this mean Fortran is "better" than C? No, there are things you can do in C you can't do in Fortran, and some things are faster in C than in Fortran. The two languages have made different trade-offs so end up with different characteristics; the same is true for C++ vs Rust, or any other pair of languages.
I have been told that Rust is both safer and faster than C++. If that is true, how can that be even possible?
One way Rust does this is that it refuses to compile many programs for which C++ would assume that the programmer knows what they are doing. C++ is notorious for undefined behavior, where if you e.g. have a pointer to object that has been already destroyed, anything can happen.
Rust would refuse to compile such a program and any other program for which it cannot determine that no dangling pointers exist. This can include programs that are completely functional but the properties cannot be readily determined.
In practice I find this puts a different kind of load on the programmer. Instead of having to convince yourself of correctness, you now have to convince the compiler. Less possibility for mistakes, but it requires more rigorous approach to programming.
As for speed, the theory is that when the compiler knows more, it can optimize better. So far I'd say this does not always happen in reality with Rust, but that depends a lot on the specific code involved.
Optimization in modern C and C++ is based around the notion that in any situation where a useful optimizing transform might have any observable effect on a program's execution, nothing an implementation does would be deemed unacceptable.
Suppose the following function is called by a function which ignores its return value:
char arr[65537];
unsigned test(unsigned x)
{
unsigned i=1;
while((i & 0xFFFF) != x)
i*=3;
if (x < 65536)
arr[x] = 1;
return i;
}
There are three plausible ways an optimized version of the function might behave if code which calls the function ignores its return value, and passes a value of x happens to be 65536 or larger:
The generated code might loop forever without returning, which is what would happen if the program is processed as a sequence of sequential steps.
The generated code will skip the loop since nothing will care about the value of i, but skip the assignment to arr[x] because x is not less than 65536.
The generated code will unconditionally store 1 to arr[x], even if x is 65536 or bigger, on the presumption that the function will never be invoked in any circumstance where storing 1 to arr[x] would be unacceptable.
If having a function hang when given certain inputs would be tolerable (e.g. because the environment would have a way of killing the process after a timeout) but unconstrained writes to memory would not be, requiring that programmers add extra code to prevent outcome #3 above would nullify any advantage that approach #2 could have offered. If, however, a language can e.g. treat the execution side-effect-free loop as unsequenced relative to following operations which have no dependencies upon values computed therein, yielding behavior #2, such treatment would be observably inconsistent with that of processing the program as a sequential series of steps, but may nonetheless be acceptable in many cases where behavior #3 would not.
While I don't know to what extent Rust does this, a language which allows programmers to safely write code whose behavior may deviate from sequential program execution and yet still satisfy application requirements can offer compilers many more useful opportunities for optimization than one which makes it necessary for programmers to write code in ways that allow no such flexibility.
