Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

My least favorite Rust type

ridiculousfish.com

Post reply on HN
Print view View original

211–220 of 298 posts

Re: My least favorite Rust type

#211

Post by devit »

IshKebab wrote: post #131
j4nt4b wrote: post #3

I'm only just learning Rust so I don't know much about Rust development, but what are the chances that any of the suggestions listed at the end make it into the language?

Pretty much zero. All his points are 100% valid, but they're probably annoyances that we can live with, and Range is a really core type - changing it would break basically all Rust code in existence.

New types could be introduced, a..b and other range syntax could resolve to them in next edition and cargo fix could add ".into()" to convert when needed.

Re: My least favorite Rust type

#212

Post by devit »

saagarjha wrote: post #145
IshKebab wrote: post #132

Earlier quoted context omitted.

I think that's what you would expect. Why do you think it is strange?

I don't know, I just find the concept of lexicographically ordering vectors something that isn't really useful. Can you think of examples where this might be something you would want?

Obviously you need a PartialOrd (and Ord, PartialEq and Eq) implementation for all fundamental data structures, since otherwise they are unusable (can't sort to canonicalize ordering, sort+uniq, use as btree keys, etc.).

Lexicographic order is the most common choice for vector; the other reasonable choice is length-then-lexicographic.

Re: My least favorite Rust type

#213

Post by saagarjha »

devit wrote: post #212
saagarjha wrote: post #145

Earlier quoted context omitted.

I don't know, I just find the concept of lexicographically ordering vectors something that isn't really useful. Can you think of examples where this might be something you would want?

Obviously you need a PartialOrd (and Ord, PartialEq and Eq) implementation for all fundamental data structures, since otherwise they are unusable (can't sort to canonicalize ordering, sort+uniq, use as btree keys, etc.). Lexicographic order is the most common choice for vector; the other reasonable choice is length-then-lexicographic.

The alternative I'm suggesting is that it is not implemented at all.

Re: My least favorite Rust type

#214

Post by coolreader18 »

ShroudedNight wrote: post #173

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

Re: My least favorite Rust type

#215

Post by nitrobeast »

pas wrote: post #129
nitrobeast wrote: post #26

Earlier quoted context omitted.

This statement seems very true, even to the point of “duh” for people who have designed and maintained semi-widely used API or applications. I wonder where the language design wisdom to the contray come from.

Similar to the marketing/advertising axiom: 80% of all marketing spending is waste, but you you will only know after it has been spent.

I'm unfamiliar with marketing but I suspect the situation is much better now with all the tracking. And I can imagine for many APIs, people do know what most frequently used features are, and what typical users are like.

Re: My least favorite Rust type

#216

Post by coolreader18 »

viraptor wrote: post #161

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)

Re: My least favorite Rust type

#217

Post by seph-reed »

WhyNott wrote: post #6

I feel like this is an example of what Jonathan Blow calls a "Big Idea" or a "100% solution". His thesis is that when you make a feature of a language too abstract and usable in many different contexts, eventually there will be so many corner cases that the result will almost certainly be clunky and full of footguns. He claims that language designers should aim for "80% solutions" instead, which cover most common usa…

This is crazy, but I kind of like the way web does new features.

They start off with a name that obviously will never be needed (eg "moz-blur") and work with that for a while until it becomes apparent what "blur" should be.

If the rust developers had named "Range" as "RustRange" or something else weird to start with, then they could come back through later and name it to the more desirable name. This seems like a good tactic whenever you're still trying to figure something out but intend to put it in production anyways.

Re: My least favorite Rust type

#218

Post by svnpenn »

TillE wrote: post #209
ShroudedNight wrote: post #173

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.

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);
    }

Re: My least favorite Rust type

#219

Post by lilyball »

dathinab wrote: post #185
matklad wrote: post #53

>This does mean writing for n in (1..10).iter(), but Rust already requires that for collections, so it’s more consistent. Even this needn't be the case. `Range` can implement `IntoIter` to plug into `for` loop syntax. Another related problem is that `SliceIndex` ( https://doc.rust-lang.org/std/slice/trait.SliceIndex.html ) trait, which is used to implement indexing, is perma-unstable. So, even if you build your own b…

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.

Re: My least favorite Rust type

#220

Post by djur »

svnpenn wrote: post #218
TillE wrote: post #209

Earlier quoted context omitted.

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.

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); }

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.
Post reply on HN