Why I’m dropping Rust
medium.com
Why I’m dropping Rust
1–10 of 164 posts
Re: Why I’m dropping Rust
#2> For other use cases, Rust is still lacking. One such use case would be an OpenGL GUI, like CEGUI or nanogui.
I'm curious if anyone has tried developing a Qt5 app in Rust -- are there any Rust-ic bindings out there?
Re: Why I’m dropping Rust
#3The 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/traits.
Regarding graphs: The best solution is option 3, using a crate on crates.io (petgraph is the most popular, but rust-forest is fine too). The preferred solution to having multiple types of nodes in the same tree is to use an enum or a trait. (Servo uses a trait for its flow tree, with downcast methods like as_block() if needed.)
I'm puzzled by the contention that the fact that all nodes have to be the same type is a problem with Rust. That's always true in any language. Even in C, you'd have to have your next/previous pointers have some type, or else you couldn't traverse the list!
Re: Why I’m dropping Rust
#4Rust 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 that type, but it knows nothing about the implementation.
I'm not quite sure what the design goal was with the Widget type, but the closest solution is to replace the member variable in the abstract type with some kind of accessor (and to replace the magic negative font sizes with an Option):
trait Widget {
// ADDED: Access whatever underlying font
// size you have stored in this type.
fn desired_font_size(&self) -> Option;
// ADDED: Access the theme of this object.
fn theme(&self) -> &Theme;
// High-level interface to get font size.
// (With a default implementation in terms of
// other functions on this trait.)
fn font_size(&self) -> i32 {
if let Some(sz) = self.desired_font_size() {
sz
} else {
self.theme().get_standard_font_size()
}
}
}
> What IS the idiomatic Rust way to do a cyclical directed graph?
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. (EDIT: See below for a better solution.) It's not much different from the C++ solution.
The Servo team really wants GCed, safe pointer support in Rust, and design work is well underway. But it's going to take a while to stabilize.
GUI libraries are an interesting special case: They involve huge class hierarchies, lots of implementation inheritance, circular references, and tricky ownership. Most older OO languages were optimized for this case. Newer languages tend to favor flatter type hierarchies and far less implementation inheritance. Which means that traditional object-oriented GUI designs may be awkward.
Re: Why I’m dropping Rust
#5The author seems to be confusing typeclass composition with OOP. They are only topically similar. (Personal opinion; typeclass composition is more principled than OOP, but a bit more rigid, which he is running into.)
There are several good ways to do this with type classes/traits. One way is to write a function
font_size : Widget t => t -> FontSize
And then in the widget definition have the "internal" font size defined, which the author seems to be assuming the existence of for some reason.
Additionally, in a language like Rust with ADTs, there's no good reason to return negative numbers to signify things like a missing font. He should be returning Maybe FontSize if he wishes to signify that an object may not contain a font size.
Re: Why I’m dropping Rust
#6I 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.
Re: Why I’m dropping Rust
#7Rust 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…
> 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.
> The Servo team really wants GCed, safe pointer support in Rust, and design work is well underway. But it's going to take a while to stabilize.
We aren't going to use GC'd pointers for any of the trees except the DOM. GC is way overkill for this use case. The reason why we want GC support is not to make tree data structures: it's for integration with JavaScript.
Re: Why I’m dropping Rust
#8You can drop something when you use it some noticeable amount of time, not just couple of weeks. Otherwise it's more "I tried but it's not for me". There's nothing wrong with it - somebody will love Rust, somebody will not, somebody will love even Go - it's ok.
But title is too dramatizing.
Re: Why I’m dropping Rust
#9Rust 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…
> 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…
> 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...
Re: Why I’m dropping Rust
#10I don't know anything about Rust itself but I find it amusing that the author thought that six months should have been more than enough time for the community to agree on and implement a nontrivial change in how the language works.