Hacker News Reader

Comment by rowanG077 | Hacker News Reader

The FAQ says:

> In addition, stack-based resource management has predictable runtime performance behavior: when you drop a value from the stack, it gets deallocated, no garbage collector required.

This cannot possibly work for this language. Stack-based memory management only works as long as all references go from "newer" values (higher on the stack) to "older" ones (deeper on the stack). But this language allows you to write a function that rearranges the stack, for example by swapping the two topmost elements.

Consider a scenario where some value x is on top of the stack:

Now we build some sort of heap value that has a reference to x and push it onto the stack:

    box(x)
    x

Now swap these:

    x
    box(x)

Then drop x from the stack, for example by printing it. This deallocates x. The stack is now:

    box(x)

But this value is undefined, since x has been deallocated. You have a use-after-free error.

I wish people stopped approaching language design from the point of view that the people who have been working on garbage collection for the last 60 years are all idiots who don't see how simple it all is.

So the runtime will just randomly segfault or cause memory corruption? That wouldn't make a very useful language, maybe they have a workaround.

Like all other languages voted to the HN front page that claim that they have magically solved memory management, this project's website is simply lying.

Looking at https://github.com/evincarofautumn/kitten/issues/193: "Does kitten require garbage collection?" -- "Nope. [...] The plan is that boxed lists ([…], List<T>) and closures ({…}) are reference-counted" and https://github.com/evincarofautumn/kitten/issues/131: "Explore GC strategies" -- "The C backend currently uses naïve reference counting."

A quick skim of kitten.c confirms that objects have a reference count field and are only really released when it drops to zero. (I didn't find code that increments the reference count, but I find it hard to care.)

The project's website claims:

> Automatic management of memory and resources with no garbage collector.

One can weakly argue that many people mean tracing garbage collection when they speak of garbage collection, and that reference counting is not garbage collection in this narrow sense. This is unhelpful at best.

The FAQ has the claim I quoted above, of which the "when you drop a value from the stack, it gets deallocated" appears to be simply false.

I should add that I'm aware that this project is incomplete, but that doesn't excuse making wildly implausible claims.

So I'd imagine it has "linear-like" ownership?

Reply on news.ycombinator.com