Vale

The github readme shows how to use the compiler. https://github.com/ValeLang/Vale#building-a-vale-program

This is actually what we're doing in Vale. [0] Rust is a stellar language, and there's a lot we as a field can learn from it. Its borrow checker is pretty amazing for optimization, but it can be a detriment for a program's overall architecture, not to mention the difficult learning curve, which people tend to underestimate as an issue. I want Rust to grow and succeed in the realms it's uniquely suited for, but I think we can make a general purpose programming language that combines its features in a new way and brings its strengths to the rest of the programming world. For example, we found a way to recreate the borrow checker based on regions [1] on top of a foundation of shared mutability with reference counting (or generational references [2] in Vale's case). Another example is inspired by Rust's RefCell; we found a way to decouple it

Vale lead here, thanks for posting! For those interested in the PL space, here are some of the shenanigans we've been up to in Vale: * We added "Higher RAII", a form of linear typing that allows destructors to have return types and parameters. [0] * We just yesterday finished the first prototype of deterministic replayability, which will allow us to capture all inputs to a program (including all network data, user input, file input, etc, and eventually, even thread orderings). No article yet, but our docs on it are pretty approachable. [1] * Last month, we finished the first milestone of "Fearless FFI", which lets us call into our C code without fearing it corrupting our Vale data. Later on, we'll be adding automatic sandboxing, either via subprocesses (using IPC for FFI) or wasm2c (which should be a lot faster). We've also got some inter

Based on the "Compiler Overview" page, they do use LLVM for codegen: https://github.com/ValeLang/Vale/blob/master/compiler-overvi...

Thanks! There are three things preventing someone from using the object after destroying it: * If it was an owning reference, the compiler will ensure nobody else uses it. * The program will halt if there are any live constraint references to an object we destroy, preventing anyone using one of those. * If it was a weak reference, the language will (conceptually) null that out when we destroy the object. Locking goes deep into Vale's concurrency story, but I can try to sum it up: * By default, an object can't be visible to two threads, every thread has its own isolated region (similar to Pony and Rust). * We can use a mutex to contain a region, and Vale's "region borrow checking" can make sure references don't escape the lock's duration. I'm curious about that second safety hole Rust has. I don't think Vale has that same