I'm not trying to code anything right now. I'm just trying to understand Rust itself better, so I asked how its users deal with a particular problem. Thanks!
- Posts
- 8
- Comments
- 581
- Joined
- 3 yr. ago
- Posts
- 8
- Comments
- 581
- Joined
- 3 yr. ago
Thanks, that is interesting about using a refcell. It hadn't occurred to me that a refcell was considered immutable for purposes of Rc. What about the issue of refcounting cylic structures though? I thought the route around that was weakrefs per someone else's suggestion.
By pointers, do you mean unsafe pointers that aren't borrow checked? I guess that's not really worse than writing a little bit of the program in C so it may be the right approach pragmatically. So I'm again wondering about Servo. I guess eventually Rust will get verification tools that let you check the soundness of "unsafe" code too. So the discomfort might only be temporary.
Sure, hashmap or numeric indices are abstractly equivalent to pointers, but Rust is supposed to be a low level language that can deal with machine primitives, and pointers are machine primitives. Simulating them through extra levels of tables is unsatisfying. Also, the uses of those pseudo-pointers are no longer checked by the compler, so your program is vulnerable to many (not all) of the same old-fashioned pointer errors that Rust was supposed to rescue us from.
Thanks. I might ask on irc how Servo does it. Given Servo's connection with Rust, it would be surprising for this to be too awkward.
Thanks, I will check that. It sounds interesting.
I guess that's possible. The sibling pointers can also be weakrefs, I think. I don't know if there are ever arbitrary links between DOM nodes rather than just the tree-like ones. But, you are onto something if creation of weakrefs safely avoids the pointer ownership rules. I'll have to look into this further.
Typically for this I’ve done some wrapper type around a vector storage for the node data (a wish.com arena, if you will). Links are just some abstraction around indices.
Not sure what wish.com is, but yeah, you're describing a traditional Fortran approach. I would say machine pointers are a hardware primitive, and using indices like that are an abstraction. Anyway, the reply is appreciated. It at least tells me that I'm not missing something super obvious.
Linked lists in general are cache unfriendly, though it helps if you have a relocating GC that puts the nodes back in order. The hash map idea is a possibility. I'm not actually trying to implement something like this. It's more of a question about Rust's approach from a PL perspective.
Thanks, this sounds like a pretty serious abstraction inversion, exposes you to various kinds of bugs such as memory leaks, and gives a performance hit from all the hashing compared with using machine pointers, but I guess it does get rid of the circular references. Is it really the idiomatic answer? I'm ok if it is, but it's not what I'd have expected from a low level language designed to replace C.
I don't see anything in the std::collections doc relevant to this question. Yes I knew about the presence of doubly linked lists in that library. Obviously you could implement the DOM structure unsafely with C-style pointers but then what are you getting from using Rust instead of C? So I hoped to hear how to do it safely, maybe using a library object as a building block. But, I don't think the stuff in std::collections suffice for the purpose.
Rust safety isn't necessarily built on unsafety, though apparently it is in the case of doubly linked lists. I think singly linked lists can be made safely in Rust, similar to using C++ std::unique_ptr. It's possible, though very complicated, to eliminate all the unsafety everywhere. Rust doesn't attempt this, but (for example) ATS does (ats-lang.org).
Anyway your scolding is unhelpful. If you've got a usable and clear answer to my question I'd be happy to try to digest it. Otherwise I don't see any point in continuing to respond.
I've never felt a desire to move off old-school IRC.
This again?
That seems to be an audio book on Libro. Barnes & Noble still has the physical book available online, but who knows. Anyway, the author is a former FB exec, so evil by definition, just maybe less evil than Zuckerberg. And I doubt she needs the money from the book.
My local library has 65 holds on 2 copies, lol. Maybe I'll look for it after the clamor has died down.
There are multiple books with that title, which is a reference to The Great Gatsby (https://www.gutenberg.org/ebooks/64317):
They were careless people, Tom and Daisy—they smashed up things and creatures and then retreated back into their money or their vast carelessness, or whatever it was that kept them together, and let other people clean up the mess they had made …
Thanks, that's reasonable to say, much more reasonable than "Rust is the one true language that is right for everything". No idea about long term careers in anything related to programming, because of AI displacing every sort of knowledge work. But Rust will probably stay relevant for a while.
Certainly, the concept of building a career around a programming language has always been unsound. Good programmers know lots of languages and can pick up new ones as the need arises.
If you want to study one language as a means of absorbing new ideas, I'd suggest Haskell rather than Rust. You probably won't get to use it at work directly, but it will make you a better programmer in general. learnyouahaskell.com is a good place to start.
The stuff here is way more professionally important than being good at Rust or any other language: https://antirez.com/news/112
- JumpDeleted
Rust is the New C
So post the transcript. LLMs don't interest me. Remember who it is who is trying to pitch a claim and find listeners. Or just tell me the main idea. If you're saying an LLM summary would suffice, that's even more evidence that the video is not worth watching.
You see laziness in not watching a video, but I see it in making the video instead of taking the trouble to think out the ideas and write them down.
- JumpDeleted
Rust is the New C
Can you name any reasonably popular language that hasn't been used for all those things? And if Rust is the new C, would anyone say C is universal? I've written tons of C. I can say C isn't universal. Specifically, there is no universal language so far. Serious programmers have to know lots of them.
- JumpDeleted
Rust is the New C
If the video has anything enlightening to say I'm sure it's ideas will get out into the part of the programming community that has learned how to read and write, and I'll find out about it then. If that doesn't happen, the video must not be so compelling after all. I'll wait and see.
- JumpDeleted
Permanently Deleted
Crosspost bots have been discussed many times and they are generally not wanted. Let reddit do its own thing. The extension sounds preferable to a bot if it's only for use by post authors.
- JumpDeleted
Rust is the New C
No I don't think I need to watch it. That's like saying I should watch TV all day to not miss anything important.
- JumpDeleted
Rust is the New C
Same issue. Does the person have trouble focusing their thoughts enough to write them down, or what? How long is the video, even? I shouldn't have to click it to find out.
Thanks, I'll look at the box-tree crate, but I'd say using indices instead of pointers is somewhat unsatisfying. C++'s advertised property is zero-cost abstractions, and Rust is supposed to have C++'s performance without the footguns. But if you compare those vector index operatons with primitive pointer dereferences, there are a bunch of extra instructions run at each operation, including a layer of memory lookups that can cause cache pressure and misses.
I think the most practical answers I've heard so far are to 1) use Rc/Arc and weakrefs, or 2) use unsafe operations on machine pointers in a hopefully carefully contained and abstracted part of the code.
Sorry about the slow responses as I'm occupied with RL stuff most of the time for now.