Hacker News Reader

Comment by zamalek | Hacker News Reader

> Borrow checking has the "shared-xor-mutable" restriction: if you hold a reference to an object, nobody else can change the object.

The article makes this sound like a problem. It isn't. This restriction frees you from thinking about certain classes of bugs in concurrent code; it's where the "fearless concurrency" comes from. R^w isn't about lifetimes - you could, in spirit (not sure about practice), remove it from Rust without affecting use-after-free at all.

Of course, it means you can't write many completely valid programs, and so we'd hope there's a better solution, but removing it is not one.

If you want to have to think about that (and potentially introduce bugs), that's perfectly fine. The flexibility of not requiring r^w is extremely useful. I'm just clearing up this mis-attribution.

View on HN

The more you restrict the safe subset of the language, the more correct programs must use the unsafe subset. The logic of "there could be bugs here, therefore it's safer to restrict it" ends in an empty safe subset. The reason for spatial and (to a somewhat lesser degree) temporal memory safety even at the cost of excluding programs that don't violate them is that out-of-bounds access and UAF are extraordinarily overrepresented as causes of severe security vulnerabilities, but that's not the case for concurrency. There are more common causes of vulnerabilities that aren't caught by Rust's type system, that focusing on races seems arbitrary.

> The logic of "there could be bugs here, therefore it's safer to restrict it" ends in an empty safe subset.

What Alan Kay called "the Wirth school of non-programming".

Concurrency issues (such as torn writes) can easily cause out of bounds and similar UB on other threads, so focusing on races is not arbitrary if you want to be a systems level language.

Sure, you could pay the overhead of a managed language and have the runtime handle synchronization behind your back, but that isn't the path Rust went down.

There are multiple things here (and I'm speaking as a systems prorgrammer of 25 years). First, you may want to look into the percentage of vulnerabilities caused by read/write races that lead to tearing and read/write races in general. Second, out-of-bounds on other threads as the result of tearing can and should be handled separately, and often are. Third, there are more common causes of security vulnerabilities and even of memory safety violations, including (though certainly not limited to) the need to use unsafe in safe situations because of the over-strictness of the type system. Rust does this because its design constraints require it, not because it's the right thing to do.

Rust is specifically designed to ensure that safe code can never trigger UB (barring compiler bugs, or bugs in unsafe code blocks). For that, protecting against races is necessary (at least when using LLVM as a backend, and when using the C++ memory model).

In practice rust also tries to guide you towards patterns that reduces the risk of other bugs. For example, using Result, Option (and enums in general) reduces the risk that you forget to handle error paths. It is also quite hard to get memory leaks unintentionally in Rust, since by default you work with various smart pointers.

In my experience typical multi-threaded C++ has a lot of threading bugs that tend to cause hard to reproduce bugs (I work in safety critical hard realtime robotics / machine control, where we have a lot of communicating threads). When I code Rust I can trust the language to prevent those classes of bugs, letting me focus on the actual hard domain specific problems, rather than language minutiae. Yes, TSAN helps in C++, but that is dynamic analysis so it has to actually catch the potential problem happening while running.

So I think that the multithreading approach in Rust is really good and what we want, not a hindrance. It is absolutely the right thing to do.

Now, the async story is another matter and I have conflicting opinions on how that is done in rust. I can't think of a significantly better design that would work on microcontrollers / no-std though. I'm not interested in anything that requires allocations or a runtime.

> at least when using LLVM as a backend, and when using the C++ memory model

Yes, that is true, but 1. that's not the same justification as for memory safety, and 2. that's a decision made by Rust, but it's not the only valid one (e.g. Zig has the "unordered" ordering, using LLVM's Java memory model support).

> In practice rust also tries to guide you towards patterns that reduces the risk of other bugs.

I understand that perspective, but let's say it's not hard to debate, and there's a clear difference between something that prevents a cause of a majority of vulnerabilities and something that prevents a small minority (while not preventing bigger causes).

> So I think that the multithreading approach in Rust is really good and what we want, not a hindrance. It is absolutely the right thing to do.

Well, it is absolutely what some people think is the right thing to do and also absolutely what others don't think is the right thing to do. It's an approach with both supporters and critics.

You can easily get memory safety issues with any concurrency though. Since this is a property of the the raw underlying hardware model of concurrency you can't work around it. See https://www.ralfj.de/blog/2025/07/24/memory-safety.html for an example of this is Go.

As soon as you have something larger than the hardware atomic size (or unaligned in memory) you risk torn reads/writes. So a pointer + a size for example on some architectures (some hardware like x86 has a double word atomic support, but on embedded you usually only get up to word size atomics).

All this means that you can't (in a systems level language) feasibly make everything atomic and ensure no UB.

All that said, do I wish Rust did more for other concurrency bugs? Yes, sure. Though there is some hope: I have seen Rust crates to enforce lock ordering at compile time (I think that originally came out of the Fuchsia OS kernel development). There is also scoped threads, rayon, actor frameworks etc. All different approaches to strucured concurrency, with the goal of reducing bugs. Different frameworks seem to suit different problems though. For what I do I rarely need mutexes, instead either rayon or message passing work well.

> but that's not the case for concurrency

Is that the case because it's easy to avoid concurrency issues, or because people are afraid of even trying to introduce concurrency into their program due to those issues? Because if it's the latter, then trying to support some amount of safe concurrency makes sense.

It's always a trade off. I don't think that humans are capable of perfectly pulling off manual memory management or multi-threading, as a biological limitation of our wetware. But I may just be stupid.

Either way, the problems that rust takes off the plate don't seem arbitrary for that reason. I don't particularly mind the problems it adds to the plate.

Calling a trade-off a slippery slope to a zero-set language is really disingenuous.

But that's not Rust's actual tradeoff. Safe Rust prevents data races not because they were separately considered as a tradeoff, but because its particular chosen design for memory safety requires it. It's a side-effect, not an orthogonal feature.

And I wasn't saying there's an actual slippery slope, only that the argument that if something is tricky it should be moved out of the safe subset is not a good one. The justification Rust uses to do this for memory safety is because memory safety was empirically found to be special, but that particular justification doesn't work for concurrency (nor is it the one used; again, in Rust this is a side-effect).

> Safe Rust prevents data races not because they were separately considered as a tradeoff, but because its particular chosen design for memory safety requires it. It's a side-effect, not an orthogonal feature.

Data race freedom has been specified as a requirement for UB-freedom (i.e. safe code) since the C11/C++11 concurrency model, which predates the Rust borrow checker. You can make different choices on particular platforms, but they come with challenging tradeoffs: e.g. in Java, variables of type "long" are not data-race free on 32-bit platforms; writes to a long can silently tear.

They can, but without UB (in Java, or in Zig with .unordered); the C++11 memory model is a choice. Also, the desire to not have any UB is not justified as strongly as the desire to have spatial and temporal memory safety, and since restrictions also exclude correct programs, which leads to more unsafe, it's definitely not a pure win.

You're right, but what pron is saying is that it doesn't matter much from a security standpoint because they can't be exploited.

Just to clarify, Valen's borrow checker can express shared-xor-mutable, its value proposition is that it can _also_ express mutable aliasing (with `in`).

* When a function has a mutable effect into a group, and the function doesn't declare any other groups to alias it (with `in`), it is effectively a unique reference.

* When a function has references into a group, and it declares no `mut` effects into any of them, they are effectively shared/immutable references.

This helps with Valen's structured concurrency in particular, but also helps guard against the single-threaded race conditions in the same way that Rust's borrow checker does. It also helps with Rust interop!

So, TL;DR: Valen lets you choose between shared-xor-mutable and mutable aliasing.

Also note how mutable aliasing is opt-in (via `in`), so there's a subtle influence pushing people towards shared-xor-mutable, so that they only reach for mutable aliasing when it will benefit them.

> Just to clarify, Valen's borrow checker can express shared-xor-mutable, its value proposition is that it can _also_ express mutable aliasing (with `in`).

Just to clarify, Rust's borrow checker can express mutable aliasing via interior mutability (i.e. UnsafeCell<T> and the various Cell<T> types). A &Cell<T> reference is essentially a mutably aliased reference. The goal is exactly that people "only reach for mutable aliasing when it will benefit them". Of course, any ergonomic improvements around the Cell types are quite welcome, especially if they help C/C++ interop - provided that they're proven to be as sound as the existing borrowck.

Good catch, and well said. Another good example I like citing is GhostCell, which adds mutable aliasing to Rust in a way that's even more flexible than Cell.

I would say Valen's real benefit here is in making a more ergonomic way for functions to work with an arbitrary number of GhostTokens / brands, and to track the relationships between them. (But I admit, I'm no expert with GhostCell, happy to be corrected by someone here)

AIUI, the main limitation with &Cell<T> is (1) no provision for concurrency, obviously - though the various Atomic* types work similarly via interior mutability; and (2) data has to be read, written or modified as a single operation - any provision for enabling subobject access or the like is quite ad hoc, and has to be implemented for the specific type you're working with. GhostCell (and QCell, LCell etc.) generalizes this by tracking the use of shared references at compile time, such that writes will not overlap with each other or with reads, without enforcing a "get/set in a single step" workflow.

> any provision for enabling subobject access or the like is quite ad hoc, and has to be implemented for the specific type you're working with

There is ongoing work on a language feature ("field projection") that could alleviate this.

I think OP understands that.

And I think OP's point, more succinctly, is that Valen programs will be much more difficult to parallelize than Rust programs.

It's shockingly easy to make a single-threaded Rust program use all the cores on a machine by slapping in Rayon wherever you have a Vec. Because Rust forces you to do the hard work of proving shared^mutable before getting a single-threaded program running.

The ecosystem-wide consequence of this is that pretty much every compute-intensive program written in Rust (that doesn't rely on non-Rust libraries for compute-intensive stuff) is automatically multicore. This is one of the reasons why Rust programmers seek out Rust libraries first. Because they know they won't get the unpleasant surprise of putting in a lot of work to adopt a library and then get burned when they find out it will only use a single core.

Apologies for not understanding. And I admit, it's hard to communicate in the abstract, so I might still not understand the question.

If it helps: AFAICT, Valen's borrow checker preserves the same ecosystem-wide concurrency benefits that Rust has. For precedent, check out GhostCell [0] which is not only _compatible_ with Rust's concurrency but gives it some interesting new abilities. Valen's approach could be thought of as a more ergonomic form of GhostCell that better tracks the relationships between multiple groups (brands).

I could give a better answer if we had an example to toss around where we think Valen might force things to be single-threaded.

Rust needs shared xor mutable in order to prevent data races on non-atomically accessed data. You said that Valen can _express_ shared xor mutable, but perhaps you haven't clarified whether this also interacts with equivalents to Rust's Send and Sync to enable the same fearless concurrency.

I mean the article doesn't talk about this aspect of the language, but Send and Sync are orthogonal to borrow checking. I don't see why you couldn't use Rust's exact design in Valen.

How widespread are locks in typical Rust code?

Very rare compared to C code.

If a language allows taking references to fields within a tagged union (as is possible with Rust enums), then "shared-xor-mutable" is required to avoid use-after-free (switching the tagged union to another variant ends the lifetime of the old variant's fields).

> "fearless concurrency"

That saying does more harm than good, and it counts against the Rust community that it keeps repeating it. Deadlocks are not something that Rust prevents. On the contrary, many beginners to Rust often run into deadlocks, some even spurred on by trying to satisfy the borrow checker. An infamous example is https://fasterthanli.me/articles/a-rust-match-made-in-hell . Instead of making blatantly false claims and causing newcomers to Rust frustration, pain and bugs, the Rust community should warn about concurrency and direct beginners to learn about concurrency, both generally as well as specifically in Rust.

* Deadlocks, memory leaks, infinite loops, etc. are all the sort of risks that Rust doesn't try to protect from. In my opinion it's okay to talk about "fearless concurrency" despite deadlocks in the same way it's okay to call Rust memory-safe despite memory leaks.

* Rust's type system also allows you to make safe interfaces like Rayon that do genuinely allow for "fearless" concurrency in a way that I don't really see in other general-purpose languages.

Reply on news.ycombinator.com