by hingler36
4 subcomments
- I can see how multiple mutable references is fine in a single-threaded context, but surely this would cause UB in the multi-thread context?
by Panzerschrek
0 subcomment
- 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.
by Panzerschrek
0 subcomment
- > 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).
by sureglymop
1 subcomments
- What about Vale? Is this a rename of it or something new?
by Xeoncross
1 subcomments
- 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 if I omit the "uniq" keyword? Is it still valid code, just not protected by the compiler from union types changing underneath?
by HexDecOctBin
1 subcomments
- What is "stable shape"?
- 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?
Very interesting anyway!
- Highly interesting. I hope this language reaches a production release some time.
- >"I have to admit, this is beautiful"
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.
- 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.
Hacker News