5 ms·

Range's idiosyncrasies and the antipathy to improving its ergonomics manifest in the issues raised against the project have been a capstone mental block to my

Range's idiosyncrasies and the antipathy to improving its ergonomics manifest in the issues raised against the project have been a capstone mental block to my investing emotionally in Rust. I continuously really want to like the language. The premise is good, a lot of the ideas are really compelling, but when it comes down to aspects I disagree with, I get a strong sense of Rust demanding that users subjugate themselves to all the choices and opinions of the architects, and is (are?) hostile to the notion of a user expressing themselves through their tools, and not just their output. As a result, every time I interact with Rust my hackles end up getting raised and so far it would seem that a (currently absent) existential motivator would be required for me to get past it.

Ygg2 6y ago
Sure. But to solve those idiosyncrasies, you need to abandon backwards compatibility or introduce conflicting syntax.
- thayne 6y ago
  Not necessarily. A new type could be introduced and the old one deprecated. Even without introducing a new type, it could be improved in a backwards compatible way. For example, derive the Copy trait, and add a contains method that takes an owned value instead of a reference (at least as long as the Idx type is Copy).
  - Ygg2 6y ago
    Pretty sure they discussed this change on Reddit (https://www.reddit.com/r/rust/comments/ix751t/my_least_favorite_rust_type/ https://www.reddit.com/r/rust/comments/ix751t/my_least_favor...): Here is the discussion > In 2021 edition the compiler team could change the meaning of (3..5) to resolve to a new type. Then if you wanted the old type you have to request it by a fully qualified name or something. And the responses was: > That would be pretty awful. I think it would be better to change IntoIterator and warn for differences in copy and intoiterator in both editions so you can write portable code.
TillE 6y ago
I was super excited about the idea of Rust but constantly frustrated trying to use it to write real code. I've basically decided to stay in my (ever-improving) comfort zone of C++ until Rust gets named/default arguments, which is my arbitrary litmus test for whether it's going to actually be a usable language for me.
- svnpenn 6y ago
  You can do that now. Its not quite the same but pretty close: fn f(n: Option<u8>) -> u8 { match n { Some(n0) => n0, None => 10 } } fn main() { let n1 = f(Some(20)); let n2 = f(None); println!("{} {}", n1, n2); }
  - djur 6y ago
    This doesn't demonstrate either named or default arguments. You can expand on it to implement the equivalent of default arguments, sure, but it doesn't solve the ergonomic reason to have default arguments, and it doesn't touch on named arguments at all.
  - identity0 6y ago
    You're missing the point. Here's a good article that talks about the problems of having neither overloading nor default parameters, but in Go.[1] The problem is made significantly worse in Rust when all struct fields need to be initialized and there are no varargs. I really see no solution to the "stable API with more options" problem in Rust, aside from a builder pattern, which I really hate. 1: https://dave.cheney.net/2014/10/17/functional-options-for-friendly-apis https://dave.cheney.net/2014/10/17/functional-options-for-fr...
    - svnpenn 6y ago
      In Go, you can use an interface to implement private struct fields. Then you can make a "New" function to implement default values as needed. I made a post about this last month: https://stackoverflow.com/a/63552596 https://stackoverflow.com/a/63552596
coolreader18 6y ago
> I get a strong sense of Rust demanding that users subjugate themselves to all the choices and opinions of the architects [..] I don't really get where you're coming from here, especially with regards to this issue -- it seems like almost everyone, including Rust core team members, agree that `impl Iterator for Range` was an API design mistake, that came out of (IIRC) Iterator existing prior to IntoIterator in the pre-1.0 days. This seems to me to just be an unfixable design flaw due to backwards-compatibility rules, not something that really speaks to the design of the language as a whole.
- carlmr 6y ago
  >This seems to me to just be an unfixable design flaw due to backwards-compatibility rules This sounds like something that could be solved in the next edition.
  - timClicks 6y ago
    How?
    - floatboth 6y ago
      Make the (x..y) syntax construct some std::BetterRange for code in a new edition.
      - timClicks 6y ago
        But wouldn't that lead to backwards incompatibilities?
deleted 6y ago
[deleted]
thayne 6y ago
> I get a strong sense of Rust demanding that users subjugate themselves to all the choices and opinions of the architects I don't know why you feel that way. Any major language or standard library change goes through an RFC process, where anyone in the community can submit feedback, and from what I have seen, the official teams are very responsive to concerns.
- ShroudedNight 6y ago
  There are a few things: - The big one is that, at least what I see from my admittedly flawed perspective, there appears to be an active annoyance by a significant number of participants on the various issues on the importance of maintaining library ergonomics under constrained execution environments, with bare metal / free-standing environments being an obvious scenario. An example that comes to mind being stuff dealing with situations where 'global allocation' is actively harmful, which, in addition to happening in kernel development, also happens when building managed runtimes. - What comes across as an almost begrudging foreign-function interface, no ABI commitments, and lack of clarity about what is undefined behaviour under the `unsafe` operation needed to engage in any of this - Cargo VS rustc and integration into other build systems. Sanctioned VS unsanctioned paths more generally. - Prominent people in the community making comments about actively suppressing individual stylistic preferences because it's better for the collective
  - ChrisSD 6y ago
    That last one is a common enough idea nowadays. Prominent people in every community advocate enforcing code style rules (Douglas Crawford's Javascript linter is famous as an early example and gofmt is practically enforced in the community). The rest of the issues you mentioned are being actively worked on or investigated. Yes Rust 1.0 didn't solve all problems out of the gate and even now there's a lot of work still to do. But a lot of progress has been made and is being made. I get that if you don't follow issues, working groups, zulip chats, etc that it may not be obvious what is and isn't being worked on but I'm really not sure where you're getting this "arrogance" from.
    - 6y ago
jdub 6y ago
This is very far away from the Rust I know, both language and contributors. Since 1.0 Rust has improved a lot while maintaining compatibility, even through a big deprecation step like the 2018 edition. A good chunk of those improvements are about making Rust more usable and more forgiving. Some were things I didn't initially recognise as usability problems, but what came out the other side was absolutely better – the modules changes are a good example. Rust's lead contributors have been welcoming and humble – while also being human. It can be very frustrating running an open source project, and Rust is trying very hard to be open and inclusive, which increases the challenge. When writing Rust, there are definitely paths of least resistance. You often read about the moment people realise they're going "against the grain", and discovering why it's safar and/or faster to do it "the Rust way". But that's not subjugation. It's about understanding your tools, how they work, and what they're for.
higerordermap 6y ago
I see scope creep. I don't think it will be very suitable for quick get-webshit-done tasks because of its goals ans design, and they should focus on systems / high performance programming, like zig is doing.
fluffything 6y ago
> Range's idiosyncrasies and the antipathy to improving its ergonomics Can you point us to where this antipathy was displayed?
jswizzy 6y ago
I've always seen Rust as a transitional language like SmallTalk or ALGOL. It's a glance into the future of programming and the Next era of modern languages but probably not the next 40 year language itself.

Ygg2 6y ago

Sure. But to solve those idiosyncrasies, you need to abandon backwards compatibility or introduce conflicting syntax.

thayne 6y ago
Not necessarily. A new type could be introduced and the old one deprecated. Even without introducing a new type, it could be improved in a backwards compatible way. For example, derive the Copy trait, and add a contains method that takes an owned value instead of a reference (at least as long as the Idx type is Copy).
- Ygg2 6y ago
  Pretty sure they discussed this change on Reddit (https://www.reddit.com/r/rust/comments/ix751t/my_least_favorite_rust_type/ https://www.reddit.com/r/rust/comments/ix751t/my_least_favor...): Here is the discussion > In 2021 edition the compiler team could change the meaning of (3..5) to resolve to a new type. Then if you wanted the old type you have to request it by a fully qualified name or something. And the responses was: > That would be pretty awful. I think it would be better to change IntoIterator and warn for differences in copy and intoiterator in both editions so you can write portable code.

TillE 6y ago

I was super excited about the idea of Rust but constantly frustrated trying to use it to write real code. I've basically decided to stay in my (ever-improving) comfort zone of C++ until Rust gets named/default arguments, which is my arbitrary litmus test for whether it's going to actually be a usable language for me.

svnpenn 6y ago
You can do that now. Its not quite the same but pretty close: fn f(n: Option<u8>) -> u8 { match n { Some(n0) => n0, None => 10 } } fn main() { let n1 = f(Some(20)); let n2 = f(None); println!("{} {}", n1, n2); }
- djur 6y ago
  This doesn't demonstrate either named or default arguments. You can expand on it to implement the equivalent of default arguments, sure, but it doesn't solve the ergonomic reason to have default arguments, and it doesn't touch on named arguments at all.
- identity0 6y ago
  You're missing the point. Here's a good article that talks about the problems of having neither overloading nor default parameters, but in Go.[1] The problem is made significantly worse in Rust when all struct fields need to be initialized and there are no varargs. I really see no solution to the "stable API with more options" problem in Rust, aside from a builder pattern, which I really hate. 1: https://dave.cheney.net/2014/10/17/functional-options-for-friendly-apis https://dave.cheney.net/2014/10/17/functional-options-for-fr...
  - svnpenn 6y ago
    In Go, you can use an interface to implement private struct fields. Then you can make a "New" function to implement default values as needed. I made a post about this last month: https://stackoverflow.com/a/63552596 https://stackoverflow.com/a/63552596

coolreader18 6y ago

> I get a strong sense of Rust demanding that users subjugate themselves to all the choices and opinions of the architects [..] I don't really get where you're coming from here, especially with regards to this issue -- it seems like almost everyone, including Rust core team members, agree that `impl Iterator for Range` was an API design mistake, that came out of (IIRC) Iterator existing prior to IntoIterator in the pre-1.0 days. This seems to me to just be an unfixable design flaw due to backwards-compatibility rules, not something that really speaks to the design of the language as a whole.

carlmr 6y ago
>This seems to me to just be an unfixable design flaw due to backwards-compatibility rules This sounds like something that could be solved in the next edition.
- timClicks 6y ago
  How?
  - floatboth 6y ago
    Make the (x..y) syntax construct some std::BetterRange for code in a new edition.
    - timClicks 6y ago
      But wouldn't that lead to backwards incompatibilities?

deleted 6y ago

[deleted]

thayne 6y ago

> I get a strong sense of Rust demanding that users subjugate themselves to all the choices and opinions of the architects I don't know why you feel that way. Any major language or standard library change goes through an RFC process, where anyone in the community can submit feedback, and from what I have seen, the official teams are very responsive to concerns.

ShroudedNight 6y ago
There are a few things: - The big one is that, at least what I see from my admittedly flawed perspective, there appears to be an active annoyance by a significant number of participants on the various issues on the importance of maintaining library ergonomics under constrained execution environments, with bare metal / free-standing environments being an obvious scenario. An example that comes to mind being stuff dealing with situations where 'global allocation' is actively harmful, which, in addition to happening in kernel development, also happens when building managed runtimes. - What comes across as an almost begrudging foreign-function interface, no ABI commitments, and lack of clarity about what is undefined behaviour under the `unsafe` operation needed to engage in any of this - Cargo VS rustc and integration into other build systems. Sanctioned VS unsanctioned paths more generally. - Prominent people in the community making comments about actively suppressing individual stylistic preferences because it's better for the collective
- ChrisSD 6y ago
  That last one is a common enough idea nowadays. Prominent people in every community advocate enforcing code style rules (Douglas Crawford's Javascript linter is famous as an early example and gofmt is practically enforced in the community). The rest of the issues you mentioned are being actively worked on or investigated. Yes Rust 1.0 didn't solve all problems out of the gate and even now there's a lot of work still to do. But a lot of progress has been made and is being made. I get that if you don't follow issues, working groups, zulip chats, etc that it may not be obvious what is and isn't being worked on but I'm really not sure where you're getting this "arrogance" from.
  - 6y ago

jdub 6y ago

This is very far away from the Rust I know, both language and contributors. Since 1.0 Rust has improved a lot while maintaining compatibility, even through a big deprecation step like the 2018 edition. A good chunk of those improvements are about making Rust more usable and more forgiving. Some were things I didn't initially recognise as usability problems, but what came out the other side was absolutely better – the modules changes are a good example. Rust's lead contributors have been welcoming and humble – while also being human. It can be very frustrating running an open source project, and Rust is trying very hard to be open and inclusive, which increases the challenge. When writing Rust, there are definitely paths of least resistance. You often read about the moment people realise they're going "against the grain", and discovering why it's safar and/or faster to do it "the Rust way". But that's not subjugation. It's about understanding your tools, how they work, and what they're for.

higerordermap 6y ago

I see scope creep. I don't think it will be very suitable for quick get-webshit-done tasks because of its goals ans design, and they should focus on systems / high performance programming, like zig is doing.

fluffything 6y ago

> Range's idiosyncrasies and the antipathy to improving its ergonomics Can you point us to where this antipathy was displayed?

jswizzy 6y ago

I've always seen Rust as a transitional language like SmallTalk or ALGOL. It's a glance into the future of programming and the Next era of modern languages but probably not the next 40 year language itself.