4 ms·

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

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 8y 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?
- phaylon 8y ago
  I made a bit of a list of the big ones here: https://news.ycombinator.com/item?id=16837894 https://news.ycombinator.com/item?id=16837894 The interesting (and to me frustrating) part is that often good improvements (or intentions to solve actual problems) come together with far-reaching changes in an all-or-nothing kind of way. Some examples: * I'm still of the opinion that moving `&mut T` to `&uniq T` pre-1.0 failed because it also proposed getting rid of `mut` alltogether and be mutable by default. * Everything that relates to errors often also tends to accumulate a push to make things look more like exceptions. That applies to `?` short-ciruiting, the current discussion about limiting the scope of that short-circuiting, and anytime auto-converting final-value result types comes up. (and it currently looks like that short-circuit construct will auto convert its final value when it arrives). * Making paths saner and modules and visibility more intuitive first started out proposing completely removing the option of being explicit about project structure, and it took multiple rounds of RFCs to keep that control. * The match ergonomics discussions hinted at a wish by some to get rid of `ref` and `ref mut` patterns which is what allows destructuring a mutable reference into mutable and immutable bindings.
kibwen 8y ago
> And given editions will allow radical changes to the language and ecosystem every 3 years This is incorrect. Editions are incredibly limited in what they can introduce (it needs to be something that it is possible for the compiler to warn for, with no false positives or false negatives). In practice this means that they're mostly limited to introducing new keywords and other little bits of trivial syntax.
- phaylon 8y ago
  I'd consider that a misconception. Everything that can be deprecated can be removed and replaced by a new edition. See the discussion here: https://www.reddit.com/r/rust/comments/82sxxf/epoch_vs_era_rust_internals/dvdkipc/ https://www.reddit.com/r/rust/comments/82sxxf/epoch_vs_era_r... An example would be the talk about removing the ability to declare reference bindings with `ref` and `ref mut` and always inherit whatever the source mode was. Edit: There is also talk about changing the prelude, so I would assume the standard library is also fair game.
  - kibwen 8y ago
    It's not a misconception, there are plenty of times in the past year that I've heard someone propose some change for the new edition only for the Rust devs to meet it with "that's not possible because we can't infallibly warn for it in the compiler, so there's no point discussing it". Furthermore, just because we can imagine things that could be broken, it doesn't mean that the Rust developers interpret that as carte blanche to break things. The history of Rust development since 1.0 has been one of careful, gradual, and conservative change. It appears that you have a lot of fear about various things that you imagine might be changed (such as ref and ref mut in patterns, which is sort of head-scratching because I've never heard anyone propose removing them, and it wouldn't make sense to remove them anyway), but I think such fears are unwarranted. I've been observing the Rust developers at work longer than almost anyone, and I've ended up with a degree of trust in their sense of taste that rivals that of any other project that I've seen. The people behind the language today are the same ones who have been behind the language for years now, so if you happen to like where their influence has led the project so far, I think it's reasonable to trust that they won't abruptly leap off the rails. :)
derefr 8y ago
It seems to be that this is one of those fights where I (as a Rust developer) would prefer that both sides fight as hard as possible. An article like this, by suggesting that the "ergonomists" move more toward the mindset of the "safety people", could cause undue wins of the "safety people" over the ergonomists, when what should have happened is a careful compromise.
- didibus 8y ago
  Can you really compromise on safety guarantees? Isn't doing so just a rewrite of C++ ?
- phaylon 8y ago
  Personally I wish it wouldn't have to be a fight, but Github issues are not well suited for large scale design discussions and are bound to produce certain amounts of grief.

hyperpape 8y 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?

phaylon 8y ago
I made a bit of a list of the big ones here: https://news.ycombinator.com/item?id=16837894 https://news.ycombinator.com/item?id=16837894 The interesting (and to me frustrating) part is that often good improvements (or intentions to solve actual problems) come together with far-reaching changes in an all-or-nothing kind of way. Some examples: * I'm still of the opinion that moving `&mut T` to `&uniq T` pre-1.0 failed because it also proposed getting rid of `mut` alltogether and be mutable by default. * Everything that relates to errors often also tends to accumulate a push to make things look more like exceptions. That applies to `?` short-ciruiting, the current discussion about limiting the scope of that short-circuiting, and anytime auto-converting final-value result types comes up. (and it currently looks like that short-circuit construct will auto convert its final value when it arrives). * Making paths saner and modules and visibility more intuitive first started out proposing completely removing the option of being explicit about project structure, and it took multiple rounds of RFCs to keep that control. * The match ergonomics discussions hinted at a wish by some to get rid of `ref` and `ref mut` patterns which is what allows destructuring a mutable reference into mutable and immutable bindings.

kibwen 8y ago

> And given editions will allow radical changes to the language and ecosystem every 3 years This is incorrect. Editions are incredibly limited in what they can introduce (it needs to be something that it is possible for the compiler to warn for, with no false positives or false negatives). In practice this means that they're mostly limited to introducing new keywords and other little bits of trivial syntax.

phaylon 8y ago
I'd consider that a misconception. Everything that can be deprecated can be removed and replaced by a new edition. See the discussion here: https://www.reddit.com/r/rust/comments/82sxxf/epoch_vs_era_rust_internals/dvdkipc/ https://www.reddit.com/r/rust/comments/82sxxf/epoch_vs_era_r... An example would be the talk about removing the ability to declare reference bindings with `ref` and `ref mut` and always inherit whatever the source mode was. Edit: There is also talk about changing the prelude, so I would assume the standard library is also fair game.
- kibwen 8y ago
  It's not a misconception, there are plenty of times in the past year that I've heard someone propose some change for the new edition only for the Rust devs to meet it with "that's not possible because we can't infallibly warn for it in the compiler, so there's no point discussing it". Furthermore, just because we can imagine things that could be broken, it doesn't mean that the Rust developers interpret that as carte blanche to break things. The history of Rust development since 1.0 has been one of careful, gradual, and conservative change. It appears that you have a lot of fear about various things that you imagine might be changed (such as ref and ref mut in patterns, which is sort of head-scratching because I've never heard anyone propose removing them, and it wouldn't make sense to remove them anyway), but I think such fears are unwarranted. I've been observing the Rust developers at work longer than almost anyone, and I've ended up with a degree of trust in their sense of taste that rivals that of any other project that I've seen. The people behind the language today are the same ones who have been behind the language for years now, so if you happen to like where their influence has led the project so far, I think it's reasonable to trust that they won't abruptly leap off the rails. :)

derefr 8y ago

It seems to be that this is one of those fights where I (as a Rust developer) would prefer that both sides fight as hard as possible. An article like this, by suggesting that the "ergonomists" move more toward the mindset of the "safety people", could cause undue wins of the "safety people" over the ergonomists, when what should have happened is a careful compromise.

didibus 8y ago
Can you really compromise on safety guarantees? Isn't doing so just a rewrite of C++ ?
phaylon 8y ago
Personally I wish it wouldn't have to be a fight, but Github issues are not well suited for large scale design discussions and are bound to produce certain amounts of grief.