2,080 karma · joined May 25, 2018
TL;DR: Vale is like a cleaner C++, and it uses generational references [0] which are similar in spirit to running with ASan [1] turned on. Generational references have a bit of overhead, but it can be removed by regions [2] or more specifically, immutable region borrowing [3]. This helps Vale achieve its goal of being a high-performance language while still remaining memory safe.
Hope that helps, happy to answer any other questions =)
[0] https://verdagon.dev/blog/generational-references
[1] https://github.com/google/sanitizers/wiki/AddressSanitizer
[3] https://verdagon.dev/blog/zero-cost-borrowing-regions-overvi...
[4] https://verdagon.dev/blog/zero-cost-borrowing-regions-part-1...
* I like mythical birds, so I wrote an article about memory safety and mythical birds: https://verdagon.dev/blog/myth-zero-overhead-memory-safety
* The Rosetta stone fascinates me, so I wrote an article on linear types and the Rosetta stone: https://verdagon.dev/blog/linear-types-borrowing
* I heard about a pigeon named G. I. Joe so I added a side note to about it on the C++ article at https://web.archive.org/web/20230629052606/https://verdagon....
* And now I had to find a way to spread the word of Brigadier Sir Nils Olav III, so I used a side note in this one. It's embarrassing but I was giggling with glee all day yesterday at the thought of putting that note in!
I suspect this is a curse that a lot of bloggers can empathize with, but they don't have the proper lack of professionalism that I do.
Once I had these little side notes, I figured I'd give some sort of prize to the first person who told me they saw them, which evolved into "comment somewhere mentioning it!" which I guess is a social hack? Maybe? I'll allow it!
We created two newer approaches since then, which let any memory be reused for any purpose:
* Random generational references, where it's fine if generations overlap with other data.
* Side-table generations, which is slower but we keep the generations in a side-table. It's can be seen in old 0.1 versions as the "resilient-v2" mode, and I plan on resurrecting it for unrelated reasons.
The former will be the default, and the latter we'll be adding back in as an option. Hope that helps!
We have a future improvement planned here too: for unrelated reasons (to support generation pre-checking) the random generational references implementation will soon not even unmap any virtual address space, instead remapping it to a central page, so we won't even get any segmentation faults, just assertion failures.
The compiler is very rough around the edges right now. August-May was spent being 100% focused on prototyping regions, and you're experiencing the tech debt I accrued on the way there (including the lack of an integration test for the help system). I've been paying that debt down for the last 1-2 months and we're still not back up to where we were at the 0.2 release.
If you need any more help, let me know, or swing by the discord server where there are many helpful folks. Cheers!
AFAICT, a language would need something like higher RAII [0] or linear types [1] for that. I'd love to see Rust adopt these features too one day, though it may be difficult to do backwards compatibly.
It uses region-based static analysis without borrow checking: it doesn't impose aliasability-xor-mutability per object, or even per-region.
Though, if you'd like to move the goalposts further to no form of borrowing at all, then I recommend looking at languages like Forty2 and Verona, they might be what you're looking for.
* Vale combines generational references and linear types with regions to eliminate overhead.
* Verona lets you divide memory into regions which can be backed by either arena allocation or GC. I think this is promising because for most GC regions you can completely avoid the collections.
* Cone lets you put borrow checking on top of any aliasing memory strategy, so could be something like the best of all these worlds.
* No language is doing this yet, but RC plus regions to eliminate the refcounts, then adding in value types for better cache usage, could be a real winner.
On phone so it's hard to get links, but you get the idea. The nice thing about regions is that they allow composing borrowing and shared mutability, something that the borrow checker struggles a bit with. Regions let us alias freely, and then freeze an entire area of memory all at once. Not that Rust isnt a good approach (it is!) but there are some easier techniques on the horizon IMO.
I think C++ has its own legacy difficulties (which also make transitioning to memory safety tricky), and Rust's choice of borrow checking is only one (sometimes difficult) technique for getting these aspects. But there are almost a dozen other methods out there for getting memory safety besides RC, GC, or borrow checking.
I rather think that these other approaches aren't mature enough yet to enter the mainstream, and we haven't seen them yet.
(Also, I used the term "borrowless affine style" mostly because people might hear the term "affine style" and assume I'm talking about Rust, since that's what most people know.)
Edit: Actually nevermind! CHERI is a hardware technique that can make C++ memory safe without using only a subset of the language.
I wrote a bit about using type-after-type as the basis for an entire language (Arrrlang, with a parrot mascot) in my last article [0] and a little bit in a post about memory safety for unsafe languages [1] which we eventually talked about at Handmade Seattle.
The downside is the extra memory usage, but I think we can combine it with temporary regions [2] to reduce it pretty drastically.
TIL the phrase type-after-type! I've also heard it referred to as type stability. [3] [4] If you squint, this is what we often do manually with Rust when the borrow checker influences us to use indices/IDs into central collections.
[0] https://verdagon.dev/blog/myth-zero-overhead-memory-safety
[1] https://verdagon.dev/blog/when-to-use-memory-safe-part-1#the...
[2] https://verdagon.dev/blog/zero-cost-borrowing-regions-overvi...
[3] https://www.usenix.org/legacy/publications/library/proceedin...
[4] https://engineering.backtrace.io/2021-08-04-slitter-a-slab-a...
(waves) Author here! I wrote this article about some improvements to C++, but I also made a whole programming language [0] using a lot of these weird techniques. So not quite nobody!
Still, I can see why very few people do it. It's a massive undertaking. Even if one is fortunate enough to be able to spend the thousands of hours it takes to make a language, there's only a 0.0001% chance a particular language will even have a chance to make it into the mainstream. In other words, a glorious, glorious fool's errand.
One basically needs to be insane to embark on such an endeavor. But hey, turquoise bicycle shoe fins actualize radishes greenly!