21–30 of 164 posts
I think it would be fair if you also would disclose that you are working in Mozilla and that you are directly connected to Rust when defending it on HN.
(Disclaimer: I'm working on a web based brainfuck ide/compiler/optimizer for my own amusement, and thus probably have some kind of dog in some kind of fight here?)
The solution linked to in "Go has a suitable answer" isn't relevant, because it doesn't support virtual methods. You can do the same thing described there in Rust by having a base struct, embedding the base struct in any child structs (composition over inheritance), and implementing Deref/DerefMut on the child if you like. Go has the exact same set of features Rust has here, no more: struct composition or interfaces/…
That's not really a great option for a widget library, because it means no custom widgets.
Earlier quoted context omitted.
> The usual solution is to put the cyclic graph code into a library, and to use pointers and about 20 lines of unsafe code. It's not much different from the C++ solution. Well, petgraph uses vectors and indices to avoid unsafe code, and it's the most popular graph library on crates.io. Really, the answer here is "use a graph crate on crates.io". If you don't know which one to use, the best answer is probably petgraph…
A lot of problems in Rust seem to involve replacing (smart) pointers with handles. Sometimes you really do want to do that, but it's bad if it's a necessary kludge. Like someone else said recently, it's a problem if you can't reasonably teach a basic computer science course in Rust.
(It's not a basic course, but you absolutely could.)
Earlier quoted context omitted.
> Well, petgraph uses vectors and indices to avoid unsafe code, and it's the most popular graph library on crates.io. Nice! I hadn't seen that yet, but it looks really interesting: http://bluss.github.io/petgraph/doc/petgraph/graph/struct.Gr...
Not sure if it's just me, but the ampersands at that link are displaying super weirdly on my end: https://i.imgur.com/Bg8rejM.png
Edit: Doesn't occur on IE 11, so it seems Chrome specific.
I think it would be fair if you also would disclose that you are working in Mozilla and that you are directly connected to Rust when defending it on HN.
I don't understand why the author wants to access fields from a trait. They can be accessed by the trait implementations, which makes sense, because the fields depend on the type.
Rust seems to be a poor match for the way the author wishes to solve this particular problem. That doesn't mean that their design is wrong, or that Rust is wrong, but it does mean that mixing the two would require rethinking parts of the design. > So a trait can define abstract functions, but can't access any underlying fields. In Rust, a trait is a purely abstract interface to a type. It explains how you can use tha…
> Unfortunately, the correct idiomatic way is that you try very hard to avoid doing so. Rust is all about clear ownership, and it doesn't like circular references.
> The usual solution is to put the cyclic graph code into a library, and to use pointers and about 20 lines of unsafe code.
The point about C++ is important. Cyclic graphs are hard in any non-GC'ed language because it breaks the ownership story.
Rust seems to be a poor match for the way the author wishes to solve this particular problem. That doesn't mean that their design is wrong, or that Rust is wrong, but it does mean that mixing the two would require rethinking parts of the design. > So a trait can define abstract functions, but can't access any underlying fields. In Rust, a trait is a purely abstract interface to a type. It explains how you can use tha…
UIs work routinely by the organizational principle the author is attempting. Nested groupings of related functions that often interact in small groups.
And the thing is, a pointer to your parent doesn't semantically mean an ownership relationship anyway. It s in fact an extremely clear declaration of the ownership contract because while the owner can own many things, an object in this graph can have but one owner.
Now, I'm not sure how you would encode this into a compiler, so the discussion may have to end there as being impractical to implement.
There's also the option to own all tree objects with some collection for allocation purposes, and use weak references for all inter-object links.
As for traits, Rust does seem to have an overly novel and complex type system, and I'm not going to defend it.