Live data from Hacker News

My least favorite Rust type

ridiculousfish.com

241–250 of 298 posts

Re: My least favorite Rust type

#241
post #202

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 themsel…

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

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).

Re: My least favorite Rust type

#242

So my first thought was "hey, why doesn't it take AsRef instead?" Then I checked the rust playground and... AsRef is not available for simple numbers, which I find confusing - since you can always reference an int, why isn't it?

I guess the same reason that `impl AsRef for T` isn't implemented. (Not sure exactly what that is, but that would probably be a better question to look into, since you could argue that `AsRef ` should be manually implemented for any std type T with your argument)

I don’t think they’re related. The blanket AsRef impl doesn’t exist because that would prevent you for providing different behavior (or blocking this behavior) for any of your types (eg smart pointers/containers) because rust doesn’t yet have impl specialization or override.

Re: My least favorite Rust type

#243

I can’t even figure out how to iterate over a Range of Vectors? iter and collect both don’t exist... Google doesn’t seem helpful either. I don’t know any rust but it seems unforgiving at the first hurdle here :-)

The whole idea of having Ranges of things without an obvious step function seems backwards to me.

Well, the std lib disagrees with you. In Rust, type definitions tend to be maximally generic and restricted with traits only in their implementation. Have a look at BTreeMap for example:

   pub struct BTreeMap {
       root: Option>,
       length: usize,
   }
The two type parameters are unbounded, this gives flexibility in the implementation because it allows you to define separate `impl` blocks where the bounds are different and more specific to their use case.

Have a look, https://doc.rust-lang.org/src/alloc/collections/btree/map.rs...

Sometimes the bounds are just Clone, other times they are more complicated Ord bounds for functions like `get`.

This is the way Rust libraries are written, it's very flexible and it's the right choice IMO.

Re: My least favorite Rust type

#244
post #155

For literals, clippy will catch this by default: error: this range is empty so it will yield no values --> src/main.rs:2:9 | 2 | let x = 5..0; | ^^^^ | = note: `#[deny(clippy::reversed_empty_ranges)]` on by default = help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#reversed_empty_ranges help: consider using the following if you are attempting to iterate over this range in…

May be worth moving to rustc, because that's not just bad style, that's incorrect code.

I disagree, sometimes you end up building empty ranges in your code for valid reasons (as a result of math, for example).

special casing a check on literals feels a bit like saying you can create an empty non-mutable vector.

Re: My least favorite Rust type

#245

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 themsel…

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.

Re: My least favorite Rust type

#246
post #244
post #155

Earlier quoted context omitted.

May be worth moving to rustc, because that's not just bad style, that's incorrect code.

I disagree, sometimes you end up building empty ranges in your code for valid reasons (as a result of math, for example). special casing a check on literals feels a bit like saying you can create an empty non-mutable vector.

I disagree, if this happens you want to document these edge-cases by failing early, this is very bad code if you don't and let the loop happen when most reviewers would have no idea if the result would be an unexpected behavior or not.

Re: My least favorite Rust type

#247

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 themsel…

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.

Re: My least favorite Rust type

#248

Earlier quoted context omitted.

The problem is that his/her proposal also says that start Now consider the usability nightmare `(1..10).unwrap()` would be and `&slice[(1..10).unwrap()]` and `(1..10).and_then(|range| slice.get(range))` instead of `slice.get(1..10)`. That's the actual problem, not that `Range` implements iterator. Oh and most ranges are used ad-hoc (created and then directly consumed) so for many use cases going with Range + IntoIter…

> The problem is that his/her proposal … Please just use the word “their”. “his/her” is not just awkward but also not even inclusive, as there are many people who do not use “his” or “her” pronouns.

Omg

Re: My least favorite Rust type

#249
post #240

Earlier quoted context omitted.

You can do that now. Its not quite the same but pretty close: fn f(n: Option ) -> u8 { match n { Some(n0) => n0, None => 10 } } fn main() { let n1 = f(Some(20)); let n2 = f(None); println!("{} {}", n1, n2); }

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.…

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

Re: My least favorite Rust type

#250
post #209

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 themsel…

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.

Not exactly what you want, but one option is to do something like:

    struct OptionsStruct {...}

    impl Default for OptionsStruct {...}

    impl Add for OptionsStruct {...}

    fn port(portnum : u16) -> OptionsStruct {...}
    fn timeout(millis: u64) -> OptionsStruct {...}
    fn maxconns(conns: usize) -> OptionsStruct {...}

    fn main() {
      ...
      // startServer("localhost", default())
      startServer("localhost", port(54321) + timeout(1000));
      ...
    }
Not the most ergonomic, I know, and requires custom architecting for each instance of this, but somewhat doable.
Post reply on HN