Mojo vs Rust memory safety
Does Mojo's value ownership and lifecycle mean that it can compete with Rust for memory safety?
13 Replies
Rust will probably stay the king of safety, with Mojo taking second place. Mojo is much safer than C++, but Rust has essentially built the whole language around safety. Mojo cares more about hot loop performance than Rust, since you have to write some very un-idiomatic Rust to get the full performance of your hardware. However, they should both be safe enough that a project can reasonable consider whether they care about safety or performance more and choose between them.
I'm not sure I agree with that characterization. 🫢 Mojo and Rust both have safe references, and unsafe references. But yes, perhaps Mojo programmers will choose to use unsafe operations more often, for the sake of optimization.
Rust has an invocation you can stick at the top of main.rs or lib.rs to disable unsafe. It also has public/private variables which allow for more granularity in terms of what the user can mess with. Also, for Rust between safety and performance safety always wins, but they will try really hard for performance. In Mojo performance wins and there are efforts made towards safety.
To address just one point: I expect Mojo will offer some form of access control eventually. It would be easy to do and has many benefits beyond safety, e.g. API versioning.
But more generally, I understand what you're saying. I guess time will tell how the ethos of Mojo vs. Rust ends up differing.
Yeah, I agree, I don't see any reason that Rust is inherently "more safe" than Mojo when Mojo is finished. We're just missing a couple features.
wouldn't Mojo put more emphasis on interop? Safety will be big step up in Python family, but probably not aim to be like Rust?
My comment is coming off a Bryan Cantrill talk (Platform as a Reflection of Values). In the talk, he gives a list of values like performance, security, safety, approachability, expressiveness, etc. All laudable goals for a project to have. However, he argues that most projects end up choosing a few of them as the "primary values" of the project. As a clear example, OpenBSD values security above all else, which is why it disables SMT by default. For people who also value security above all else, OpenBSD is where they can find a project that shares their values. Yes, it will try to be fast, approachable, portable, etc, but security wins any arguments. The talk is about why Joyent decided to move away from NodeJS, which to his mind (as CTO), was because Joyent wanted different values for the project than the community at large did. Joyent wanted robustness and resiliency, the JS community wanted approachability and simplicity to be the guiding stars of the project. There is nothing wrong with choosing different values, but having clear values (see the zen of python for another example) can help to minimize conflict in a community.
To my mind, Rust's guiding star is safety, with performance and productivity as secondary values. Rust generally will sacrifice the productivity of the programmer to keep safety and performance (see the lifetime soup of async), and while it offers the escape hatch of unsafe for performance, that is an even bigger hit to productivity and you are required to uphold many safety invariants yourself to avoid UB. Rust is willing to pile syntatic salt on top of unsafe to discourage its use unless absolutely necessary as well, something that has been rejected for Mojo. Mojo, to my mind, seems to care about performance, then safety, then approachability. The programmer is given the power to cause UB without any special rituals to avoid making writing fast kernels hard.
Bryan Cantrill
YouTube
Platform as a Reflection of Values
My talk from Node Summit 2017. Despite this being a popular talk (and one that was personally and professionally very important to me), it was taken down sometime in 2023. Fortunately, the Internet Archive had a copy; if you saw this talk for the first time here, consider supporting their important efforts!
It's a reasonable approach to take, and I think that Mojo still cares far more about safety than C or C++, but the general feeling I've gotten is that Mojo cares more about performance than safety. That may be wrong, and I'm happy with it whichever way you prioritize them, but it just seems to me like Mojo is not willing to make sacrifices on the altar of safety to quite the level Rust is.
IMO each language has a different "guiding light". Rust wants to be savior of all C++ errors. Mojo wants to unify the AI deployment stack (is that correct?). Currently it needs performance to be viable vs CUDA. Ultimately it needs the best interop.
I think it's interesting that Mojo seems to be able to compete with other languages on both performance (which I'd agree looks like the main focus) or safety, with the flexibility to choose one over the other that isn't present in other languages. But at the same time isn't it extremely approachable if you already know Python?
That’s the goal!
At least, it should be easy to get started. Maybe not to write your own low-level SIMD number crunching code.
Mojo is pragmatic - it needs to talk to Python obviously, but also to C and C++ and other languages. Rust does a weird thing where they're like "we're safe, unless you use unsafe or call into other things" which is a very interesting "value system"
It's a value system that punishes pragmatism, and prevents Rust from expressions (Eg) its array type in its own language, which seem fairly problematic if you care about generality. I prefer the approach of "you can provide safe abstractions over unsafe concepts through library design" personally.
That's fair, I've run into those limitations quite a few times. Rust does have its escape hatches, and most of the "safe" comes from the agreement to use said escape hatches as little as possible. I could be perfectly happy with unsafe acting more like a lint rule/warning than how Rust treats it, so long has there's a reasonable programmatic way to check that nobody has decided to use raw pointers in the "business logic" sections of a code-base. I see far too much "use unsafe to not deal with the borrow checker" in Rust code and people using raw pointers in C++ when a
std::unique_ptr would suffice, and it makes me wary of not having a good way to automatically catch unsafe constructs outside of places where they make sense (hot loops, data structures, etc).
Ideally, the community designs itself out of the need for unsafe in most contexts, and Mojo gets a solid memory model that is easier to explain than Rust's WIP one.