I'm really looking forward to the next generation of languages. Not only are the old 90's languages like Java, PHP, and JavaScript now actually doing things correctly. The new languages like Zig, Go, Swift and Rust continue to figure out new ways of trying things like generics. Spinoffs like V, Ante, and others are perfect testing grounds.
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.
surprised to see that, I've long held tree balancing up as practically the poster child for ML syntax being the best way to express certain algorithms. it directly says what shape of nodes goes to what other shape.
> Because of this, Ante code can safely have multiple mutable borrow references to the same struct at the same time.
I doubt it can work in multithreaded code. Allowing sharing mutable references (even to simple structs) means race conditions, temporal inconsistency between different struct fields and even incorrect read results for basic integer types (if the target CPU can't atomically read/write values of types like u64).
I am pretty skeptical about the whole idea about adding such exceptions to the single mutable reference rule. It may be safe to share references to simple structs in terms of raw bytes access, but as long as some non-trivial invariants are involved, it can be a source of nasty bugs.
In my programming language I generally don't allow having more than one mutable reference to a variable. The only exception is when two references point to different elements of structs/tuples. This gives some flexibility without sacrificing correctness.
The interesting bit here is treating Rc<T> and &T as compatible via a shared representation, so you can hand an Rc to a function expecting a borrow without bumping the count. Swift already does something adjacent with its guaranteed vs owned parameter conventions eliding retain/release pairs, but that's an optimization pass, not a type-level guarantee. Making it explicit in the signature is nicer because you can reason about when a clone actually happens.
The part I'm skeptical about is cycles. Once you lean on RC as the escape hatch for graph-shaped data, you inherit the weak-reference discipline problem that Rust users hit with Rc<RefCell<T>>. Ante doesn't seem to address that directly, and region inference has historically been fragile at scale (see the ML region work that got abandoned for tracing GC). Also, if a borrowed T is really a pointer into an Rc allocation, you need to guarantee the count can't hit zero during the borrow, which either requires the caller to hold the Rc live across the call or some form of stack pinning. Curious how they handle re-entrancy through a callback that drops the last strong ref.
Interesting but I wonder how useful this is in practice. It doesn't work with unions/enums, I presume it also doesn't work with heap allocated containers, like vectors, hash maps, etc? Wouldn't that rule out like 90% of typical data structures?
Also, there's definitely something to be said for Rust's ownership rules improving code quality. I wonder if that would be affected if you relax them like this?
16 comments
[ 3.3 ms ] story [ 36.3 ms ] threadAnte is making some very intriguing steps forward in memory safety design and I thought others would find it interesting too.
me too!
Terse it is, beautiful it is not (well my version of beautiful that is - easy to read and understand). this is not to diminish the language.
I doubt it can work in multithreaded code. Allowing sharing mutable references (even to simple structs) means race conditions, temporal inconsistency between different struct fields and even incorrect read results for basic integer types (if the target CPU can't atomically read/write values of types like u64).
In my programming language I generally don't allow having more than one mutable reference to a variable. The only exception is when two references point to different elements of structs/tuples. This gives some flexibility without sacrificing correctness.
The part I'm skeptical about is cycles. Once you lean on RC as the escape hatch for graph-shaped data, you inherit the weak-reference discipline problem that Rust users hit with Rc<RefCell<T>>. Ante doesn't seem to address that directly, and region inference has historically been fragile at scale (see the ML region work that got abandoned for tracing GC). Also, if a borrowed T is really a pointer into an Rc allocation, you need to guarantee the count can't hit zero during the borrow, which either requires the caller to hold the Rc live across the call or some form of stack pinning. Curious how they handle re-entrancy through a callback that drops the last strong ref.
Also, there's definitely something to be said for Rust's ownership rules improving code quality. I wonder if that would be affected if you relax them like this?
Very interesting anyway!