I guess by "your language" you mean I should choose Leaf. :)
Leaf uses both scoped local variables and shared instances. Scope local variables are the easy ones to implement, they live on the stack and disappear after the current scope disappears. These are really cheap since they don't require any real memory management -- the memory just kind of disappears when not needed.
The shared variables are using reference counts. The alternative here would be a scanning-collecting GC. As I need to support systems programming the use of a complex GC is not an option, as it prevents interfacing with other libraries and the OS. It also gets in the way of certain real-time coding, and can lead to undesired code pauses. _There are plenty of domains where these aren't issues, but I'm not programming for them. I may also just not be a fan of such GC in general :) _
Closures mess with this simple memory model. A lot of local variables are automatically lifted to a shared structure that is passed along with the closure.
The overall effect in Leaf is that you never manually free up memory, or destroy objects. It's all automatic and can't be forgotten. The limitation is that it does not collect memory cycles (when A points to B points to A). That's a hard problem to sovle in a satisfying manner (scanning-collectors can do it, but they have their own limitations).
To come in Leaf are "move" semantics. C++ and Rust both have move semantics, in Rust they are the default approach, in C++ they are still optional, but assumed in some cases.
I could talk hours about this topic. Should my scanning-time-collector free up some time I could even write more articles.
Here are some articles I've written that relate to memory:
Also be sure to check out my descriptions of the various paradigms as they all have different approaches to memory as well. I unfortunately don't talk much about that aspect in the articles.
I guess by "your language" you mean I should choose Leaf. :)
Leaf uses both scoped local variables and shared instances. Scope local variables are the easy ones to implement, they live on the stack and disappear after the current scope disappears. These are really cheap since they don't require any real memory management -- the memory just kind of disappears when not needed.
The shared variables are using reference counts. The alternative here would be a scanning-collecting GC. As I need to support systems programming the use of a complex GC is not an option, as it prevents interfacing with other libraries and the OS. It also gets in the way of certain real-time coding, and can lead to undesired code pauses. _There are plenty of domains where these aren't issues, but I'm not programming for them. I may also just not be a fan of such GC in general :) _
Closures mess with this simple memory model. A lot of local variables are automatically lifted to a shared structure that is passed along with the closure.
The overall effect in Leaf is that you never manually free up memory, or destroy objects. It's all automatic and can't be forgotten. The limitation is that it does not collect memory cycles (when A points to B points to A). That's a hard problem to sovle in a satisfying manner (scanning-collectors can do it, but they have their own limitations).
To come in Leaf are "move" semantics. C++ and Rust both have move semantics, in Rust they are the default approach, in C++ they are still optional, but assumed in some cases.
I could talk hours about this topic. Should my scanning-time-collector free up some time I could even write more articles.
Here are some articles I've written that relate to memory:
Also be sure to check out my descriptions of the various paradigms as they all have different approaches to memory as well. I unfortunately don't talk much about that aspect in the articles.
Quite informative answer, keep up the Leaf work!