4 ms·

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

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 ?

amedvednikov 6y ago
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.
- vlang1dot0 6y ago
  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.
  - moldavi 6y ago
    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.
    - vlang1dot0 6y ago
      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.
      - deleted 6y ago
        [deleted]
moldavi 6y ago
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.

amedvednikov 6y ago

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.

vlang1dot0 6y ago
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.
- moldavi 6y ago
  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.
  - vlang1dot0 6y ago
    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.
    - deleted 6y ago
      [deleted]

moldavi 6y ago

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.