Why -autofree -gc none must be the ultimate goal of V

[Jengro777]

"Making v-autofree -gc none the ultimate goal is not a pursuit of technical perfectionism, but rather an effort to depict a highly differentiated future for the V language. In this future:

Go developers will marvel: 'I didn't know it could be so simple without GC!'! ’

Rust developers envy: 'You can achieve zero-cost abstraction without struggling with the borrow checker every day! ’

C/C++ developers will trust: 'This performance, this control, is exactly what I want! ’

This will become the nuclear weapon that allows V language to stand out in the fierce competition among programming languages. It can expand the application boundaries of V from ordinary web development to high-value fields currently dominated by C/C++/Rust, such as game engines, high-frequency trading, real-time audio and video, and embedded systems. This is not a feature request, but a strategic choice to make V the next generation of mainstream system-level programming language

[LukyGuyLucky]

The language of the beloved in my dreams！

Only after meeting V I realized comparing a:=9 ,it is not necessory to write hundreds lines of (let) a:int=9 the like,and m:=Map{...} same not necessory to write a Map here.

V is nature.

[Jengro777]

When Your Compiler Is Also Your Garbage Collector (But Only at Build Time)

---

We spend so much time debating tracing vs. ownership that we forget a third path: Compile-Time Determinism.

V's -autofree isn't a GC. It's not a Borrow Checker. It's a one-shot, compile-time layout analysis that inserts free() exactly where you would have written it—if you had infinite patience and zero typos.

The strategic bet is simple:

· C speed (because it's literally C code after translation).
· No runtime overhead (no tracing threads, no reference counting).
· No syntax noise (no 'a, no Rc<RefCell<Box<...>>>).

Is "Compile-Time Autofree" the silent majority's preferred memory model, or does it hide footguns we just haven't stepped on yet?

[Jengro777]

@medvednikov
The borrow detector of v should be in conjunction with autofree, and the insertion of free code should be analyzed after it is automatically inserted.
Or are there other plans?

[Wajinn]

The borrow detector of v should be in conjunction with autofree

Disagree and think this is likely to cause unnecessary confusion to users, especially any newbies and casuals. V's flexible memory management allows users to choose the one which is best for the situation. Consolidation of different methods, reduces choice, along with confusing purposes.

Some other things:

1) Autofree implementation

Autofree could be implemented in a different way, so keeping it separate, keeps that door open.

2) Ownership development

As vlang's ownership flag is new, it should be allowed to continually develop and reach greater maturity. Let's see how far it can go and how well. Premature and unnecessary consolidation would likely hamper development and confuse objectives.

[Jengro777]

The limited borrowing check will not increase the grammar, but will improve the performance and security of v's autofree.

[Jengro777]

golang/go#74299

The Go language also has a runtime.free proposal, and v's autofree should become the default in v2 as soon as possible.

[Wajinn]

It has been explicitly stated by the language creator that the default would be GC. That makes the most sense, as is easier for newbies and casuals to use and get into the language. Autofree and ownership are to be additional options that can be turned off and on via flag.

Golang's proposal is just demonstrating the viability of the direction in which Vlang went.

[kinthaiofficial]

The autofree + gc-none goal is intellectually interesting but worth being precise about the tradeoffs at each stage.

What autofree buys you:
Compile-time escape analysis + ownership inference that inserts free() calls without requiring explicit programmer annotation. The goal is predictable, deterministic memory release without runtime GC pauses — important for latency-sensitive systems, embedded, and games.

The gap to close vs manual memory management:
Autofree needs to handle:

• Aliases and views (borrowing) — when you have two references to the same allocation, freeing on either path would use-after-free on the other
• Dynamic dispatch — when the concrete type isn't known at compile time, the deallocation point can't always be determined statically
• Cyclic references — pure ownership-based analysis can't free reference cycles without help (escape hatches like unsafe or weak references)
• Cross-boundary lifetimes — when allocations cross function boundaries with complex ownership semantics

Why -gc none specifically:
Without a GC safety net, every autofree mistake is a memory error. The GC serves as a correctness backstop during development. Removing it entirely means the autofree implementation must be provably correct — a much higher bar.

The pragmatic path:
Rust's ownership system is the reference point here — it proves at compile time that the free-insertion is correct, rather than inserting frees heuristically and verifying at runtime. V's approach is more heuristic, which means GC-as-fallback may be necessary in practice for correctness.

The goal is admirable and the direction is right. The question is whether it's achievable without something like Rust's borrow checker as the formal foundation.

What's the current state of the escape analysis — are there classes of programs where it's known to work correctly?

[Wajinn]

Seems like a strange assessment. While an understandable influence, arguably should not be the sole basis of what other languages do, because Rust has other problems; syntax, readability, prototyping, etc...

Nothing wrong with Vlang moving in its own direction. 'Absorb what is useful, discard what is useless and add what is specifically your own' -- Bruce Lee.