7 ms·

"No race conditions, leaking resources, dangling pointers, unhandled exceptions, ..., the list goes on." Except of dangling pointers, Rust has everything else

"No race conditions, leaking resources, dangling pointers, unhandled exceptions, ..., the list goes on." Except of dangling pointers, Rust has everything else from this list. About compilation time issue: it doesn't exist anymore. Current versions do "cargo check" in a few seconds even for big projects (my biggest project is 45k LoC) and it takes a couple of minutes to compile it because of incremental compilation. For libraries it takes seconds to compile and 1-2 seconds to run "cargo check" (or clippy).

Laaas 8y ago
It is indeed true that you can unintentionally leak resources, but it is still much harder. Also, what do you mean that it has unhandled exceptions and race conditions? Rust doesn't even have exceptions (although there are panics, which is not the same thing), and race conditions are statically prevented in safe code due to how a mutable reference works.
- EugeneOZ 8y ago
  Theoretically they are different, in practice they are the same (it's just more difficult to handle panicking - sometimes you can't use catch_unwind because of it's trait limitations). About race conditions: https://doc.rust-lang.org/nomicon/races.html https://doc.rust-lang.org/nomicon/races.html
  - setr 8y ago
    I feel like its quite difficult to call them the same in practice, when they serve very different roles: errors that are likely to be recoverable are not panics! in a sane rust api, whereas they very much are exceptions in sane C++. You recover from either in similar fashion, but panics! are intended to serve a much different role than exceptions (the common usage of exceptions in C++ being covered by Result<> in rust).
    - EugeneOZ 8y ago
      I hate when people use exceptions for regular errors, it triggers me hard. Please let's don't start this topic :)
      - speedplane 8y ago
        You started it.... exceptions are mostly annoying because they are so verbose. Writing try... catch... is a whole lot longer than "if func() == null".
        setr 8y ago
        Exceptions are mostly annoying because they’re infectious, and somewhat undocumented (they’ve not part of the api; if an upstream library adds a new exception, all downstream code must now handle it [or document it]), and if anyone misses the update, its a runtime error waiting to happen. But notably, your compiler won’t say a word about it (unless its java, in which case you’ll probably get too much :-). Return codes are similar, but less cascade-y. Try-catch being verbose and fucking up control flow is just an added bonus.
        speedplane 8y ago
        Which is easier: try: module.find_element() except: # handle not found else: # handle found Or this: if module.find_element(): # handle found else: # handle not found
- Sharlin 8y ago
  It's important to understand the difference between data races and race conditions. The former are a subset of the latter. Race conditions in general can happen even in single-threaded code. (Although admittedly Rust ownership semantics prevent many of the latter as well; for instance, modifying a collection while iterating over it is impossible, cf. Java `ConcurrentModificationException` which itself is thrown only on a best-effort basis.)
jerrre 8y ago
>big projects (my biggest project is 45k LoC) and it takes a couple of minutes to compile it I don't think 45k LoC could be considered big, and I _do_ think a couple minutes compile time is a problem. I say that as a C++ programmer, a full recompile will easily get me out of the zone
- EugeneOZ 8y ago
  Out of curiosity, not to argue: how much time it takes in C++ to compile 45k LoC?
  - adrianN 8y ago
    That really heavily depends on the kind of code. Template metaprogramming slows down the compiler a lot.
    - EugeneOZ 8y ago
      So sometimes it takes couple of seconds, sometimes couple of hours? Maybe there's some approximate range.
      - skrimp 8y ago
        C++ compile times heavily depend on the code that is being compiled and the build system that is compiling it. Code that doesn't touch STL or boost or do much metaprogramming of its own is going to compile extremely fast (especially when compiled in parallel). Code that pulls in half of boost isn't going to compile so quick without tweaking the build settings. Due to how variable compilation times are, I don't think the range you provided is that unreasonable. Build time is something that changes on a project to project basis.
  - danieldk 8y ago
    I have some projects of that size (ballpark), typically using some Boost (but not heavy on meta programming), Qt, and the likes. A fresh non-incremental compile usually takes less than a minute. I have Rust projects that are many times smaller but take much more time for a non-incremental build. Of course, a large difference is that a fresh Rust build (after a cargo clean) compiles all its dependent crates, whereas many C/C++ libraries are provided pre-compiled by whatever system you are compiling on.
pjmlp 8y ago
It surely does, my Gtkmm demo application I wrote several years for "The C/C++ Users Journal" still compiles faster than the Rust rewrite in Gtk-rs, when doing fresh build or after minor changes. Lack of binary library support on cargo, not having incremental compilation and linking does hurt.
- EugeneOZ 8y ago
  There is incremental compilation. And cargo doesn't recompile libraries every time. Not sure how you don't know it if you really use Rust.
  - EugeneOZ 8y ago
    yeah, downvote it when you have nothing to say, that's how to make a discussion. Facts: Incremental compilation from 1.24 stable: https://blog.rust-lang.org/2018/02/15/Rust-1.24.html https://blog.rust-lang.org/2018/02/15/Rust-1.24.html Cargo recompiles dependencies only after "cargo clean" or after Rust version update.
    - pjmlp 8y ago
      I didn't downvote you. Cargo surely recompiles common dependencies across crates, unless one uses the workspace trick and even then recompiles do happen. Just get Gtk-rs, get nightly and then trace the build log. I once even mailed Rust devs about it. Incremental compilation still isn't up to incremental compilation + incremental linking, which is why I explicitly mentioned both on my comment.
      - steveklabnik 8y ago
        To clarify two things you've said: 1. Hacker News won't let you downvote someone who replies to you, so it is literally impossible for you to have downvoted in this situation. 2. Both of you are correct, because you're talking about different things. Evgeniy means "You only need to compile your dependencies upon the first build", and you mean "if I use the same dependency in two projects, it will be compiled twice, once on the initial compile of both."

Laaas 8y ago

It is indeed true that you can unintentionally leak resources, but it is still much harder. Also, what do you mean that it has unhandled exceptions and race conditions? Rust doesn't even have exceptions (although there are panics, which is not the same thing), and race conditions are statically prevented in safe code due to how a mutable reference works.

EugeneOZ 8y ago
Theoretically they are different, in practice they are the same (it's just more difficult to handle panicking - sometimes you can't use catch_unwind because of it's trait limitations). About race conditions: https://doc.rust-lang.org/nomicon/races.html https://doc.rust-lang.org/nomicon/races.html
- setr 8y ago
  I feel like its quite difficult to call them the same in practice, when they serve very different roles: errors that are likely to be recoverable are not panics! in a sane rust api, whereas they very much are exceptions in sane C++. You recover from either in similar fashion, but panics! are intended to serve a much different role than exceptions (the common usage of exceptions in C++ being covered by Result<> in rust).
  - EugeneOZ 8y ago
    I hate when people use exceptions for regular errors, it triggers me hard. Please let's don't start this topic :)
    - speedplane 8y ago
      You started it.... exceptions are mostly annoying because they are so verbose. Writing try... catch... is a whole lot longer than "if func() == null".
      - setr 8y ago
        Exceptions are mostly annoying because they’re infectious, and somewhat undocumented (they’ve not part of the api; if an upstream library adds a new exception, all downstream code must now handle it [or document it]), and if anyone misses the update, its a runtime error waiting to happen. But notably, your compiler won’t say a word about it (unless its java, in which case you’ll probably get too much :-). Return codes are similar, but less cascade-y. Try-catch being verbose and fucking up control flow is just an added bonus.
        speedplane 8y ago
        Which is easier: try: module.find_element() except: # handle not found else: # handle found Or this: if module.find_element(): # handle found else: # handle not found
Sharlin 8y ago
It's important to understand the difference between data races and race conditions. The former are a subset of the latter. Race conditions in general can happen even in single-threaded code. (Although admittedly Rust ownership semantics prevent many of the latter as well; for instance, modifying a collection while iterating over it is impossible, cf. Java `ConcurrentModificationException` which itself is thrown only on a best-effort basis.)

jerrre 8y ago

>big projects (my biggest project is 45k LoC) and it takes a couple of minutes to compile it I don't think 45k LoC could be considered big, and I _do_ think a couple minutes compile time is a problem. I say that as a C++ programmer, a full recompile will easily get me out of the zone

EugeneOZ 8y ago
Out of curiosity, not to argue: how much time it takes in C++ to compile 45k LoC?
- adrianN 8y ago
  That really heavily depends on the kind of code. Template metaprogramming slows down the compiler a lot.
  - EugeneOZ 8y ago
    So sometimes it takes couple of seconds, sometimes couple of hours? Maybe there's some approximate range.
    - skrimp 8y ago
      C++ compile times heavily depend on the code that is being compiled and the build system that is compiling it. Code that doesn't touch STL or boost or do much metaprogramming of its own is going to compile extremely fast (especially when compiled in parallel). Code that pulls in half of boost isn't going to compile so quick without tweaking the build settings. Due to how variable compilation times are, I don't think the range you provided is that unreasonable. Build time is something that changes on a project to project basis.
- danieldk 8y ago
  I have some projects of that size (ballpark), typically using some Boost (but not heavy on meta programming), Qt, and the likes. A fresh non-incremental compile usually takes less than a minute. I have Rust projects that are many times smaller but take much more time for a non-incremental build. Of course, a large difference is that a fresh Rust build (after a cargo clean) compiles all its dependent crates, whereas many C/C++ libraries are provided pre-compiled by whatever system you are compiling on.

pjmlp 8y ago

It surely does, my Gtkmm demo application I wrote several years for "The C/C++ Users Journal" still compiles faster than the Rust rewrite in Gtk-rs, when doing fresh build or after minor changes. Lack of binary library support on cargo, not having incremental compilation and linking does hurt.

EugeneOZ 8y ago
There is incremental compilation. And cargo doesn't recompile libraries every time. Not sure how you don't know it if you really use Rust.
- EugeneOZ 8y ago
  yeah, downvote it when you have nothing to say, that's how to make a discussion. Facts: Incremental compilation from 1.24 stable: https://blog.rust-lang.org/2018/02/15/Rust-1.24.html https://blog.rust-lang.org/2018/02/15/Rust-1.24.html Cargo recompiles dependencies only after "cargo clean" or after Rust version update.
  - pjmlp 8y ago
    I didn't downvote you. Cargo surely recompiles common dependencies across crates, unless one uses the workspace trick and even then recompiles do happen. Just get Gtk-rs, get nightly and then trace the build log. I once even mailed Rust devs about it. Incremental compilation still isn't up to incremental compilation + incremental linking, which is why I explicitly mentioned both on my comment.
    - steveklabnik 8y ago
      To clarify two things you've said: 1. Hacker News won't let you downvote someone who replies to you, so it is literally impossible for you to have downvoted in this situation. 2. Both of you are correct, because you're talking about different things. Evgeniy means "You only need to compile your dependencies upon the first build", and you mean "if I use the same dependency in two projects, it will be compiled twice, once on the initial compile of both."