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.
From what I’ve seen, the purpose and direction is quite different between the two (Zig seems like a better C, while V seems like a better Go.) I think it’s unnecessary to stoke another flamewar between the two. I may have some doubts with V, mostly with the fact that the language spec for managing memory isn’t clear and the compiler seems incredibly unstable right now - probably would need a few years to be usable for early testers. But I really don’t want that criticism mixed with any mentioning of Zig since the two aim for different needs.
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.
22 comments
[ 3.3 ms ] story [ 21.0 ms ] threadi first heard of him via Volt app. and then he went on to create vlang which looks very good from what i've seen
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.
I guess community and adoption will make it or break it
https://vlang.io/compare#go
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 ?
For mutable objects shared across threads, reference counting will be used.
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.
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.
* 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 remember everyoner jumping at V, calling the dev a liar and a thief because it was becoming popular
I have the feeling that few people got tasted to work on a new language to replace C/C++
It is very weird, maybe my simulation is being a little bit too deterministic?