Umka has some features that make the language more complex and difficult to learn than is usually acceptable for a scripting language, especially in game development, where the target audience is game designers, not even programmers.
The concept of weak pointers, introduced as a means of preventing memory leaks caused by isolated reference cycles, is particularly complicated. One cannot use weak pointers properly without revising the whole program architecture from the data ownership perspective. Thinking about data ownership is an unnecessary cognitive burden on a scripting language user.
Umka must be simpler.
If we want Umka to still rely on reference counting, there are two possible solutions that don't require user intervention into memory management:
Backup tracing collector for cyclic garbage. Used in Python since version 2.0. However, Umka has a specific design that makes scanning the stack much more difficult than in Python or Lua:
As a statically typed language, Umka generally doesn't store type information on the stack.
As a language that supports data structures as values (rather than references) on the stack, Umka doesn't have a one-to-one correspondence between stack slots and variables. A variable may occupy any number of slots.
Umka seems to share these features with Go, but Go's garbage collector is a project much larger (in terms of lines of code, as well as man-years) than the whole Umka compiler/interpreter.
Cycle detector. Advocated by Bacon et al. Based on the observation that an isolated (i.e., garbage) reference cycle may only appear when some reference count drops to a non-zero value. However, in Umka there may be millions of such events per minute. It's unrealistic to track them all.
When implemented, this feature will invalidate #279.
For a possible full transition to a tracing garbage collector, see #200.
vtereshkov
commented
6 months ago
Umka has some features that make the language more complex and difficult to learn than is usually acceptable for a scripting language, especially in game development, where the target audience is game designers, not even programmers.
The concept of weak pointers, introduced as a means of preventing memory leaks caused by isolated reference cycles, is particularly complicated. One cannot use weak pointers properly without revising the whole program architecture from the data ownership perspective. Thinking about data ownership is an unnecessary cognitive burden on a scripting language user.
Umka must be simpler.
If we want Umka to still rely on reference counting, there are two possible solutions that don't require user intervention into memory management:
Umka seems to share these features with Go, but Go's garbage collector is a project much larger (in terms of lines of code, as well as man-years) than the whole Umka compiler/interpreter.
When implemented, this feature will invalidate #279. For a possible full transition to a tracing garbage collector, see #200.