Vale brings a lot of innovations to the table to make coding safe.
This page describes Vale's design, but it's still a work in progress. See the annotations for whether something's ready or not.
All of today's native languages require some unsafe user code to function. For example, in C, you can bring in a library that causes mysterious crashes in other parts of your program, because there are no protections in C.
Rust does especially well here, though its guarantees are somewhat weakened by its unsafe keyword. Most think that memory unsafety can only happen inside unsafe blocks, but unfortunately, unsafe blocks can cause safe Rust code to trigger undefined behavior as well.
Vale uses hybrid-generational memory, which doesn't require any unsafe, even in its standard library.
Vale goes even further, by isolating all unsafe memory from safe memory. Even if we call into C, there's no way for accidental bugs there to trigger memory unsafety in Vale. 1
Vale's design has seamless, fearless, structured concurrency to allow us to safely read existing data while doing fork-join parallelism.
When doing manual parallelism, one can either:
Vale can call into C code (and vice versa). So how does it maintain its safety guarantees? By using what we're calling extern isolation.
The behavior when sending an object into C depends on the object's mutability. 5
This means that any bugs in our C code won't affect our Vale code. If we want to protect against not only bugs but maliciously written C code, we can "sandbox", by sending all of our extern calls across an IPC channel to another process. However, it's recommended to never run arbitrary untrusted code.
When Vale's package manager is ready, the user will have to whitelist every single dependency that wants to call into extern code.
This way, we can be more certain that none of our dependencies are making surprising extern calls.
Vale is memory safe today via generational memory! Hybrid-generational memory is a planned optimization on top of that.
This is talking about accidental bugs because this is not a security feature. It's only meant as a debugging tool, because these protections can be worked around with some effort.
Safe concurrency is in the design, but not implemented yet. Stay tuned!
This isn't as expensive as one might think. We use a combination of assertions and generation increments to guarantee no further accesses from the source thread, and even those are often elided.
Safe externs are nearing completion. Everything in this section is done, except the handle scrambling and sandboxing option. Stay tuned!
As described in Structs / Mutability, a struct can either be mutable or immutable.
Vale doesn't have a package manager yet. Stay tuned!