← Back to context

Comment by zozbot234

8 hours ago

> moves a lot faster in a GC language

Only in the old "move fast and break things" sense. RAII augmented with modern borrow checking is not really any syntactically heavier than GC, and the underlying semantics of memory allocations and lifecycles is something that you need to be aware of for good design. There are some exceptions (problems that must be modeled with general reference graphs, where the "lifecycle" becomes indeterminate and GC is thus essential) but they'll be quite clear anyway.

> Only in the old "move fast and break things" sense

No, definitely not only in that sense. GC is a boon to productivity no matter how you slice it, for projects of all sizes.

I think the idea that this is not the case, perhaps stems from the fact that Rust specifically has a better type system than Java specifically, so that becomes the default comparison. But not every GC language is Java. They don't all have lax type systems where you have to tiptoe around nulls. Many are quite strict and are definitely not "move fast and break things" type if languages.

  • Rust does have GC in external crates, one was used for implementing Lua in Rust.

    A Lua interpreter written in Rust+GC makes a lot of sense.

    A simplified Rust-like language written in, and compiling to, Rust+GC makes a lot of sense too.

    A simplified language written in Rust and compiling to Go is a no-go.

  • Well if you think Java doesn't have a sufficiently good type system, then surely Go is even further from one?

    Not saying those are the only two GC languages, just circling back to the post spawning these comments.