[kibwen]

I didn't get to see which issue was linked before the original poster deleted their comments, but in the original comment they mentioned the Dining Philosophers chapter from the book which cannot exhibit the leak from that issue because it doesn't define any destructors (let alone define any potentially-panicking destructors, let alone attempt to catch any panics, all of which would be required to observe such a leak).

[rjshayes]

I was aware of the entire conversation here, sadly.

" the Dining Philosophers chapter from the book which cannot exhibit the leak from that issue because it doesn't define any destructors (let alone define any potentially-panicking destructors, let alone attempt to catch any panics, all of which would be required to observe such a leak)."

Since when can memory leaks only be observed from within the language itself? There are a number of tools that are used on a regular basis to observe memory leaks, with many of them being entirely language agnostic. Additionally, the entire issue brought up in the deleted comment was in relation to threads, an argument of a lack of user-defined destructors wasn't brought into question at all.

    use std::thread;
    use std::sync::{Mutex, Arc};

Glancing briefly over the section of the Rust book in question here, the above two lines appear in the code. In any language, whenever memory is used and then not freed there is a leak. A leak may have nothing to do with a destructor in a language, but could relate to code generation, etc..

As I linked to the other commentator who was assured the individual in question (whose comment is now deleted) was incorrect, Alex Crichton (one of Rust's main contributors) posted a valgrind example yesterday on one of the issues that individual linked (https://github.com/rust-lang/rust/issues/19776).

    ==21255== HEAP SUMMARY:
    ==21255==     in use at exit: 312 bytes in 7 blocks
    ==21255==   total heap usage: 26 allocs, 19 frees, 2,720 bytes allocated
    ==21255== 
    ==21255== LEAK SUMMARY:
    ==21255==    definitely lost: 0 bytes in 0 blocks
    ==21255==    indirectly lost: 0 bytes in 0 blocks
    ==21255==      possibly lost: 0 bytes in 0 blocks
    ==21255==    still reachable: 312 bytes in 7 blocks

The original comment mentioning this issue was lacking so in confrontational qualities that the responses he or she received here and on twitter (how I myself arrived here) were entirely unwarranted.

[kibwen]

  > Since when can memory leaks only be observed from within 
  > the language itself?

The issue you linked has to do with leaking local variables during a panic, and if uncaught a panic will bring down the entire process. I don't see how you could observe such a leak.

  > Additionally, the entire issue brought up in the 
  > deleted comment was in relation to threads, an argument 
  > of a lack of user-defined destructors wasn't brought 
  > into question at all.

As party to the original comment, it didn't bring up threads at all. Nor does the issue you linked above, #14875, relate to threads at all. To paraphrase what I remember of the original comment, it was "I stopped using Rust when I got to the Dining Philosophers chapter of the book and found that it taught newcomers to leak memory like crazy, via a bug that has gone unfixed since 2014." It contained no mention of which bug that was nor where the leaks were, hence the numerous follow-up comments asking for clarification.

  >  The original comment mentioning this issue was lacking 
  > so in confrontational qualities that the responses he 
  > or she received here and on twitter (how I myself 
  > arrived here) were entirely unwarranted.

I can only guess that the original poster edited their comment between the time that you and I read the post, because the original version was quite confrontational. What responses do you believe are unwarranted? All the ones here seem courteous, and I haven't seen any on Twitter (I would appreciate it if you could link me to these).

[gtani]

the ticket was filed mid-Dec. 2014 and stated that all threads leaked memory when closed. I think there was an earnest misunderstanding, since the ticket was still open when i read it, but has clearly been fixed on linux/OS X.

And i couldn't find the ticket when i looked, after the user deleted his comments. So it seemed a bit like a direct attack on the language's fitness for developemnt, but also like a misunderstanding.