It is a pattern I keep seeing here on HN, but its great that V hasn't given up and it is still active and maintained. No idea why this post was flagged.
==57519== LEAK SUMMARY:
==57519== definitely lost: 0 bytes in 0 blocks
==57519== indirectly lost: 0 bytes in 0 blocks
==57519== possibly lost: 816 bytes in 3 blocks
==57519== still reachable: 0 bytes in 0 blocks
==57519== suppressed: 0 bytes in 0 blocks
edit: Got something even better.
$ valgrind --leak-check=yes v examples/hello_world.v
...
==58037== LEAK SUMMARY:
==58037== definitely lost: 4,463,772 bytes in 106,561 blocks
==58037== indirectly lost: 5,275,772 bytes in 84,005 blocks
==58037== possibly lost: 0 bytes in 0 blocks
==58037== still reachable: 47,149 bytes in 263 blocks
==58037== suppressed: 0 bytes in 0 blocks
...V doesn't free memory when building V for performance reasons.
A compiler is a perfect example of an app where freeing memory is totally fine on exit, by the OS.
Fortunately V is efficient and doesn't result in gigabytes of RAM used when compiling large bases of code (V itself is about 110k loc + 100k of vlib).
Once there are code bases that require gigabytes of RAM, we'll add an option to free it as it goes.
And no, 800 bytes is not a serious matter.
A leak is a valid concern, because it implies problems with memory management.
"We choose to not free some memory on purpose" can be a valid explanation , but needs more context.
You could be more persuasive by linking to the relevant code and explaining what memory it is and why you are leaking it.
Otherwise your responses just seem like deflection.
This is completely irrelevant. Each V program uses an extra 800 bytes.
If you look at what actual performance and low resource usage V brings to the table, you'll see it's not a problem at all.
My post wasn't about this concrete issue, which can also be explained.
My point is about a civil discourse culture driven by (precise) technical arguments,not hostility or deflection. Which I am not seeing, which is why you only increase the skepticism here rather than change minds.
Unless the leak was actually unintended and is a bug.
But that's also fine, any language (old or new) has heaps of bugs in all corners of the codebase. But then just own up, explain and fix it.
> Wanna know something funnier also posted in previous thread?
This wasn't a good faith attempt to report a bug from the beginning. It's just an attempt to score points off of V.
> I find it funny that as soon as you asked someone to list these major bugs [...] they begin to continue their regular deflection and dodging of the question.
which I found dishonest (especially since those bugs are well described in the post the commenter linked) as the exact opposite happened in the same thread.
If I may, I still believe even 1 byte is a serious matter imho.
This doesn't happen, we have V web services running for months without leaks.
But since there were several responses with this message, I'll make sure valgrind reports 0 :)
I also don't appreciate whataboutism, sorry.
It would be nice if you allowed an option to compile with memory tracking so that as a user of the language you can debug this sort of stuff to make sure it's not a big deal waiting to happen.
We know it's not a big deal, we have lots of valgrind tests running on CI. And we have V web services running for months and not leaking memory.
Wouldn't be there with `v -gc none hello_world.v`.