Hacker News Reader

Comment by dgb23 | Hacker News Reader

I haven't done any UI work in Rust, have used the language sparingly on the side.

But while reading the article, I was thinking "You're modelling the tree wrong! The memory layout doesn't need to know that it is a tree!" - gladly we came to the same conclusion.

The funny thing with this pattern is that Rust is much more loose when it comes to modelling with hashmaps and vectors. You are essentially creating user-space references and maintaining them with your own logic.

You're basically circumventing the borrow checker, but also a lot of other problems as you encapsulate the maintenance of these references within your tree / graph data structure.

But in a sense it's cheating! When you give me a key to a hashmap, do _I_ know whether the thing is there?

View on HN

But doesn't maintaining references using a hashmap mean that you've got to cleanup, which is basically (the hardest part of) memory management?

Exactly!

But the cool thing with laying out your graph like that, is that it has a relational character to it.

You’re essentially dealing in tables and (one/many) to many relationships.

You have a birds eye view of where your entities are allocated and how they are connected.

You still need policies around how you clean them up (remove an entity) and how the edges are affected. But you can reason about that in a similar way as you would in a relational database.

That does not feel like advantage unless you can do relational algebra on it all, though. Without that, it's more like dBase and similar languages of that era, where you had to manually juggle tables and cursors. People did UI that way too, but there was a reason why the OOP approach with object graphs and references quickly became dominant once it appeared - it's still a much more natural way to model this.

You're not circumventing the borrow checker though. You can only access a hashmap/vec entry if you have the right borrow of it's container. Unless you play around with unsafe, the hash map entries that stay in the container will live at most as much as the container.

This is what the borrow checker does. The index is just for doing an If let Some(entry) = map.get(&ident) {}

and not fail if it does not exist. Do you want to keep stuff alive even if they are removed? You can use reference counter wrappers (Rc and Arc) just fine.

The right pattern for graphs etc in vectors and maps is that the owning struct/type is responsible for keeping its internal state (indices it knows to exist) consistent. But that's not a memory safety issue, it's a logic issue

> But in a sense it's cheating!

Once you start cheating you might as well write yourself a garbage collected language and use that to write your UI library.

I'm not a rust developer, but I see all the signs and scents of somebody who detects the truncheon and the trap.

My guess is that you're adrift in a continuum made by somebody else who started with one goal, but found an ancillary surprise benefit worthy of persisting under the umbrella of the previous illusion. Bricks kept getting put down, the pamphlet never changed, then bam there you are.

I wager you're right in the mix before former turned to latter.

Sorry, I read your comment twice but I have no idea what you're trying to say.

Me too so I asked ChatGPT to rewrite his comment like a high school student would write :

ChatGPT: I'm not a rust developer, but it seems like you know what you're talking about when it comes to detecting problems and traps.

My guess is that you're stuck in a situation that someone else created. They started with one goal, but found another good thing that they wanted to keep doing. They kept building and never changed their plan, and now you're stuck in the middle of it.

I think you were there before things started to get weird.

Not sure why your comment got downvoted. I’m also not sure I really understand what you’re saying, although I get the hunch that it might be a valuable description?

Reply on news.ycombinator.com