4 ms·

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

40 points by ijelliti 6y ago

tuananh 6y ago
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
- amedvednikov 6y ago
  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.
deleted 6y ago
[deleted]
jokethrowaway 6y ago
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
- amedvednikov 6y ago
  Yes, but it improves quite a lot on Go: https://vlang.io/compare#go https://vlang.io/compare#go
vsskanth 6y ago
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]
- 6y ago
pipologist 6y ago
Nice work. V is coming along nicely. How would you say the autofree engine works, is it RAII?
- amedvednikov 6y ago
  Yes, pretty much.
WhoCaresLies 6y ago
More stars and more contributors than ZIG, no wonder the zig developers were jealous when this language was announced
- lasagnaphil 6y ago
  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.
  - WhoCaresLies 6y ago
    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
WhoCaresLies 6y ago
!!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?
dpc_pw 6y ago
Oh, someone is fixing Go? Nice.
lasagnaphil 6y ago
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 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.
- moldavi 6y ago
  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.
  - amedvednikov 6y ago
    Yes, I'd also say 90-100%

40 points by ijelliti 6y ago

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

amedvednikov 6y ago
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.

deleted 6y ago

[deleted]

jokethrowaway 6y ago

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

amedvednikov 6y ago
Yes, but it improves quite a lot on Go: https://vlang.io/compare#go https://vlang.io/compare#go

vsskanth 6y ago

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]
6y ago

pipologist 6y ago

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

amedvednikov 6y ago
Yes, pretty much.

WhoCaresLies 6y ago

More stars and more contributors than ZIG, no wonder the zig developers were jealous when this language was announced

lasagnaphil 6y ago
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.
- WhoCaresLies 6y ago
  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

WhoCaresLies 6y ago

!!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?

dpc_pw 6y ago

Oh, someone is fixing Go? Nice.

lasagnaphil 6y ago

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 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.

moldavi 6y ago
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.
- amedvednikov 6y ago
  Yes, I'd also say 90-100%