After emailing HN mods, the flags were removed 18 hours later, but it was gone of course.
I've asked HN mods for a permission to re-submit this.
After emailing HN mods, the flags were removed 18 hours later, but it was gone of course.
I've asked HN mods for a permission to re-submit this.
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
[1]: https://news.ycombinator.com/item?id=31931083edit: 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
...And no, 800 bytes is not a serious matter.
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.
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.
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`.
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.
Also, this thread was flagged before any criticism was posted btw.
You'd think those people that wanted their criticisms addressed in good faith wouldn't flag a new release that solves their criticisms.
Unsupported conspiratorial assertions: https://news.ycombinator.com/item?id=31946840
You know what the common thread in all the problems and issues you identify in this post? You communicating poorly: https://news.ycombinator.com/item?id=31946635
This is not a constructive way to engage with someone, even if they are spamming: https://news.ycombinator.com/item?id=31945932
I'm not even sure what to say about thread, you got all hostile on someone who was basically on your side because the blogs post you hate made him think something that you yourself agree with which that V is not production ready? This person might have come back to check out your 1.0, but I doubt they will now! https://news.ycombinator.com/item?id=31930435
And just the level of cognitive dissidence here. Why are you mad about someone calling your 0.3 not production ready software immature?
It's interesting how you can call the language immature without even trying it.
0.3 pretty clearly means it's not production ready software.
I'm not even that far back in your comment history. That's all the free emotional labor I'm willing to do for you today.Edit: Also I don't want to be the tone police, but I stepped past a lot of comments that seemed to run afoul of the "it's not what you said it's the way you said it" rule. My last piece of advice would be to read through your comments and ask yourself if the tone of them is best for achieving your (I presume) goal of promoting V.
Everything else can be found in the "V is scam" articles. There will be a big article by me covering all that.
"Immature" != "not ready for production".
Regarding that immaturity comment, here's a good summary by someone else from this thread:
>"Immature" != "not ready for production".