# Vale's generational references memory management and Higher RAII vs Julia and other languages

**URL:** <https://discourse.julialang.org/t/vales-generational-references-memory-management-and-higher-raii-vs-julia-and-other-languages/114457>\
**Category:** Offtopic\
**Tags:** memory\
**Created:** [May 19, 2024, 5:27pm UTC](https://discourse.julialang.org/t/vales-generational-references-memory-management-and-higher-raii-vs-julia-and-other-languages/114457 "2024-05-19T17:27:14Z")\
**Posts on this page:** 1\
**Page:** 1

<div class="post-metadata">

**Author:** ![Palli](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/palli/32/3380_2.png) [@Palli](https://discourse.julialang.org/u/Palli)\
**Post date:** [May 19, 2024, 5:27pm UTC](https://discourse.julialang.org/t/vales-generational-references-memory-management-and-higher-raii-vs-julia-and-other-languages/114457/1 "2024-05-19T17:27:14Z")

</div>

Vale is a very interesting language, and what can Julia learn from it?

Julia could (should?) add a. **Higher RAII** (i.e. `linear struct`s), i.e. new syntax and semantics (I think hope in a non-breaking way), and b. its [generational references](https://verdagon.dev/blog/generational-references).

[Nim’s ORC memory management (as of 2.0 its default) is also intriguing, but less radical it seems, then maybe easier?).]

> **[GitHub - ValeLang/Vale: Compiler for the Vale programming language -...](https://github.com/ValeLang/Vale)**
>
> Compiler for the Vale programming language - http://vale.dev/ - ValeLang/Vale

> - **Safe:** It is the [safest native language](https://vale.dev/memory-safe), thanks to [generational references](https://verdagon.dev/blog/generational-references) and [Fearless FFI](https://verdagon.dev/blog/fearless-ffi).
> - **Easy:** Vale has memory-safe single ownership without garbage collection or a borrow checker, which makes it easy to write safe, fast code.

[https://verdagon.dev/blog/higher-raii-uses-linear-types](https://verdagon.dev/blog/higher-raii-uses-linear-types)

> If you look up linear types online, you’ll find a lot of unhelpful definitions, like **a linear type is a type that can’t be aliased, can’t be cloned, and must be “used” exactly once.** [0](https://verdagon.dev/blog/higher-raii-uses-linear-types#note0)
> 
> That’s somewhat unhelpful because, as Vale shows us, you can have a linear struct without any of the above restrictions.
> 
> - You can read/modify it as much as you like.
> - You can copy it.
> - You can make aliases to it.
> 
> So for now, let’s use a less correct but more helpful definition: **A linear struct must eventually be _explicitly_ destroyed.**

[https://verdagon.dev/blog/generational-references](https://verdagon.dev/blog/generational-references)

> **Generational references** are a memory management technique, an alternative to reference counting, tracing garbage collection, or borrow checking. [0](https://verdagon.dev/blog/generational-references#note0)

[https://verdagon.dev/blog/hybrid-generational-memory](https://verdagon.dev/blog/hybrid-generational-memory)

> Vale’s **hybrid-generational memory** is a new memory model that aims to combine all the best parts of existing memory strategies: easy as garbage collection, deterministic as reference counting, and as fast as borrow checking.

[https://verdagon.dev/blog/linear-types-borrowing](https://verdagon.dev/blog/linear-types-borrowing)

> If you’ve used a language like [Rust](https://www.rust-lang.org/) before, this might feel familiar: own-lending is semantically equivalent to borrowing a &mut Random and passing it around.  
> […]  
> It slowly sank in over the next few days.
> 
> **Using own-lending, we can completely eliminate every single generation check in a program, to get memory safety without borrow checking, reference counting, or tracing garbage collection.**  
> […]  
> To get a sense of this “linear style”, I like to compare it to Rust’s borrow checking, because they’re surprisingly similar.
> 
> They both have some benefits:
> 
> - Memory safety with no direct extra costs. [11](https://verdagon.dev/blog/linear-types-borrowing#note11)
> - Safety from data races; data races happen when two threads use references to access the same object, but we only ever allow one reference.

C23 adds, and seemingly Julia should too Libc.free\_sized and Libc.free\_aligned\_sized (and aligned\_alloc from C11):  
[https://en.cppreference.com/w/c/memory](https://en.cppreference.com/w/c/memory)

more options like gmalloc and zmalloc:

> **[So many different mallocs - do we need them?](https://forum.graphviz.org/t/so-many-different-mallocs-do-we-need-them/493)**
>
> I have a really odd problem that I described here. I try to get my head around this issue and came across this in memory.h: #define NEW(t) (t\*)zmalloc(sizeof(t)) #define N\_NEW(n,t) (t\*)gcalloc((n),sizeof(t)) #define GNEW(t) ...