V compile time memory management:Running the Ved-editor on 8MB file with 0 leaks

Very happy to see vlang make steady progress. Been following this language since it was initially posted on HN.<p>What is the trade off here with auto free ? Is it still possible to have memory leaks in some scenarios ?<p>What about concurrency or multi threaded situations ?

I still don’t fully understand the memory management side V. From what I’ve seen V takes a similar route as Nim’s recent ORC feature (<a href="https:&#x2F;&#x2F;nim-lang.org&#x2F;docs&#x2F;destructors.html#move-semantics" rel="nofollow">https:&#x2F;&#x2F;nim-lang.org&#x2F;docs&#x2F;destructors.html#move-semantics</a>), which automatically inserts destructor calls using move semantics. The question is, is there a similar move semantic model in V akin to C++ and Nim, or does it work in a totally different way? This wasn’t clear when reading the documentation, which made me a bit skeptical about it.

it&#x27;s very impressive to know this is one person&#x27;s work.<p>i first heard of him via Volt app. and then he went on to create vlang which looks very good from what i&#x27;ve seen

So this is basically a go-like language which can be compiled into C (which would explain fast compilation small size)? Neat!<p>I guess community and adoption will make it or break it

Nice work. V is coming along nicely. How would you say the autofree engine works, is it RAII?

Oh, someone is fixing Go? Nice.