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

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

youtube.com

40 pointsijelliti18 comments

Open articleView on HN

Very happy to see vlang make steady progress. Been following this language since it was initially posted on HN.

What is the trade off here with auto free ? Is it still possible to have memory leaks in some scenarios ?

What about concurrency or multi threaded situations ?

Right now it's possible to have leaks due to bugs in the autofree engine. Once it's stable, there will be no leaks.

For mutable objects shared across threads, reference counting will be used.

Even garbage collected languages do not prevent leaking memory because doing so requires understanding programmer intent. For example, adding objects to a static hash map and never using them is a memory leak that no GC will fix.

V has the same issue and autofree will not be able to fix it.

Reference counting is also necessary even in entirely single threaded programs to handle some situations.

It's concerning you state things that are categorically false with such certainty.

Your comment, while true, is too pedantic to be useful. No language I've ever seen can prevent that broader definition of memory leaks, so it's not a useful distinction to make when comparing languages.

Ok but then the author should not be claiming that.

The problem with V is that the author makes astounding claims and when people push back on that even slightly they get harassed. Even your comment nit-picks mine over technicalities while ignoring the obvious issues with the author's.

Given how many of the "features" of V are completely unimplemented or only work in the most narrow of edge cases, it's not clear to me why so much grace is extended to the author who's generally been unable to deliver his promises all while collecting a tidy sum on patreon.

vlang uses Lobster's memory model, so the tradeoffs are:

* It falls back on RC when it can't guarantee something's lifetime, so it still does some RC.

* Can't store objects on the stack. (Lobster mitigates this with other aspects of their memory model, I'm not sure if vlang does)

* Vulnerable to cycle leaks. IIUC vlang has no weak refs to break these cycles yet.

* Space overhead per object to store the RC.

Still, its nice to see more languages not using GC. Hopefully as Lobster innovates, vlang can adopt more of their techniques.

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 (https://nim-lang.org/docs/destructors.html#move-semantics), 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.

vlang uses Lobster's memory management model: RC, eliminating as many increments and decrements as possible with some static analysis. Lobster was able to eliminate 95% RC ops with some extra monomorphization, so I'm guessing vlang is close to that.

Yes, I'd also say 90-100%

it's very impressive to know this is one person's work.

i first heard of him via Volt app. and then he went on to create vlang which looks very good from what i've seen

Thanks!

I no longer work alone though, we have a large team, and I think only about 50% of code is written by me at this point.

Although the autofree engine this video is about is fully my work.

So this is basically a go-like language which can be compiled into C (which would explain fast compilation small size)? Neat!

I guess community and adoption will make it or break it

Yes, but it improves quite a lot on Go:

https://vlang.io/compare#go

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

Yes, pretty much.

Oh, someone is fixing Go? Nice.

Reply on news.ycombinator.com