To me, the biggest improvement Rust brings to the table is its sane defaults. This, coupled with its type system, makes handling outcomes something you opt out of.
As I continue to use of Rust, I keep finding myself avoiding `if` statements in favor of the `match` statement for this reason alone.
You must be mistaken, because the Dining Philosophers example only dates back to May 2015. A quick glance at the chapter reveals nothing that leaks, and the program itself is Valgrind-clean except for a single allocation from dlopen in the thread internals. Can you be more specific? Where did you hear this information?
There are 32 bytes leaked out of some internal runtime code, but they are allocated once globally, not "whenever a thread closes".
The code that generated the allocation that leaked in that issue (std::io::with_task_stdout) no longer exists, and I believe the thread local storage system has been rewritten since then as well. Could you clarify how that issue is relevant to modern Rust?
I'm following up on this since the person you were writing in response to has deleted their comments.
Alex Crichton, one of Rust's top contributors, confirmed that the problem is still present a day ago. He acknowledged this on one of the very issues the original comment was in reference to.
alexcrichton commented a day ago
@huonw did you test on linux? You may have been using the ELF TLS instead of pthread tls. I just built a compiler with --disable-elf-tls and it looks like the leak is still present:
$ valgrind ./foo
==21255== Memcheck, a memory error detector
==21255== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al.
==21255== Using Valgrind-3.10.0.SVN and LibVEX; rerun with -h for copyright info
==21255== Command: ./foo
==21255==
Hello World!
How are you today
==21255==
==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
==21255== suppressed: 0 bytes in 0 blocks
==21255== Rerun with --leak-check=full to see details of leaked memory
==21255==
==21255== For counts of detected and suppressed errors, rerun with: -v
==21255== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
It's exceptionally too bad the person who originally pointed this out in the comments here felt the need to delete their comment.
I'm getting mixed signals. In the comment elsewhere you say the original poster linked #14875, but here you refer to #19776. It's also the case that #19776 isn't even a problem, because using "leak" here is a misnomer. The "still reachable" section doesn't indicate memory that was leaked, but memory that could have been freed but that nobody bothered to. And the reason that this isn't a problem is because failing to explicitly free memory during process exit doesn't matter because the act of exiting will free that memory by definition. There's no leak here; the only reason that issue exists is because it makes the valgrind output slightly annoying when run with certain settings. It's a tooling issue, not a language issue.
I experienced this problem too. It didn't seem to exist on ubuntu or fedora, which were the two OS distributions I was developing for. Windows and Mac were the only platforms displaying the issue when I'd tested it.
Come on everyone, this is HN -- let's not pick apart valid concerns people express that they have experienced personally, especially when those concerns are acknowledged as an existing issue by the repository's main contributors in the linked issue...
Being rude is not supportive of an open dialogue and comments intended to efface the author of the original comment from the conversation are just despicable. When you alienate someone, they leave, and that's exactly what happened here. Hopefully whoever that was didn't just up and delete their HN account.
I don’t see what should’ve been considered rude behaviour here regarding the mentioned individual. The only critical reactions I see are twofold. First, there is the critique for missing sources for his claims. Second, the factual claim is refuted by experiment, for at least some environments. Both objections are valid.
I’m afraid, too, that said individual is feeling bad for the reaction HN gave him, but I think he shouldn’t! If you were wrong, be happy for having learnt something. If anybody thinks less about you for it, they are jerks.
Yeah, my remarks now lack their context with the deletions/edits. I haven't checked hacker news since I edited by own reply, but I can only imagine they were edited by the time you saw them, given the time stamps.
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).
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.
> 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).
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.
You might have a strange set-up or a misconception. The issue you link to doesn't reproduce for me, and there's certainly not a proliferation of memory leaks in the book. The dining philosophers example definitely runs destructors and frees memory.
A practitioner oughtn't hit this at all, since the cited chapter contains no leaks. It's actually quite difficult to leak memory accidentally in Rust, short of using the `std::mem::forget` function whose sole purpose is to deliberately leak memory (which can be useful for C interop).
As I continue to use of Rust, I keep finding myself avoiding `if` statements in favor of the `match` statement for this reason alone.