Dave Herman’s contributions to Rust • Hacker News Board

Re: Dave Herman’s contributions to Rust

#31

Post by joseluisq » Mon, May 03, 2021, 11:36 AM UTC

Macha wrote: post #25

joseluisq wrote: post #19

Earlier quoted context omitted.

Yep, this needs a `dup` mark somewhere. Edit for down-voters: the typical HN behaviour. Don't be lazy and take a time to explain why you downvote.

https://news.ycombinator.com/newsfaq.html > Are reposts ok? > If a story has not had significant attention in the last year or so, a small number of reposts is ok. Otherwise we bury reposts as duplicates. > Please don't delete and repost the same story. Deletion is for things that shouldn't have been submitted in the first place. Dupes are not against the rules. You're likely getting downvoted by people aware of that…

If your affirmation is true, why many of HN users (me included) get [dupe] at first place? In general, Is not the HN intention to decrease number of duplicates? If not so then HN should provide a solution for prevent this, such prevention that is not happening today. Example search input.

Sorry but I'm seeing big contradictions in the so called rules.

Just one example:

> If a story has not had significant attention in the last year or so, a small number of reposts is ok. Otherwise we bury reposts as duplicates.

> "in the last year or so"

Not in the same month or even after some hours later.

> "a small number of reposts is ok"

Well, HN what to prevent duplications or not ?

> Dupes are not against the rules. You're likely getting downvoted by people aware of that.

With that premise in mind, let's continue making duplicate content. right?

So don't misunderstand me, since my intention here is just to put in evidence the same recurrent problem to improve HN. For instance I have also faced the same problem in the past so there is nothing agains rules or things like that, but instead is more a improvement for HN.

The reason because I'm interested on this is because I feel part of the community and this is a concern for me (I suppose for others too). Otherwise I could take the easy and dirty way to just say nothing and ignore the problem.

Re: Dave Herman’s contributions to Rust

#32

Post by nicoburns » Mon, May 03, 2021, 11:38 AM UTC

mkl wrote: post #18

akvadrako wrote: post #13

Earlier quoted context omitted.

How is it not clear that var is variable?

Yes. I think the problem may be with the other one. "val" (and "let") don't seem obviously constant to me.

Let is definitely confusing given that JS has let and const (with let being mutable)

Re: Dave Herman’s contributions to Rust

#33

Post by jeltz » Mon, May 03, 2021, 11:44 AM UTC

chrismorgan wrote: post #22

melling wrote: post #4

Haven’t learned Rust yet. I see they debated this: let and let mut let and var And went with the verbose option. Swift went with the succinct option, which I love about the language. In practice I suppose I do mostly type “let” in Swift so it doesn’t matter much Swift, however, chose ‘func’ instead of ‘fn’, after much debate. Those little things that are debated initially, then forever

A relevant period of history here is the mutpocalypse , where the question was raised “why are we calling this &mut and teaching it as being about mutability when what we actually care about (for memory safety) is uniqueness and aliasing?” Had that side prevailed, &mut would have been renamed (the main candidates presented were &uniq and &only), and all bindings would have become mutable (`let mut` would have disappe…

I agree with that thinking about it in terms of mutability is a bit missleading but I am not sure how your idea would fix the issues with RefCell and Mutex. Additionally I think that some code is clearer with enforced single assignment in the syntax.

Re: Dave Herman’s contributions to Rust

#34

Post by chrismorgan » Mon, May 03, 2021, 11:44 AM UTC

NanoCoaster wrote: post #29

chrismorgan wrote: post #22

Earlier quoted context omitted.

A relevant period of history here is the mutpocalypse , where the question was raised “why are we calling this &mut and teaching it as being about mutability when what we actually care about (for memory safety) is uniqueness and aliasing?” Had that side prevailed, &mut would have been renamed (the main candidates presented were &uniq and &only), and all bindings would have become mutable (`let mut` would have disappe…

> Mutability is easier to explain initially, but teaches an incorrect mental model that hinders a correct understanding of Rust’s approach to memory safety, falling apart as soon as you touch things like atomics, RefCell or Mutex. Could you elaborate or link to some material / discussion regarding that? I'd be very interested in how the alternative approach you're describing would change (or make unnecessary) constru…

The changes I described for the mutpocalypse vision are basically all there is to it, because &mut has always been a misnomer, never about being a mutable reference as its name replies, but rather about being a unique reference, that nothing else holds a reference while you have that one. The main thing the mutpocalypse sought to achieve was to adjust Rust’s syntax to match its semantics (including to remove mutability tracking on bindings, because that wasn’t part of Rust’s necessary semantics, and wouldn’t make as much sense after the trivial syntax change).

The thing I’m noting about atomics, RefCell and Mutex is how they have methods that (safely) mutate themselves, despite taking &self, a supposedly immutable reference.

(I’ve modified the final sentence in my original comment to clarify this.)

Re: Dave Herman’s contributions to Rust

#35

Post by est31 » Mon, May 03, 2021, 11:45 AM UTC

chrismorgan wrote: post #22

melling wrote: post #4

Haven’t learned Rust yet. I see they debated this: let and let mut let and var And went with the verbose option. Swift went with the succinct option, which I love about the language. In practice I suppose I do mostly type “let” in Swift so it doesn’t matter much Swift, however, chose ‘func’ instead of ‘fn’, after much debate. Those little things that are debated initially, then forever

A relevant period of history here is the mutpocalypse , where the question was raised “why are we calling this &mut and teaching it as being about mutability when what we actually care about (for memory safety) is uniqueness and aliasing?” Had that side prevailed, &mut would have been renamed (the main candidates presented were &uniq and &only), and all bindings would have become mutable (`let mut` would have disappe…

> falling apart as soon as you touch things like atomics, RefCell or Mutex.

Does it really fall apart? None of these constructs change the fact that if a &mut T is available, you can call functions on that type that take &mut self. The only thing that breaks is the assumption that non-presence of mut implies that there is no way to call those &mut self functions. If you change it to "non-prsence of mut implies that you need extra constructs like atomics, RefCell or Mutexes in order to get mutable access" it works out again.

Re: Dave Herman’s contributions to Rust

#36

Post by chrismorgan » Mon, May 03, 2021, 11:46 AM UTC

est31 wrote: post #35

chrismorgan wrote: post #22

Earlier quoted context omitted.

A relevant period of history here is the mutpocalypse , where the question was raised “why are we calling this &mut and teaching it as being about mutability when what we actually care about (for memory safety) is uniqueness and aliasing?” Had that side prevailed, &mut would have been renamed (the main candidates presented were &uniq and &only), and all bindings would have become mutable (`let mut` would have disappe…

> falling apart as soon as you touch things like atomics, RefCell or Mutex. Does it really fall apart? None of these constructs change the fact that if a &mut T is available, you can call functions on that type that take &mut self . The only thing that breaks is the assumption that non-presence of mut implies that there is no way to call those &mut self functions. If you change it to "non-prsence of mut implies that…

The mental model of & being immutable and &mut being mutable, that’s what falls apart. Here are types that are taking &, and yet are mutating themselves.

This becomes a huge deal when people think that they have an immutable data structure just because they have an & reference to it. Someone will inevitably stash a mutex or similar in there because they just need to be able to mutate it this once… I mean these three times… I mean all the time. Oh, you wanted this immutable data structure so you could diff it for your VDOM or incremental calculations or whatever? Heh, guess you’ll have to find some other way or structure things so that mutations can be propagated through the object tree or something. And you’ll keep on having cache issues from time to time when people forget to jump through the right hoops. Sorry about that.

So yeah, the mental model of &/&mut references being about mutability is just completely and harmfully wrong. Rust does not have a way of guaranteeing immutability.

Re: Dave Herman’s contributions to Rust

#37

Post by Macha » Mon, May 03, 2021, 11:51 AM UTC

joseluisq wrote: post #31

Macha wrote: post #25

Earlier quoted context omitted.

https://news.ycombinator.com/newsfaq.html > Are reposts ok? > If a story has not had significant attention in the last year or so, a small number of reposts is ok. Otherwise we bury reposts as duplicates. > Please don't delete and repost the same story. Deletion is for things that shouldn't have been submitted in the first place. Dupes are not against the rules. You're likely getting downvoted by people aware of that…

If your affirmation is true, why many of HN users (me included) get [dupe] at first place? In general, Is not the HN intention to decrease number of duplicates? If not so then HN should provide a solution for prevent this, such prevention that is not happening today. Example search input. Sorry but I'm seeing big contradictions in the so called rules. Just one example: > If a story has not had significant attention i…

> > If a story has not had significant attention in the last year or so, a small number of reposts is ok. Otherwise we bury reposts as duplicates.

> > "in the last year or so"

> Not in the same month or even after some hours later.

A year is the expiration date on reposts of items that _have_ had significant discussion. Items which did not have significant discussion, and also did not have a large quantity of reposts already are exempt. In some cases the mods have reached out to submitters and suggested they repost items which the mods felt were interesting but did not catch on.

Re: Dave Herman’s contributions to Rust

#38

Post by NanoCoaster » Mon, May 03, 2021, 11:56 AM UTC

chrismorgan wrote: post #34

NanoCoaster wrote: post #29

Earlier quoted context omitted.

> Mutability is easier to explain initially, but teaches an incorrect mental model that hinders a correct understanding of Rust’s approach to memory safety, falling apart as soon as you touch things like atomics, RefCell or Mutex. Could you elaborate or link to some material / discussion regarding that? I'd be very interested in how the alternative approach you're describing would change (or make unnecessary) constru…

The changes I described for the mutpocalypse vision are basically all there is to it, because &mut has always been a misnomer, never about being a mutable reference as its name replies, but rather about being a unique reference, that nothing else holds a reference while you have that one. The main thing the mutpocalypse sought to achieve was to adjust Rust’s syntax to match its semantics (including to remove mutabili…

I see, interesting point. Thank you :)

Re: Dave Herman’s contributions to Rust

#39

Post by wink » Mon, May 03, 2021, 12:02 PM UTC

nicoburns wrote: post #32

mkl wrote: post #18

Earlier quoted context omitted.

Yes. I think the problem may be with the other one. "val" (and "let") don't seem obviously constant to me.

Let is definitely confusing given that JS has let and const (with let being mutable)

But that is cross-language, which is not ideal but not an internal problem if you work in one code base. (O)Caml also has `let` and is quite a bit older than JS.

Re: Dave Herman’s contributions to Rust

#40

Post by chrismorgan » Mon, May 03, 2021, 12:02 PM UTC

NanoCoaster wrote: post #38

chrismorgan wrote: post #34

Earlier quoted context omitted.

The changes I described for the mutpocalypse vision are basically all there is to it, because &mut has always been a misnomer, never about being a mutable reference as its name replies, but rather about being a unique reference, that nothing else holds a reference while you have that one. The main thing the mutpocalypse sought to achieve was to adjust Rust’s syntax to match its semantics (including to remove mutabili…

I see, interesting point. Thank you :)

I feel like making one more note. I said that “mutable references” was a misnomer and that it’s actually about unique references, but even that’s a bit of a misnomer, because it’s not quite about uniqueness, but uniqueness of access. You can have multiple &mut borrows to the same thing, but only one of them is accessible at any given time:

  let mut x = 1;
  let y = &mut x;
  let z = &mut *y;
  *z += 1;
  *y += 1;
  assert_eq!(x, 3);

z and y both point to x, but only one is accessible at any point in time. Touching y finishes the z borrow; if you swapped the increment lines, it wouldn’t compile.

My memory is fuzzy (this was quite some years back), but I have a vague feeling that this lack of precision in the use of the word “unique” was a factor in some baulking at the proposed change. (“You’re trying to fix something that we admit is strictly wrong, but you’re not even making it right!”)