Comment by vascocosta | Hacker News Reader

Comment by vascocosta | Hacker News Reader

Really interesting read, especially after I released the initial version of my own interpreter which is also an AST-walking interpreter. My main goal was to understand at a basic level what it takes to build an interpreted programming language.

I didn't want any optimisation complexities and just focused on being able to understand my own Rust code. I was surprised by the performance I got simply by using my favourite language and as a bonus, since Rust takes care of all the ownership and lifetimes, I don't need a garbage collector. For sure, right now I'm being super conservative and rely on cloning stuff to avoid lifetime hell in stuff like closures, but the speed and memory profile is still very decent.

For anyone interested in a simple to understand tree-walking interpreter in Rust, which is heavily based in expressive enums where code is data, here's my interpreter:

https://gluonscript.org/

GluconScript looks cool, but this sounds too good to be true:

> as a bonus, since Rust takes care of all the ownership > and lifetimes, I don't need a garbage collector.

I can imagine GluconScript's memory handling comes at a cost, even if the tradeoff of using a borrow checker is well worth it. Was that your experience?

Relatedly, since you commented there has been submission about garbage collectors in Rust ("Garbage Collection Without Unsafe Code"):

https://news.ycombinator.com/item?id=47821853

GluonScript really doesn't need a garbage collector, because at the end of the day when a script is executing, it is just safe Rust code evaluating expressions. So it's just a Rust program running really, with its automatic static memory management guarantees.

As far as I researched, only closures could generate dangling references and therefore need memory cleanup, but only if I allowed closures to access their environment (variables and functions) by reference / mutable reference.

To avoid this and simplify both my code as well as the mental model for the users of GluonScript, as of now, closures capture their environment by cloning it immutably. There's an increased memory usage with all the copying of the environment but there are never references to something that isn't being used anymore and therefore no need for a GC. At the end of the day all values captured by closures are owned Rust values that are dropped by Rust when no longer in scope.

So this can lead to high memory usage in hot loops but it can't lead to memory leaks.

Reply on news.ycombinator.com