3 ms·

Rust's borrow checker does not have a lot of mental overhead while working once you are moderately proficient. It imposes design constraints that in the end wo

• foldr 8y ago
  This is only true in cases where a single ownership model makes sense. In cases where it doesn't, there is a definite overhead. I think even the strongest Rust advocates would not deny the existence of this overhead. They'd just point out that you'd have the same overhead in C++, but without the compiler helpfully telling you when you've made a mistake. I'd also add that there are (small) warts on Rust's current implementation of borrow checking which everyone agrees are minor annoyances, even to experienced users: https://github.com/rust-lang/rust/issues/43234 https://github.com/rust-lang/rust/issues/43234 Judging by that issue thread, some of these issues are about to be fixed.
• jeremycw 8y ago
  > It imposes design constraints that in the end work out for the better. I feel the jury is still out on this. It does impose design constraints that remove a certain subclass of errors, whether this correlates to actually causing better designed programs in the sense of readability, maintainability, etc. I'm unsure. I understand the desire for this to be true and I feel that some of the fanaticism around the language is the belief that this is true. Developers like to have the 'one true way' to solve problems. Go's popularity I feel is in part because of this as well but achieved it by having a bare bones language with less options instead of a restrictive compiler. If you take the 'restrictive compiler' argument to its logical conclusion for a program that accepts input x and produces output y there would only be one valid way to code this program. This would be good in the sense that presumably the compiler has proven that your program works and is correct. On the other hand though I have no inclination to believe that this program would be the most understandable, modifiable way to get from x -> y.
  • sephware 8y ago
    Also, there are many classes of errors that Rust doesn't help solve, but which people seem to get the impression that it does aim to solve, which can be confusing and counterproductive when choosing a language because of the classes of errors it aims to solve (often a big motivator in both designing and choosing a language; see Swift and Go).
    • vram22 8y ago
      >Also, there are many classes of errors that Rust doesn't help solve, but which people seem to get the impression that it does aim to solve What are some of those?
      • steveklabnik 8y ago
        The big one is memory leaks. People also assume “race conditions” instead of “data races.”
        • vram22 8y ago
          Thanks for the info. I need to look up the latter point, the difference between the two. Saw it mentioned in an article or book about Go too. Looked it up, found these links, for anyone interested: https://blog.regehr.org/archives/490 https://blog.regehr.org/archives/490 https://stackoverflow.com/questions/11276259/are-data-races-and-race-condition-actually-the-same-thing-in-context-of-conc https://stackoverflow.com/questions/11276259/are-data-races-...
          • steveklabnik 8y ago
            Any time! And yeah, those links are excellent.
            • vram22 8y ago
              Cool, good to know :)