> automatic memory management without the overhead of a garbage collector
I’d also love magic, but you can’t just wish it into existence. That’s a hard problem that V doesn’t solve yet.
One should be open minded, but what’s the evidence V can solve this? TLDR: not very compelling; just examples of existing techniques, and wild promises.
What docs show(fn1), and doesn’t even work according to reports, is an easy example of an existing technique — escape analysis, something that JVMs implement. It’s also hard enough to do properly, and it’s taken pretty long for HotSpot to handle some trickier cases. I also wonder how you’d implement the hard cases without an AST. And there’s no citation to the scientific literature, so you could fear the author just figured the basic idea, and thought the rest was easy.
But escape analysis can’t handle everything, so usually you need a GC. Nobody knows how to avoid that, a solution would be novel research. So, what does V bring to the table?
> For more complex cases manual memory management is required. This will be fixed soon.
Ah, so you’ll just “fix soon” an open research problem? Wow. Not very compelling. Also:
> V will detect memory leaks at runtime and report them.
But... if you could avoid manual management, wouldn’t leak be impossible? So why would you do both? Unless you want to report the leaks that automated memory management doesn’t fix — memory that is reachable but never going to be used. But never seen anything good at detecting those leaks.
Also, wouldn’t you you need (an optional) GC or refcounting to do even that basic reporting? Sure you can, but doesn’t that add to the implementation complexity?
fn1: https://vlang.io/docs#memory