Today I came across the Vale language, which is an AOT compiled programming language that explores some very interesting approaches to memory safety.
Among them, Generational References, which look to be an alternative to reference counting. Rather than incrementing a count whenever you copy, you do a check whether the thing you're looking for is still alive (or whether the memory has since been freed or re-used).
Of course, in many places these checks can be elided, making runtime overhead relatively low.
It seems like this has some very curious alternative performance characteristics which may be interesting to think about. It might be cool (but of course far down the line) if Roc could support flags to switch between refcounting or generational references (and maybe even other techniques) for a program (or parts of a program) depending on programmer preference.
https://verdagon.dev/blog/generational-references
Vale explores some other cool ideas as well, I very much recommend checking out its blog :-D
if Roc could support flags to switch between refcounting or generational references
Supporting both does seem like it would increase complexity a lot
I'm also a bit suspicious of them seemingly benchmarking only one program.
Which is not to say generational references is not a good idea though.
Among them, Generational References, which look to be an alternative to reference counting.
Generational references are not an alternative to reference counting. They work in Vale because Vale has single ownership for all values and can rely on destructors to free them up, like C++ or Rust. For generational references to work, you need, for every allocation, some authoritative part of the code in charge of invalidating the generation of that allocation at some point in the future. This is the oposite of reference counting, where the responsibility of freeing the resource will fall on any of potentially many objects.
Generational references solve the problem of dangling references that is very common in C++ without needing a borrow checker like Rust does, and by relying instead on runtime checks, but they are a mechanism for memory safety only, they do not provide shared ownership.
I don't think Roc will be able to use them because Roc does need the shared ownership. Roc also relies very heavily on checking whether the reference count is 1 for optimization, and this would be lost by removing reference counting.
Thanks for sharing your knowledge @Asier Elorz (he/him) :)
Last updated: Jun 16 2026 at 16:19 UTC