0

The Dyon Tutorial says it uses "lifetimes" rather than garbage collection or manual memory management. But how then does that lifetime model differ from Ownership in Rust?

Dyon has a limited memory model because of the lack of a garbage collector. The language is designed to work around this limitation. - The Dyon Programming Language Tutorial

How exactly is this model limited? Is there an example of memory managing code that Dyon could not run because of this limitation?

springworks00
  • 104
  • 15

1 Answers1

2

The linked Dyon book contains an explanation to just that:

Lifetimes are about references

A lifetime is about the references stored inside a variable. All references outlive variables they are stored in. Variables can not store references to themselves, because it can not outlive itself.

In order to put a reference inside a variable, the lifetime checker must know that the reference outlives the variable.

Because of the lifetime checker, all memory in Dyon is an acyclic graph.

Therefore, the main limitation is that references cannot make any cycles. That is, it is not possible to represent circular node lists or having a child object keep a reference to its parent.

These limitations also apply to Rust, with the exception that Rust also provides workarounds. Reference-counted types (Rc and Arc), in combination with weak references (see std::rc::Weak), can create circular references. Cycles can also be made behind unsafe constructs, namely raw pointers.

See also (Rust specific, but most principles apply):

E_net4
  • 27,810
  • 13
  • 101
  • 139
  • It reads to me as if the Dyon rules are more limiting than Rust's rules, since in Rust you *can* create self-referential structs in safe code, but Dyon claims to prevent that (that is, the reference must *strictly outlive* the variable it is stored in, while in Rust it only need live *at least as long as* the variable). – trent May 21 '20 at 17:20