3 ms·

Relying on "type stability" (which I assume means no structure-altering mutations are allowed) is pretty similar to "just use atomics" as a strategy, which is w

Relying on "type stability" (which I assume means no structure-altering mutations are allowed) is pretty similar to "just use atomics" as a strategy, which is what languages like Java and C# employ (it also has some similarities to the "value restriction" in languages like Standard ML and OCaml). However, this can be quite restrictive depending on your definition of type stability (and what optimizations are allowed); for instance, Rust considered changing a value to null to be a structure altering mutation and is able to optimize around that, while it sounds like Vale cannot. The rest of it sounds a lot like Rust (though I'm not sure whether regions are more like arenas or lifetimes, I'd have to look at the implementation, but generally speaking people call the same kinds of things regions even if they weren't trying to coordinate, and the performance tradeoffs you're describing sound really similar to those of regions in other languages). Overall, like I said, it sounds like a very interesting point in the tradeoff space! Edit: Also, I misspoke when I said MLton, what you actually want is the similarly named sister project MLkit (http://www.mlton.org/MLKit http://www.mlton.org/MLKit ; see http://www.mlton.org/Regions http://www.mlton.org/Regions for details on why they did not end up going with this strategy).

verdagon 5y ago
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.

verdagon 5y ago

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.