4 ms·

Type stability lets us mutably alias, which atomics and Cell do not. It doesn't really have a Rust counterpart, a struct containing a bunch of Cells cannot be m

Type stability lets us mutably alias, which atomics and Cell do not. It doesn't really have a Rust counterpart, a struct containing a bunch of Cells cannot be mutably aliased. If you're curious, this (draft) page has some information on it: https://vale.dev/vision/safety-2-type-stability https://vale.dev/vision/safety-2-type-stability Vale also considers changing between Some<T> and None<T> to be a type-unstable operation, and the automatic borrow checker (HGM) detects the possibility for that (because the field was marked non-final), to not do auto-borrowing for it. We might decide to use something called the Undead Cycle to help with the Opt<T> case, though it comes with interesting tradeoffs. There's a lot more to Vale, such as how our region borrow checker can enable zero-cost structured concurrency without the Send/Sync requirements, and the better RAII support. In the end, the only similarities we really share with Rust are the syntax and (hopefully!) the speed. Vale regions are tracked like lifetimes, and have a concept of immutable vs const vs readwrite to aid in optimization, but they come with an implicit interface pointer to the containing objects' allocator, similar to Odin but memory-safe. Oh, MLKit! I've looked into MLkit a bit before, but wrote them off because their regions needed a backup GC, where Vale's regions don't. Keep an eye out, we'll be posting a lot of articles to HN soon ;)

Jweb_Guru 5y ago
> Type stability lets us mutably alias, which atomics and Cell do not. Well, that's not the case :) Both Cell and atomics let you mutably alias, in the sense most languages mean. They don't let you mutably alias in the Rust `&mut` / "restrict" sense, which is far more powerful and would be unsound in any language, but they do let you mutably alias. > Vale also considers changing between Some<T> and None<T> to be a type-unstable operation, and the automatic borrow checker (HGM) detects the possibility for that (because the field was marked non-final), to not do auto-borrowing for it. We might decide to use something called the Undead Cycle to help with the Opt<T> case, though it comes with interesting tradeoffs. That's interesting and good to know! I'm glad you are taking this seriously. > There's a lot more to Vale, such as how our region borrow checker can enable zero-cost structured concurrency without the Send/Sync requirements, and the better RAII support. In the end, the only similarities we really share with Rust are the syntax and (hopefully!) the speed. A lot of the stuff in Rust is also found in other languages :) In this case, it sounds to me like Send/Sync are thoroughly built into your language, to the point that annotations are not needed--which is very nice, but not completely unique (this is the basis for memory safety in C# and Java, after all!), but may be so when combined with regions. From what it sounds like, though, I'm having a very hard time telling the difference between regions and (generational) arenas--they sound like they have almost exactly the same tradeoffs. Perhaps I'm missing something? Overall, seems like an interesting language, and I will definitely stay on the lookout.

Jweb_Guru 5y ago

> Type stability lets us mutably alias, which atomics and Cell do not. Well, that's not the case :) Both Cell and atomics let you mutably alias, in the sense most languages mean. They don't let you mutably alias in the Rust `&mut` / "restrict" sense, which is far more powerful and would be unsound in any language, but they do let you mutably alias. > Vale also considers changing between Some<T> and None<T> to be a type-unstable operation, and the automatic borrow checker (HGM) detects the possibility for that (because the field was marked non-final), to not do auto-borrowing for it. We might decide to use something called the Undead Cycle to help with the Opt<T> case, though it comes with interesting tradeoffs. That's interesting and good to know! I'm glad you are taking this seriously. > There's a lot more to Vale, such as how our region borrow checker can enable zero-cost structured concurrency without the Send/Sync requirements, and the better RAII support. In the end, the only similarities we really share with Rust are the syntax and (hopefully!) the speed. A lot of the stuff in Rust is also found in other languages :) In this case, it sounds to me like Send/Sync are thoroughly built into your language, to the point that annotations are not needed--which is very nice, but not completely unique (this is the basis for memory safety in C# and Java, after all!), but may be so when combined with regions. From what it sounds like, though, I'm having a very hard time telling the difference between regions and (generational) arenas--they sound like they have almost exactly the same tradeoffs. Perhaps I'm missing something? Overall, seems like an interesting language, and I will definitely stay on the lookout.