Ante: A new way to blend borrow checking and reference counting

Creator of Ante here, Ante inherits Rust's Send/Sync for thread-safety. `mut` refs and `Rc` which provides shared mutability don't implement either and thus can't be shared across threads. So shared mutability is only within a single thread.

Given their "shape stability" design, not necessarily. The three ways that multithreaded access can cause UB are:

* changing the type of the underlying memory (e.g. because it's part of an enum variant and you changed the tag, or because you changed the length of a vector) * data races (can be defined away by making [effectively] every access Relaxed, as Java does * use after free (resolved here by reference counting)

In Rust, any type specified like this (all accesses are Relaxed, "shape stable", and reference counted) can already be used in safe code using & references. In theory. But the first property (forcing all accesses to be Relaxed) is very annoying to achieve for arbitrary user data types--even if those types are Copy or other kinds of plain old data--which is a problem e.g. for specifying stuff like sequence locking. The example they give here with bare unions is also very annoying to use in Rust even though this mode of use is safe, because the type system doesn't track which variant is active. So I definitely think there's room to innovate ergonomically here.

(It does seem from the text like this is intended for a single-threaded context, where I think the arguments against Cell are a little less persuasive, but it's still true that it's very awkward to try to figure out how to safely project a Cell down to the exact fields you need to mutate, even though something like LambdaRust will tell you it's safe to do so).

By accepting semantics like this you are, of course, opting out of a lot of potential optimizations around both shared and unique accesses, but you are already doing this in most langauges anyway, so if you're willing to eat the performance cost this can be quite acceptable. The bigger problem (briefly noted in the post) is that the kind of recursive analysis they're proposing doesn't necessarily compose well. Rust explicitly opted out of most types of analysis that can't be efficiently summarized at the function signature level to improve compilation speed. Historically, not being able to efficiently summarize functions that do this kind of stuff has been a big thing that killed attempts to automatically add borrow checking like facilities onto existing C++ code, too. But maybe a language designed for it from the ground up will avoid this problem.

Not if you define the behavior. Many programming languages have robust memory models ranging from "happens before" style systems like those in Java or Modern C++ to the Software Transactional Memory system in GHC/Haskell.

Correct, shared mutation is an extremely well-understood problem in the sense that there are points in the programming language design space that admit it with present technology.

As always, there are tradeoffs.

Hi, article's author here (Verdagon, Vale's creator), and no, I'm just writing about someone else's language (Ante) that I thought was interesting.

Ante is making some very intriguing steps forward in memory safety design and I thought others would find it interesting too.

Creator of Ante here. It's just a term I made up for mutation which does not change the "shape" of data in a way that can invalidate any of that data. Mutating a struct or tuple field, even if nested, is stable for example, but mutating an optional string to None is not because you may be dropping a string which there may be a reference to somewhere.

What would your ideal version look like? I recommend reading the C++ or Rust equivalent code in the article. I like the example because it is copied 1:1 with example code from a textbook with only some keywords changed and a Copy constraint. Any other language without a GC and with unboxed types today represents it far more verbosely to the point where the meaning becomes obscured and a typo becomes more likely to survive code review.

That's what I thought too when I first saw it. But then I actually took a moment to read it and eventually changed my mind.