Good question! If one defines safety as a lack of UB or vulnerabilities, then I'd say Vale's a bit safer than other languages like Rust. I say this because:

Good question! If one defines safety as a lack of UB or vulnerabilities, then I'd say Vale's a bit safer than other languages like Rust. I say this because: 1. There are no unsafe blocks in Vale. 2. Vale memory is decoupled from native memory, it only passes messages and handles between, and uses a different stack. [0] This prevents accidental bugs in unsafe code from corrupting data from safe code. We just finished our proof-of-concept of this last month! 3. Building on that, we could automatically sandbox any native code for a module in theory, with either subprocesses or wasm2c. [0] (Note we've only just started on this part.) I'd say that's safer than Rust, where unsafe code can undermine the code around it. I'm particularly excited about how this might make it safer to use dependencies; #1 and #2 protect from accidental corruption, and #3 could help protect against malicious corruption and certain kinds of supply chain attacks. We're even tossing around a potential #4 to add permissions, so dependencies must be whitelisted to be able to access network, files, etc. We're also thinking about relaxing the above 3 restrictions on a per-module basis if we can do it in a way that doesn't compromise the safety of the ecosystem (note that these relaxations are not implemented yet): * Instead of full sandboxing (3), we can rely on the decoupling (2), if we trust a dependency's intentions. * Have operators to skip generation checks for extra speed. [1] These operators would be by default ignored for dependencies. It's unclear if this will help, as the combination of regions [2] and HGM [3] might combine to eliminate the vast majority of generation checks. We'll see! * Perhaps add a keyword for blocks, to ignore all generation checks within (maybe `unsafe`?). This would also be ignored by default for dependencies. Rust must always allow unsafe blocks, because libraries often believe it's necessary for their performance, or sometimes for just working around the borrow checker. Vale would default to disallowing it (and sandbox FFI), and it would be much more noticeable (and suspicious) if a dependency said it wouldn't work without unsafe; they can't just sneak it in there like they can in other languages. These adjustments are still under consideration (thoughts are welcome!) but as of today, there's no unsafety in any Vale code. To summarize, Vale has stronger protections against memory unsafety and UB, so I'd say it's a bit safer. Though, if one wants to prevent all bugs at compile time, then one shouldn't be looking at Rust or Vale which often panic, but instead look at languages like Pony (which doesn't even have panics, hence its amazing uptime) or proof languages like Coq. Hope that helps! [0] https://verdagon.dev/blog/next-fearless-ffi https://verdagon.dev/blog/next-fearless-ffi (still a draft, read generously!) [1] https://vale.dev/guide/unsafe https://vale.dev/guide/unsafe [2] https://verdagon.dev/blog/zero-cost-refs-regions https://verdagon.dev/blog/zero-cost-refs-regions [3] https://verdagon.dev/blog/hybrid-generational-memory https://verdagon.dev/blog/hybrid-generational-memory