5 ms·

The main problem I see with this reasoning: The author provides some "extreme" examples of bad ergonomics, and posits there are milder examples of similarly ba

The main problem I see with this reasoning: The author provides some "extreme" examples of bad ergonomics, and posits there are milder examples of similarly bad ergonomics. But their examples aren't on the scale of "ergonomics", they're on the scale of "weakening language guarantees". Instead of writing an essay with (intentional) strawman examples and then saying "trust me this could happen with any new ergonomics" is much less persuasive than just bringing up any legitimate concerns on offending ergonomic features. This essay is kind of arguing against no one and everyone at the same time: No one disagrees that automatic unwrapping is a bad idea, but it's ridiculous to say that "I reach more ergonomics by accepting more programs and hoping they do what the author have meant, so I don’t have to bother the author with a compilation error." This isn't arguing against ergonomics, it's arguing against. . . I don't know, making Rust not Rust anymore?

foldr 9y ago
I don't see anything wrong with automatic unwrap in principle. It's not really much different from how Rust handles array indexing (where you don't have to explicitly handle the case where the array lacks an element at the given index).
- gamegoblin 9y ago
  Rust provides two methods for array indexing. `my_array[i]` which panics if `i` is out of bounds, and `my_array.get(i)` which returns `None` if `i` is out of bounds. The same thing applies to `HashMap` etc. For the vast majority of cases, it is an non-recoverable logic error to try to access an out-of-bounds elements, so panicking makes sense for the more common, more terse `my_array[i]` syntax. For me, recoverability dictates whether or not to return `Option<T>` or `T-but-maybe-panic`. If a caller can reasonably recover (and in fact expects to get `None` some of the time!), then `Option<T>` is the right choice. If it is obviously an irrecoverable logic error, then maybe panicking is the right choice.
  - foldr 9y ago
    Yes, I'm aware of how Rust handles array indexing. I was just noting that autounwrapping wouldn't be any less safe than the existing behavior for array indexing using [].
ChrisSD 9y ago
I think a more charitable read is that Vorner is urging caution. Ergonomic changes are the "most prominent language work in the pipeline"[0] and there does seem to be a general consensus that Rust is harder to learn and should be made easier. The argument is that Rust should keep its priorities straight and not be seduced by ease of use to the detriment of the language's advantages. But I agree that the danger remains hypothetical unless we can point to some dubious proposals that are gaining traction. [0] https://blog.rust-lang.org/2018/03/12/roadmap.html#language-improvements https://blog.rust-lang.org/2018/03/12/roadmap.html#language-...
- hyperpape 9y ago
  I agree with your priorities, but I want to stress that don't think there's any reason to believe the people working on the language are confused about this. The ergonomics initiative has explicitly been about making certain things easier without introducing ambiguity or jeopardizing the safety guarantees Rust offers. Like the OP says, the article is misguided, and if it has any effect, it will create FUD in people who have not followed the ergonomics proposals enough to know better.
  - phaylon 9y ago
    I was part of a couple ergonomics discussions and I disagree. Yes, in the end the changes don't sacrifice long-term maintainability over learnability/marketing, but that was a hard fight. And given editions will allow radical changes to the language and ecosystem every 3 years, I'm not sure how long that resistance is sustainable.
    - hyperpape 9y ago
      Interesting. I guess you’re closer to the action than I am. I didn’t participate, but liked the proposals I read (I think I saw a lot of them by way of core contributors. Would you mind sharing some of the proposals you thought were dangerous and whether you felt like they were close to being adopted?

foldr 9y ago

I don't see anything wrong with automatic unwrap in principle. It's not really much different from how Rust handles array indexing (where you don't have to explicitly handle the case where the array lacks an element at the given index).

gamegoblin 9y ago
Rust provides two methods for array indexing. `my_array[i]` which panics if `i` is out of bounds, and `my_array.get(i)` which returns `None` if `i` is out of bounds. The same thing applies to `HashMap` etc. For the vast majority of cases, it is an non-recoverable logic error to try to access an out-of-bounds elements, so panicking makes sense for the more common, more terse `my_array[i]` syntax. For me, recoverability dictates whether or not to return `Option<T>` or `T-but-maybe-panic`. If a caller can reasonably recover (and in fact expects to get `None` some of the time!), then `Option<T>` is the right choice. If it is obviously an irrecoverable logic error, then maybe panicking is the right choice.
- foldr 9y ago
  Yes, I'm aware of how Rust handles array indexing. I was just noting that autounwrapping wouldn't be any less safe than the existing behavior for array indexing using [].

ChrisSD 9y ago

I think a more charitable read is that Vorner is urging caution. Ergonomic changes are the "most prominent language work in the pipeline"[0] and there does seem to be a general consensus that Rust is harder to learn and should be made easier. The argument is that Rust should keep its priorities straight and not be seduced by ease of use to the detriment of the language's advantages. But I agree that the danger remains hypothetical unless we can point to some dubious proposals that are gaining traction. [0] https://blog.rust-lang.org/2018/03/12/roadmap.html#language-improvements https://blog.rust-lang.org/2018/03/12/roadmap.html#language-...

hyperpape 9y ago
I agree with your priorities, but I want to stress that don't think there's any reason to believe the people working on the language are confused about this. The ergonomics initiative has explicitly been about making certain things easier without introducing ambiguity or jeopardizing the safety guarantees Rust offers. Like the OP says, the article is misguided, and if it has any effect, it will create FUD in people who have not followed the ergonomics proposals enough to know better.
- phaylon 9y ago
  I was part of a couple ergonomics discussions and I disagree. Yes, in the end the changes don't sacrifice long-term maintainability over learnability/marketing, but that was a hard fight. And given editions will allow radical changes to the language and ecosystem every 3 years, I'm not sure how long that resistance is sustainable.
  - hyperpape 9y ago
    Interesting. I guess you’re closer to the action than I am. I didn’t participate, but liked the proposals I read (I think I saw a lot of them by way of core contributors. Would you mind sharing some of the proposals you thought were dangerous and whether you felt like they were close to being adopted?