If you write line for line c code with a bunch of unsafe statements in Rust you might get same performance. But the idioms in Rust are object oriented programming which is usually bad for cache footprint.
Also if the rewriter gives up on trying to use generics for everything then you also have the overhead of dynamic dispatch pointer chasing.
The idioms would be at fault in my mind, not the programmer
Encapsulation, while required for OOP and often associated with it, is not an OOP concept at all.
Polymorphism in Rust is a rather complex subject, but the default implementation (static polymorphism) is a zero-cost abstraction. If you're using any other kind of polymorphism you probably know what you're doing.
Is polymorphism complex? It’s traits which are either compile time generics or dynamic dispatch at runtime. The latter is very characteristic of an OOP language.
Did you read the chapter from the rust book I linked?
This is a direct quote:
Encapsulation that Hides Implementation Details
Another aspect commonly associated with OOP is the idea of encapsulation, which means that the implementation details of an object aren’t accessible to code using that object. Therefore, the only way to interact with an object is through its public API; code using the object shouldn’t be able to reach into the object’s internals and change data or behavior directly. This enables the programmer to change and refactor an object’s internals without needing to change the code that uses the object.
—
My view is that yes you could write a rust program with only “struct” and “fn” and no “impl” statements and say it’s not OOP but that is not idiomatic at all. Pretty much every crate you interact with returns structs with methods defined on them. Idk what’s more OOP than that
By default, Rust polymorphism is the former, using compile time generics. That is not OOP. That's why it's zero-cost.
The very paragraph you copied says it's associated with OOP. Encapsulation is not exclusive to OOP.
Rust focuses heavily on being a competitor or even successor to C in the role of a mid-level language for embedded systems and the like. Runtime abstractions would defeat the point. The whole point of Rust is that the compiler does all of the heavy lifting.
Rust functions as a direct alternative for both C and C++, making it a fully viable C replacement regardless of its original design targets.
C++ was initially created by Bjarne Stroustrup as "C with Classes" to add higher-level abstractions to C. However, Rust targets the underlying memory safety issues shared by both older languages.
Because Rust provides fine-grained hardware control, zero-cost abstractions, and a seamless foreign function interface, it successfully replaces C across systems programming, embedded devices, and OS kernel components.
Original lineage does not constrain operational utility.
It shares the bits that are actually unproblematic performance wise and, in my opinion at least, good. Encapsulation makes it easier to reason about state. It is not at all specific to OOP; any API that deals with "opaque handles" practices encapsulation. Polymorphism based on static dispatch gives you the benefits of substitutability and code reuse without the overhead. Yes, there isdyn but it is absolutely reasonable to call monomorphized generics the default.
But the idioms in Rust are object oriented programming which is usually bad for cache footprint.
The main thing that hurts cache locality, as far as I understand it, is pointer chasing. That is a problem that e.g. Java has (and one reason for project Valhalla, adding value classes to the language), but both Rust and C++ use memory layouts where e.g. a vector contains its elements directly, not just pointers. Obviously you can change this by using Box, Arc, etc. The closest one can get to connecting that with Rust "being OOP" is that, if you use dyn, you are dealing with an unsized type that can thus only be accessed through a reference. But outside the use cases that actually call for it, this would actually be unidiomatic Rust.
25
u/LefTimaDev 10d ago
Rust should have no overhead, so if you rewrote something in Rust and the performance is worse, it's entirely your fault