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

171–180 of 298 posts

Re: My least favorite Rust type

#171

Post by centimeter »

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…

Haskell’s Foldable and Traversable typeclasses represent these use cases, are more general, and have none of the clunky edges mentioned in the article.

Re: My least favorite Rust type

#172

Post by saagarjha »

ccccc0 wrote: post #163
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?

If you ever create a BTreeSet , it will use String's PartialOrd, which is directly #[derive]d from Vec .

I have nothing against String having PartialOrd. I don't see why this means Vec should be PartialOrd–especially because treating a String as a Vec sounds very wrong.

Re: My least favorite Rust type

#173

Post by ShroudedNight »

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.

Re: My least favorite Rust type

#174

Post by 013a »

stouset wrote: post #169
gameswithgo wrote: post #151

Earlier quoted context omitted.

I feel that Golang makes a lot of these 80% solutions.

Honestly it feels more like they make a lot of 40% solutions.

Well, as others have said: Hitting exactly 80% is pretty much impossible. And we've established that hitting more than 80% produces languages that are often bad, in some way or another.

So, logically it follows: aim for less than 80%. You can always add things; you can't take things away.

Re: My least favorite Rust type

#175

Post by saurik »

dathinab wrote: post #167
R0b0t1 wrote: post #30

Earlier quoted context omitted.

Now that I know the details of Rust's range type it is extremely weird. The constraints need to be separate types. Why should range be so general as to support things that are obviously not ranges, only to return values indicating the range is malformed?

> obviously not ranges, only to return values indicating the range is malformed? It's not the case. The only think affected by range being generic is that `contains` takes a reference instead of a copy (which btw. can likely be eliminated by the optimizer). Which is necessary to allow thinks like `Range `. All other things have nothing to do with it being generic but with for which use cases it was designed for. In t…

But shouldn't len() panic instead of returning 0? I don't even understand how it could return 0 without having already done all the work to determine it should have returned a negative number.

Re: My least favorite Rust type

#176

Post by saurik »

tomjakubowski wrote: post #146
saagarjha wrote: post #141

Earlier quoted context omitted.

I assume the issue is with Rust letting you create such a range and then having the bad stuff happen when you try to use it, rather than failing fast.

Whether 5..0 being an empty range is "bad stuff" or "good stuff" is a matter of perspective. It is often "good stuff" for me, when computing some indices to slice with. Panicking on construction would force one perspective on every use case.

But why isn't it panicking on len()? How is 0 the right answer there?

Re: My least favorite Rust type

#177

Post by dathinab »

saagarjha wrote: post #141
kibwen wrote: post #133

Earlier quoted context omitted.

> The constraints need to be separate types. Why should range be so general as to support things that are obviously not ranges, only to return values indicating the range is malformed? I'm not sure what malformed return values this is referring to, because I can't think of any. Is it referring to the fact that ranges where the start is greater than the end will result in an empty range? Without dependent types, which…

I assume the issue is with Rust letting you create such a range and then having the bad stuff happen when you try to use it, rather than failing fast.

No the author misrepresents the facts.

If you index a slice with a out of bounds index it will panic independent of weather the index is a usize or a Range.

If you use `get` with a out of bound index you always get a None.

Sure it's open for discussion if why a range with start > end should be treated the same as an out of bounds index or if it should be treated as empty slice. But then doing the former makes it easier to catch errors.

Enforcing start Range's are mainly used ad-hoc (e.g. `slice[start..=mid+2]`) or `for x in x..y {...}` and are optimized for that usage patterns.

For other usages they might not be optimal. But you can always do your own types.

Re: My least favorite Rust type

#178

Post by andy_ppp »

leshow wrote: post #121
andy_ppp wrote: post #78

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

There are plenty of hurdles in Rust, but I wouldn't call this one of them. What exactly do you expect an Iterator for a range of vectors to do?

Traverse the entries?

Re: My least favorite Rust type

#179

Post by andy_ppp »

bilkow wrote: post #128
andy_ppp wrote: post #78

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

It looks like you can't. You can create a Range out of it, but the range is not an iterator. If you look at the Range docs[0], you'll see that it only implements Iterator where its generic type (A) implements std::iter::Step. Going to the Step docs[1] you'll see that its only implemented by integer types and char. If Vec implemented Step, you could iterate over it. Also, if you're referring to the "contains" guessing…

That’s what I did (at repl.it anyway)... how do I print the values in a Range of Vectors?

Re: My least favorite Rust type

#180

Post by a1369209993 »

013a wrote: post #174
stouset wrote: post #169

Earlier quoted context omitted.

Honestly it feels more like they make a lot of 40% solutions.

Well, as others have said: Hitting exactly 80% is pretty much impossible. And we've established that hitting more than 80% produces languages that are often bad, in some way or another. So, logically it follows: aim for less than 80%. You can always add things; you can't take things away.

> And we've established that hitting more than 80% produces languages that are often bad

No we haven't; we've established (for very dubious values of "established") that aiming for more than 80% is frequently not worth the trouble.

Post reply on HN