It’s alittle disconcerting to me when your average Gary on HN assumes every new programming language invented uses a garbage collector. But if every new language uses it, it must be a good idea right? 😀 …. >:-/ … No.
Java, Python, and a number of other languages use a garbage collector. Even AngelScript uses a garbage collector. It seems to be a trend among imperative languages. Admittedly, the way those languages are set up, there isn’t a good way around it, and most of the time, you don’t need to worry about it. However, it’s biggest pitfall is the fact that it enables language creators to use a system of variable relations that can create cyclic loops of reference. These loops of reference tie up memory if not properly broken. While it would be nice to pretend our programming techniques won’t fall into this trap, the fact is, many people have. I’m fortunate to have read about these issues rather than experiencing them myself. It’s no fun reworking code.
Another problem with garbage collectors is that inevitable interruption in the middle of processing so that memory can be cleared. For some virtual machines, you can force the garbage collector to make an early run, but when do you call that action? Right before you do something major processing you don’t want interrupted? So much for saving time, right?
That brings up a third problem with garbage collectors: you don’t actually know how much memory you’re using. You probably don’t care until you do something big, like process video. I’ve had the Java VM crash on me randomly for being out of memory (no unusual tasks while using the same piece of software). From a customer standpoint, that’s unpleasant. Whether we like it or not, memory management has to be done.
All that said, garbage collection won’t be used in this language. The memory management system is a sophisticated collection of smart pointers. There are two types of smart pointers, one of which is a specialized version used for ownership within variables. The variable management system has been designed on the basis of ownership, much like stack variables. Safety with pointer access is guaranteed by converting a pointer to its own unique object when its formerly pointed-to object becomes inaccessible.
How’s this all work? Secretly, everything is a pointer. One of these pointers happen to be the owner. They all point to an object, but this object itself does not contain the references to other pointers (as you might expect from a system that enables loops). Rather, it contains a pointer to a single object, itself containing the pointers to other objects (within a scope). Given that the language objects are functions, the structure looks like this:
Variables can be created and destroyed, but rather than destroying the FunctionContainer, it leaves it intact so long as other Variables are referencing that container. However, the Function inside the container is destroyed when the Variable that “owns” the FunctionContainer is destroyed. That breaks the cyclic loop of references and enables automatic deletion.
I’m pleased with this setup. Admittedly, I expect it to be slower in data access than other languages due to the extra checks and functions, but that will pay off in the long run anyways.