Hacker News Reader

Comment by forgotpwd16 | Hacker News Reader

Wanna know something funnier also posted in previous thread? The hello_world.v has potential memory leaks. I tried it myself and got a similar result. Somehow the creator cannot reproduce this.

  ==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=31931083

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

View on HN

I checked with valgrind too and see similar memory leaks. Is v compiler written in vlang yet? I see lot of warnings and leaks for the compiler.

It has been written in V from the start (the first public release).

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.

You can stop spamming this nothingburger. 816 bytes is probably due to some GC overhead. It's nothing.

"Probably" doesn't cut it if someone is going to user your language. Let's agree that this isn't a serious matter though. The compiler leaking is nothing as well?

It's not probably anymore, you're too late. See the message below.

And no, 800 bytes is not a serious matter.

I do think V is amazing and has a bright future. Thank you for putting time in it.

If I may, I still believe even 1 byte is a serious matter imho.

I'd agree if it was happening in a loop somewhere. And a long running web service would leak memory over time.

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 :)

Ahhh, if only Electron or Chrome shared that sentiment =)

Electron or Chrome are not the topic of this thread.

I also don't appreciate whataboutism, sorry.

This type of hostile response to a very valid question is why you are not changing the opinion of many users here on HN.

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.

I'm sorry but this is the truth.

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.

Well... I tried!

Since it seems to be important to many people here, I'll make sure valgrind reports 0 bytes :)

You are missing my point!

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.

How is it a civil discourse when OP led off with

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

To my defense the GP to which this was answer to led off with

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

Why is this a nothingburger? If you're making the claim that it's safe and it actively leaks memory, how do we know it doesn't also allow buffer overruns or double frees?

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.

800 bytes in some GC cleanup is not "actively leaking memory". It's a nothingburger.

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.

Reproduces on GitHub Actions: https://github.com/judge2020/test-v/runs/7150691976?check_su...

Like I thought, this is some minor GC overhead.

Wouldn't be there with `v -gc none hello_world.v`.

Reply on news.ycombinator.com