4 ms·

Thanks, yeah, I was very careful to avoid claiming they're mutually exclusive. However, although I stopped trying to learn Rust back in 2016, unless it's change

Thanks, yeah, I was very careful to avoid claiming they're mutually exclusive. However, although I stopped trying to learn Rust back in 2016, unless it's changed its fundamentals radically (which I understand it hasn't), I'm not sure if it's really a counterexample here for expressiveness. Can you use different allocators for different vectors in the same function in Rust? Can you have custom move semantics for objects that might know about pointers to them? And does the compiler no longer complain about code that really should work just fine? [1] I understand the answers to most if not all such questions is still "no", at which point I stop believing it really has the same flexibility as C++ or the same ease of writing as Python, but would be happy to hear if things have changed. [1] http://softwaremaniacs.org/blog/2016/02/12/ownership-borrowing-hard/en/ http://softwaremaniacs.org/blog/2016/02/12/ownership-borrowi...

couchand 8y ago
> And does the compiler no longer complain about code that really should work just fine? In the general case that's theoretically impossible, and also not really a good measure anyway.
- mehrdadn 8y ago
  Okay, how about in the practical cases that actually come up and make you have to work around the compiler?
  - Sharlin 8y ago
    Non-lexical lifetimes, which were just recently stabilized [1], make many of the most common cases of borrow checker frustration "just work". And now that the groundwork is done, even more cases will likely be supported in the future. [1] https://rust-lang-nursery.github.io/edition-guide/rust-2018/ownership-and-lifetimes/non-lexical-lifetimes.html https://rust-lang-nursery.github.io/edition-guide/rust-2018/...
    - mehrdadn 8y ago
      Confused, how are these common use cases, and how is this "just working"? In both examples on that page there is an unused variable (seems rare to do intentionally?) and in the second case where one of them is used, it seems they just elaborated the error message.
      - staticassertion 8y ago
        A common use case might be something along these lines: https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=7929c7ee98bf530888173d51a71f96a1 https://play.rust-lang.org/?version=stable&mode=debug&editio... While the `entry` API provided an ergonomic, more performant way to do this, this is an example of a common pattern one might expect from other languages that, until recently, did not compile. NLL and other ergonomics improvements have helped a lot with these paper-cuts.
        chrismorgan 8y ago
        Incidentally: for what that whole `match` block could be with the entry API: *example_map.entry("some_key").or_insert(0) += 1; Or, if you prefer an extra intermediate for clarity: let entry = example_map.entry("some_key").or_insert(0); *entry += 1; This is a good example of how, often, Rust’s approach of having greater underlying complexity but exposing it sanely ends up allowing you to write something that is semantically superior and easier to reason about, while being faster too. This and Rust’s ownership model (which I declare stands under the same banner) is the sort of thing that I regularly miss when working in JavaScript (and regularly missed when I used to work in Python plenty).
Sharlin 8y ago
In general, Rust will probably never be the sort of Swiss Army chainsaw that C++ is, and that is by design. For instance, there will most likely never be custom move semantics; the fact that Rust moves are always simple bitwise copies is a feature. But we're probably talking about different types of expressiveness—what I had in mind was modern type system features such as algebraic data types and pattern matching, monadic/combinator-based vocabulary types such as Option, Result, and Iterator, trait-based polymorphism and so on. C++ is slowly getting many of these as well, but often the corresponding features feel clunky and "design-by-committee"-ish.
zozbot123 8y ago
> objects that might know about pointers to them The Pin<> type constructor is being standardized to support this case. This is not so much "custom move semantics" as a lack of in-built "move" semantics of any sorts, but the basic use case is being worked on. > And does the compiler no longer complain about code that really should work just fine? As other people have mentioned, the NLL feature addresses many cases where this used to be a problem, and has now been introduced to the 'stable' version.

couchand 8y ago

> And does the compiler no longer complain about code that really should work just fine? In the general case that's theoretically impossible, and also not really a good measure anyway.

mehrdadn 8y ago
Okay, how about in the practical cases that actually come up and make you have to work around the compiler?
- Sharlin 8y ago
  Non-lexical lifetimes, which were just recently stabilized [1], make many of the most common cases of borrow checker frustration "just work". And now that the groundwork is done, even more cases will likely be supported in the future. [1] https://rust-lang-nursery.github.io/edition-guide/rust-2018/ownership-and-lifetimes/non-lexical-lifetimes.html https://rust-lang-nursery.github.io/edition-guide/rust-2018/...
  - mehrdadn 8y ago
    Confused, how are these common use cases, and how is this "just working"? In both examples on that page there is an unused variable (seems rare to do intentionally?) and in the second case where one of them is used, it seems they just elaborated the error message.
    - staticassertion 8y ago
      A common use case might be something along these lines: https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=7929c7ee98bf530888173d51a71f96a1 https://play.rust-lang.org/?version=stable&mode=debug&editio... While the `entry` API provided an ergonomic, more performant way to do this, this is an example of a common pattern one might expect from other languages that, until recently, did not compile. NLL and other ergonomics improvements have helped a lot with these paper-cuts.
      - chrismorgan 8y ago
        Incidentally: for what that whole `match` block could be with the entry API: *example_map.entry("some_key").or_insert(0) += 1; Or, if you prefer an extra intermediate for clarity: let entry = example_map.entry("some_key").or_insert(0); *entry += 1; This is a good example of how, often, Rust’s approach of having greater underlying complexity but exposing it sanely ends up allowing you to write something that is semantically superior and easier to reason about, while being faster too. This and Rust’s ownership model (which I declare stands under the same banner) is the sort of thing that I regularly miss when working in JavaScript (and regularly missed when I used to work in Python plenty).

Sharlin 8y ago

In general, Rust will probably never be the sort of Swiss Army chainsaw that C++ is, and that is by design. For instance, there will most likely never be custom move semantics; the fact that Rust moves are always simple bitwise copies is a feature. But we're probably talking about different types of expressiveness—what I had in mind was modern type system features such as algebraic data types and pattern matching, monadic/combinator-based vocabulary types such as Option, Result, and Iterator, trait-based polymorphism and so on. C++ is slowly getting many of these as well, but often the corresponding features feel clunky and "design-by-committee"-ish.

zozbot123 8y ago

> objects that might know about pointers to them The Pin<> type constructor is being standardized to support this case. This is not so much "custom move semantics" as a lack of in-built "move" semantics of any sorts, but the basic use case is being worked on. > And does the compiler no longer complain about code that really should work just fine? As other people have mentioned, the NLL feature addresses many cases where this used to be a problem, and has now been introduced to the 'stable' version.