Live data from Hacker News

My least favorite Rust type

ridiculousfish.com

141–150 of 298 posts

Re: My least favorite Rust type

#141
post #133
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?

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

Re: My least favorite Rust type

#142

Quoted post unavailable.

I don't know anything about Johnathan Blow, so could you explain why you have a hard time taking him seriously about PL design?

I'm not as dismissive to jblow, but I am frustrated with his model of development and the inflated expectations that come with it. It's quite likely that Jai will be a great language but it won't be the silver bullet some seem to think that it is. There's nothing more annoying than talking about the tradeoffs between compile time and static analysis only for someone to say "but Jai solved it" (and yes, I have conversations with people who do say this).

Imagine I had a startup and kept on posting about how amazing my product was and how everybody was going to find it revolutionary, and maybe I even shared a few streams of me using it, but I didn't release. And this continued for like, 6 years. Wouldn't you get a little suspicious? Even if I was running a closed beta. Even if I had a proven track record.

Writing a language and keeping it locked up while you perfect it just isn't a great model of development. Languages are not just the compiler and the corresponding features. They're tooling and infrastructure. They're libraries. They're communities. It may be wonderful to work sans the usual politics of open source, but you're not gonna end up making a language that people use.

And maybe that's not jblow's goal. Maybe he just wants a language for himself. Well, good for him. But that seems a little sad. Programming languages are some of the most generous, wonderful gifts to the CS world. If I were him, I'd hate to see my language die with me.

Re: My least favorite Rust type

#143
post #129

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.

What many companies seem to fail to realize is that for a significant portion of advertising you'll never know if it was a waste or not.

Re: My least favorite Rust type

#144
post #138
post #41

I broadly agree with this, and am most frequently confused by the fact that a `Range ` isn't `Copy` even if `T: Copy`. I feel this was a small design mistake (having `Range` itself be an interator instead of implementing the `IntoIterator` trait) but there is a proposal to fix this that looks like it wouldn't be breaking, and so should be possible: https://github.com/rust-lang/rfcs/issues/2848

Yeah, this sounds like it could be fixed with a one-liner without any breaking changes: `impl Copy for Range where T: Copy {}`. That being said, I can understand why this might not necessarily be desirable for some people; Copy is generally reserved for types that are "small enough" that implicitly copying the bytes will be cheap enough to ignore. It might seem obvious that a struct containing two types that are Copy…

The reason this can't be done quite as you describe is outlined in the linked issue: if something implements both `Iterator` (as Range does) as well as `Copy`, then you can end up in situations where you accidentally end up copying an iterator you think you're mutating. A good example is provided here:

https://github.com/rust-lang/rust/issues/48649#issuecomment-...

Re: My least favorite Rust type

#145

Implementing PartialOrd for Vec is a fairly strange choice to be honest. I'm curious why lexicographic ordering was chosen for this.

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?

Re: My least favorite Rust type

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

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.

Re: My least favorite Rust type

#147
> A practical problem is writing correct bounds checks. For example, consider the get_unchecked function on slice - it says “an out-of-bounds index is undefined behavior” but never defines what out of bounds means. So how does one even call this function safely?

Except that it's well defined: If you start or end after then end of the array/slice/vector. The same way it's done for any other array/slice/vector access.

Could the documentation of this nightly experimental API be better, sure. Is it undefined or unusable? No it's as well defined as "an array index being out of bounds".

Oh and it's only defined for Range before you wonder there is no confusion with any ranges of custom types, this a method of a trait implemented for only for Range which generalizes the indexing of slices and of which everything but the name is currently unstable/experimental.

Re: My least favorite Rust type

#148
post #140

Quoted post unavailable.

You started a flamewar and fueled it with 35 comments. That's beyond the pale. In fact, it makes me wonder what the record is for a single user in a flamewar on HN. Can you please not do this again? I appreciate https://news.ycombinator.com/item?id=24548161 , but vandalism is not a good way to pass the time. Not arson either. You did the same thing in other threads today too (e.g. https://news.ycombinator.com/item?id…

Well, it was never my intention to do something that you would consider vandalism.

Re: My least favorite Rust type

#149
post #8

Why does Rust allow Ranges for types that don't have comparators in the first place?

Exactly my question.

>If you try to enforce that start What even is a "range of non-comparable things"? Doesn't the very definition, included in the article, imply an ordering because of the "upper" and "lower" bounds? What on earth is a situation where "upper" is not necessarily greater than "lower"?

Re: My least favorite Rust type

#150
post #140

Earlier quoted context omitted.

You started a flamewar and fueled it with 35 comments. That's beyond the pale. In fact, it makes me wonder what the record is for a single user in a flamewar on HN. Can you please not do this again? I appreciate https://news.ycombinator.com/item?id=24548161 , but vandalism is not a good way to pass the time. Not arson either. You did the same thing in other threads today too (e.g. https://news.ycombinator.com/item?id…

Well, it was never my intention to do something that you would consider vandalism.

I know that, which is why I didn't rate limit or ban your account. These things mostly happen unintentionally. The thing is, though, we have to judge them by their effects, not intentions, since it's the effects that have...effects. https://hn.algolia.com/?dateRange=all&page=0&prefix=true&sor...

You're a good HN user and the only thing that's needed here is a bit more mindfulness. I like the 'arson' analogy for this sort of thing, except it's the wrong word since it implies intent. The right analogy is not arson, but negligence, i.e. playing with fire for fun or what have you, but then it burns down the building.

There's nothing intrinsically wrong with this thread. It's perfectly good watercooler conversation. That's part of the original intention for HN (let me dig up an old pg link...ah yes: https://news.ycombinator.com/item?id=8314). We all enjoy talking smack with coworkers or friends—same way one might argue about whether so-and-so is a good athlete or actor or whatever. On that level, what you did wasn't wrong at all, it's perfectly fine and good fun.

The issue is just that this particular watercooler gets broadcasted to millions of people, which suddenly makes for completely different dynamics. For example, the person you're talking about may well read the thread, which may sour them on HN and make them less likely to participate here, which would impoverish the site for all of us. That doesn't mean you shouldn't ever post criticism, but it should be alloyed with respect, and if the thread starts to turn into a cage match, you should do something to try to walk it back. (By "you" I don't mean you personally, but all of us.)

The biggest issue, though, are the feedback loops that happen when you're no longer talking to a couple people you already have good connections with, but an entire crowd of people who you have zero connections with. Your comments are guaranteed to get interpreted in ways that you not only didn't intend, but would find horrifying and would never dream of meaning. A lot of dark stuff flows in that way. Then people read it and feel licensed to start doing the same and worse—why not, if that's the kind of place this is? This is how internet forums decay, and the decay is exponential, so we have to be proactive about not letting that happen. That also is one of the founding intentions of HN: https://news.ycombinator.com/newswelcome.html.

Unfortunately, this does mean we need to have more restrained conversation than would be most enjoyable in a small group. People instinctively do this when talking to large groups, but HN is a large group that feels like a small group, so those instincts don't kick in. And of course it's also one of the best things about HN that it feels like a small group.

Past comments about this, if anyone wants a fuller picture:

https://news.ycombinator.com/item?id=21633967

https://news.ycombinator.com/item?id=15378909

https://news.ycombinator.com/item?id=9378899

https://news.ycombinator.com/item?id=7906377

https://news.ycombinator.com/item?id=7742471

https://hn.algolia.com/?dateRange=all&page=0&prefix=true&sor...

Post reply on HN