4 ms·

Yes indeed! Cell types can be used for a lot of different situations depending on the specific requirements, but there's no good way (that I've found) to really

Yes indeed! Cell types can be used for a lot of different situations depending on the specific requirements, but there's no good way (that I've found) to really represent the Plane/Airport example in a way that doesn't discard safety, incur a runtime cost, or freeze the containing Vec... I may very well have missed something though.

steveklabnik 6y ago
So, first of all, I want to say that I haven't read all of the Vale stuff yet but will, and I'm excited people are doing stuff in this space. Please take that (and this) comment as a "we're on the same team of safety!," not some sort of attack or something :) We need more software with more memory safety, and we need more people researching novel ways of achieving it. I think it's hard to talk about these examples, but I'm having a hard time putting what I want to say into words. I am very interested to see these benchmarks :)
comex 6y ago
> but there's no good way (that I've found) to really represent the Plane/Airport example in a way that doesn't discard safety, incur a runtime cost, or freeze the containing Vec… That's true. But according to your blog post, neither does Vale: it makes you choose between unsafe mode and reference-counting-overhead mode. From what I can tell, the advantages you're claiming are: 1. Optimized reference counting: Valid, though I'm wondering how much difference it makes. 2. Constraint references: Valid, but as far as I can tell this could be easily implemented as a wrapper around Rc like the C++ version is around shared_ptr. 3. Mutable aliasing: I think this is the most important one. In Rust you can do this by wrapping all your struct fields in Cell or RefCell (so that the 'immutable' references you get from Rc are actually mutable ones), but the ergonomics are poor. Other reference-counting languages (e.g. Swift) do this ergonomically, but have no way to opt out and use a borrow checker for increased performance. There's definitely room for a language to combine features of both. 4. Ability to compile the same code as either fast or safe: Doesn't appeal to me, because safety matters most in production where you might actually get exploited; but YMMV. I know game developers tend to have a different outlook.
- verdagon 6y ago
  Absolutely right! Both Rust and Vale have their respective overheads. Fast mode is as fast as even C++, and strictly safer than e.g. the C++ + ASan approach, but Resilient Mode is where the speed+safety story gets interesting. I didn't have much opportunity to go into it in the article (it was already going on 15 pages, hah!) but there are some other aspects to Vale which should drastically cut down on reference-counting overhead: * Immutable region borrowing: we guarantee an entire is immutable, so all references into it are temporary and zero-cost, verified by the region borrow checker) * Bump-calling: a pure function can make its own new region which uses a bump-allocator for all allocations, and at the end we copy out the return value. * As mentioned, optimized ref-counting; we hope to reuse Lobster's algorithm, which removes 95% of ref counts. * Non-atomic ref-counting, because of the region isolation (like Rust's Rc, as opposed to its Arc), which is faster and more optimizable. I would of course agree that fast mode isn't for every use case; I would use it for a game or WASM, but not for a production server, where priorities are different. We think that the above four optimizations will give Resilient Mode speed on par with Rust and C++. Benchmarking will show us how close we can get!

steveklabnik 6y ago

So, first of all, I want to say that I haven't read all of the Vale stuff yet but will, and I'm excited people are doing stuff in this space. Please take that (and this) comment as a "we're on the same team of safety!," not some sort of attack or something :) We need more software with more memory safety, and we need more people researching novel ways of achieving it. I think it's hard to talk about these examples, but I'm having a hard time putting what I want to say into words. I am very interested to see these benchmarks :)

comex 6y ago

> but there's no good way (that I've found) to really represent the Plane/Airport example in a way that doesn't discard safety, incur a runtime cost, or freeze the containing Vec… That's true. But according to your blog post, neither does Vale: it makes you choose between unsafe mode and reference-counting-overhead mode. From what I can tell, the advantages you're claiming are: 1. Optimized reference counting: Valid, though I'm wondering how much difference it makes. 2. Constraint references: Valid, but as far as I can tell this could be easily implemented as a wrapper around Rc like the C++ version is around shared_ptr. 3. Mutable aliasing: I think this is the most important one. In Rust you can do this by wrapping all your struct fields in Cell or RefCell (so that the 'immutable' references you get from Rc are actually mutable ones), but the ergonomics are poor. Other reference-counting languages (e.g. Swift) do this ergonomically, but have no way to opt out and use a borrow checker for increased performance. There's definitely room for a language to combine features of both. 4. Ability to compile the same code as either fast or safe: Doesn't appeal to me, because safety matters most in production where you might actually get exploited; but YMMV. I know game developers tend to have a different outlook.

verdagon 6y ago
Absolutely right! Both Rust and Vale have their respective overheads. Fast mode is as fast as even C++, and strictly safer than e.g. the C++ + ASan approach, but Resilient Mode is where the speed+safety story gets interesting. I didn't have much opportunity to go into it in the article (it was already going on 15 pages, hah!) but there are some other aspects to Vale which should drastically cut down on reference-counting overhead: * Immutable region borrowing: we guarantee an entire is immutable, so all references into it are temporary and zero-cost, verified by the region borrow checker) * Bump-calling: a pure function can make its own new region which uses a bump-allocator for all allocations, and at the end we copy out the return value. * As mentioned, optimized ref-counting; we hope to reuse Lobster's algorithm, which removes 95% of ref counts. * Non-atomic ref-counting, because of the region isolation (like Rust's Rc, as opposed to its Arc), which is faster and more optimizable. I would of course agree that fast mode isn't for every use case; I would use it for a game or WASM, but not for a production server, where priorities are different. We think that the above four optimizations will give Resilient Mode speed on par with Rust and C++. Benchmarking will show us how close we can get!