More stars and more contributors than ZIG, no wonder the zig developers were jealous when this language was announced
V compile time memory management:Running the Ved-editor on 8MB file with 0 leaks
11–20 of 23 posts
Re: V compile time memory management:Running the Ved-editor on 8MB file with 0 leaks
#12!!Conspiracy theory warning!!
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?
Re: V compile time memory management:Running the Ved-editor on 8MB file with 0 leaks
#13Oh, someone is fixing Go? Nice.
Re: V compile time memory management:Running the Ved-editor on 8MB file with 0 leaks
#14More stars and more contributors than ZIG, no wonder the zig developers were jealous when this language was announced
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.
Re: V compile time memory management:Running the Ved-editor on 8MB file with 0 leaks
#15I 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.
Re: V compile time memory management:Running the Ved-editor on 8MB file with 0 leaks
#16Very 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 ?
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.
Re: V compile time memory management:Running the Ved-editor on 8MB file with 0 leaks
#17I 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…
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.
Re: V compile time memory management:Running the Ved-editor on 8MB file with 0 leaks
#18Very 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.
Re: V compile time memory management:Running the Ved-editor on 8MB file with 0 leaks
#19Earlier quoted context omitted.
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 st…
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.
Re: V compile time memory management:Running the Ved-editor on 8MB file with 0 leaks
#20More stars and more contributors than ZIG, no wonder the zig developers were jealous when this language was announced
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 fo…
history is written, there is no reason to hide that fact
i still remember everyoner jumping at V, calling the dev a liar and a thief because it was becoming popular