5 ms·

Five lists of six things about Rust

44 points by mmphosis 11y ago

jumperjake 11y ago
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.
- hermanradtke 11y ago
  And then you start pipelining all the match statements... Rust almost starts to look functional.
cpeterso 11y ago
> Six ways Rust is fundamentally different from how it started > ... > 3. LLVM: strengths (amazing optimization) and weaknesses (narrow semantics) Did Rust originally use a custom code generator instead of LLVM?
- pcwalton 11y ago
  Sure did. I think it's still in the git history, boot/back/ or something.
deleted 11y ago
[deleted]
- taeric 11y ago
  Is this more of a niche complaint, or something that will hit a practitioner pretty quickly?
  - kibwen 11y ago
    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).
- evmar 11y ago
  In case anyone else is wondering, the referenced chapter is https://doc.rust-lang.org/book/dining-philosophers.html https://doc.rust-lang.org/book/dining-philosophers.html I don't have enough Rust experience to see the issue. I searched the bug tracker to try to find the mentioned bug but couldn't.
- Aatch 11y ago
  It would be nice if you linked to the issue. I've been involved with the language since before then and haven't heard of this particular issue.
  - deleted 11y ago
    [deleted]
    - rjshayes 11y ago
      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. EDIT: Awh, that's sad... s/he deleted the comment.... The issue the individual linked was https://github.com/rust-lang/rust/issues/14875 https://github.com/rust-lang/rust/issues/14875, an open issue the contributors acknowledged as existing since June 13, 2014. 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.
      - madez 11y ago
        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.
        rjshayes 11y ago
- kibwen 11y ago
  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?
  - deleted 11y ago
    [deleted]
    - deleted 11y ago
      [deleted]
    - sfackler 11y ago
      I ran that code through Valgrind on x86_64 Linux and am finding that the leaks described in that issue no longer exist: https://gist.github.com/sfackler/1f7d4dc0c171be6b6b54 https://gist.github.com/sfackler/1f7d4dc0c171be6b6b54. 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?
      - rjshayes 11y ago
        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. See https://github.com/rust-lang/rust/issues/19776 https://github.com/rust-lang/rust/issues/19776 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.
- deleted 11y ago
  [deleted]
- dbaupp 11y ago
  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.
StefanKarpinski 11y ago
I know this doesn't add much, but I love everything Graydon Hoare writes, especially about programming languages.

44 points by mmphosis 11y ago

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.

hermanradtke 11y ago
And then you start pipelining all the match statements... Rust almost starts to look functional.

cpeterso 11y ago

> Six ways Rust is fundamentally different from how it started > ... > 3. LLVM: strengths (amazing optimization) and weaknesses (narrow semantics) Did Rust originally use a custom code generator instead of LLVM?

pcwalton 11y ago
Sure did. I think it's still in the git history, boot/back/ or something.

deleted 11y ago

[deleted]

taeric 11y ago
Is this more of a niche complaint, or something that will hit a practitioner pretty quickly?
- kibwen 11y ago
  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).
evmar 11y ago
In case anyone else is wondering, the referenced chapter is https://doc.rust-lang.org/book/dining-philosophers.html https://doc.rust-lang.org/book/dining-philosophers.html I don't have enough Rust experience to see the issue. I searched the bug tracker to try to find the mentioned bug but couldn't.
Aatch 11y ago
It would be nice if you linked to the issue. I've been involved with the language since before then and haven't heard of this particular issue.
- deleted 11y ago
  [deleted]
  - rjshayes 11y ago
    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. EDIT: Awh, that's sad... s/he deleted the comment.... The issue the individual linked was https://github.com/rust-lang/rust/issues/14875 https://github.com/rust-lang/rust/issues/14875, an open issue the contributors acknowledged as existing since June 13, 2014. 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.
    - madez 11y ago
      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.
      - rjshayes 11y ago
kibwen 11y ago
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?
- deleted 11y ago
  [deleted]
  - deleted 11y ago
    [deleted]
  - sfackler 11y ago
    I ran that code through Valgrind on x86_64 Linux and am finding that the leaks described in that issue no longer exist: https://gist.github.com/sfackler/1f7d4dc0c171be6b6b54 https://gist.github.com/sfackler/1f7d4dc0c171be6b6b54. 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?
    - rjshayes 11y ago
      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. See https://github.com/rust-lang/rust/issues/19776 https://github.com/rust-lang/rust/issues/19776 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.
deleted 11y ago
[deleted]
dbaupp 11y ago
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.

StefanKarpinski 11y ago

I know this doesn't add much, but I love everything Graydon Hoare writes, especially about programming languages.