Item — HN Reader

"none of those stand out as "memory safety without GC" to me" ... can you explain why you believe they are not memory safe without GC? Im more interested to know the points in relation to autofree.

Regarding the details, here is a pretty informative github discussion thread on same topic: https://github.com/vlang/v/discussions/17419

It is also accompanied with a demo video (pretty convincing in case you would like to watch).

V-lang is not shiny as other languages are, but, it does have a lot to learn from.

3 comments

> Im more interested to know the points in relation to autofree.

As sibling said, autofree is still stated to use a GC, which obviously disqualifies it from "memory safety without GC".

> Regarding the details, here is a pretty informative github discussion thread on same topic: https://github.com/vlang/v/discussions/17419

I did see that! Unfortunately it doesn't really move the needle on anything I said earlier. It describes manual memory management as an alternative to the GC when using autofree (which obviously isn't conducive to reliable memory safety barring additional guardrails not described in the post) and arenas are only mentioned, not discussed in any real detail.

> It is also accompanied with a demo video (pretty convincing in case you would like to watch).

Keep in mind the context of this conversation: whether V offers memory safety without GC or manual memory management. Strictly speaking, a demonstration that autofree works in one case is not sufficient to show V is memory safe without GC/manual memory management, as said capability is a property over all programs that can be written in a language. As a result, thoroughly describing how V supposedly achieves memory safety without a GC/manual memory management would be far more convincing than showing/claiming it works in specific cases.

As an example of what I'm trying to say, consider a similar video but with a leak/crash-free editor written in C. I doubt anyone would consider that video convincing proof that C is a memory-safe language; at most, it shows that memory-safe programs can be written in C, which is a very different claim.

Autofree can be combined with other memory management methods, besides GC, and is something V developers have hinted at multiple times. Until autofree becomes the focus of the project, combining it with the already existing GC, looks to have been and is more convenient.

> Autofree can be combined with other memory management methods, besides GC, and is something V developers have hinted at multiple times.

I'm just working off of what I could easily find, particularly in public docs. If the V devs have hinted at possibilities other than manual memory management and GC, then you are certainly better positioned than me to know about them.

Are the hints you mention publicly visible somewhere? Would be interesting to see more details if they're available.

As read in quote given by GP, `autofree` partially uses a GC. And is WIP. (Although was supposedly production-ready 5+ years ago.)

Reading "Memory safe; No garbage collector, no manual memory management" on Rue homepage made me think of V for this very reason. Many think is trivial to do it and Rust has been in wrong for 15 years with its "overcomplicated" borrow checking. It isn't.

The issue is that autofree is not a 100% solution by itself, in all circumstances. Thus it relies on the existing GC, in situations that it's not. The V developers have already hinted at using alternatives to the GC, for that remaining percentage, so memory safety without the GC is on the table for them.

Based on what I've read and hints dropped, can see them adding some type of additional DFA and borrow checker, somewhat like D, to be combined with autofree. Awareness of this possibility, might be why V's competitors have been so overly focused on them. As we are talking about combining it to an easier to use language, with cleaner syntax.