Why I’m dropping Rust
medium.com
medium.com
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!
That's not really a great option for a widget library, because it means no custom widgets.
Or, couldn't you have a vec that owns the nodes and use indices instead of pointers? Or use pointers with the lifetime of the vec?
It hasn't languished, it's not just a bunch of +1s met with developer silence. What precisely is the author expecting the Rust team to do better on here?
"Right, so they've been working on this potential change since 2016, and...wait. 2016?!"
If he'd said 2014 or earlier, I'd consider him to have a point. 2015 is asking for a bit too much, but I can still see his frustration; I'd call that a wash. But 2016? It destroyed his credibility with me, because it's clear he has no idea what he's talking about when it comes to developing a programming language.
I know that sounds harsh but...man. He's leaving Rust because they're taking more than six months to implement a massive change to a core language mechanic? Have fun working with absolutely any other language ever.
Reads to me like he is disappointed that they didn't start the process sooner and have just recently started to discuss a solution.
> Rust's ecosystem, since Rust itself is reasonably young, is still in a developing stage.
> What I didn't know though, was that when you hit a road-block, finding a solution feels like navigating a jungle.
Living on the edge always has a price
I might be wrong but judging from this, I felt like we might never reach a conclusion on this topic even in a considerably long enough time, since it did seem to me that the core team is not interested in this feature.
From this point of view, I don't think it matters too much when we debate if six month is long enough, even if we waited longer, I'm not sure if the situation is gonna change when interest in this feature stays low.
> it did seem to me that the core team is not interested in this feature.
To re-phrase someone from the Reddit, you can't win: if we don't add new features but fix bugs, people claim that you ignore feature work, but if you add tons of new features, people wonder why you're bothering to add new features when there's lots of bugs open. It's tough.
Not that it's a bad thing but if he does programming as a hobby it means that he only used it a few hours a day for 6 months.
I don't quite understand why HackerNews gave so much importance to some random developer opinion on Rust.
> 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<i32>;
// 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.
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.
Nice! I hadn't seen that yet, but it looks really interesting:
http://bluss.github.io/petgraph/doc/petgraph/graph/struct.Gr...
Edit: Doesn't occur on IE 11, so it seems Chrome specific.
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.)
I am currently "attending" the above mentioned course by following along online. I am enjoying it very much so far. There have been three assignments so far, the first of which was to get rust installed and such. I think it would take most of the HN crowd less than a week to catch up with the course so that they can follow it for the remainder of the semester, even if they have a day job. The most experienced programmers might be able to catch up within just a few hours.
The schedule at https://cis198-2016f.github.io/schedule/ has links to the slides, lecture notes and assignments.
But if you want to teach an operating systems course or build cyclic, pointer-based data structures, you'll usually need a modest amount of "unsafe" Rust. Using "unsafe" gives you access to real pointers, which work just like they do in any systems language.
It's just that Rust chooses to lock those features away when you don't explicitly ask for them. If you actually need "unsafe", it's no more dangerous or more difficult than writing C code.
For the article author, I'd recommend going down a virtual DOM like approach rather than traditional OO toolkit. Rust meshes a bit more closely with functional ideas than OO.
It's not a kludge. It's how you prove to the compiler that you're using those structures safely.
If you aren't used to programming with compiler-enforced safety, you might be tempted to call working with the safety mechanisms a "kludge". But in reality all you're doing is doing things a little differently so that the compiler can ensure safety.
> 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.
That indicates a fundamental design flaw in the language.
Safe Rust allows one to do an incredible amount of things whole providing strong guarantees against the sorts of problems that plague lower level languages. Since this isn't suitable for absolutely everything, we have unsafe Rust to fill in the gaps in the small areas it's needed. Unsafe Rust isn't "bad", it just doesn't provide the same guarantees as safe Rust. And if something goes wrong, you can at least narrow down your search to unsafe areas of the code.
This isn't the sign of fundamental language design flaws. It's the sign of a phenomenally well-designed language, where the downsides of seldom-needed yet powerful features are limited to only those areas where they're used.
No. That's only true if the unsafe code presents a completely safe interface to its callers. If the safe code opens a hole in Rust's protection system, which is very easy to do, you can now have C-type no-idea-where-it-is bugs.
It is not mandated that you 'must' write safe code but that you 'can' write safe code. So there really is no fundamental assurance that rust and its libraries are in fact 'safe' by Rusts own definition in any meaningful sense.
You could make the same style argument that C is a 'safe' memory language also as long as you use automatic memory management and no malloc. Of course that would be a rather disingenuous claim to make.
As somebody who has used Rust since late 2012, I completely agree. It seems that most of the more sweeping claims come from those new and excited users - hopefully over time this will soften and become more reasonable. Hype is definitely something that needs to be kept in check though, as it more than often results in a back-fire.
That said, people also need to understand that many such instances are not design flaw, but are instead design tradeoffs. The OP indicated that having to switch to unsafe Rust to represent a cyclic datastructure is a design flaw. My response is that it's a tradeoff that pays dividends in every other piece of code.
Can Rust improve upon the number of problems that can be solved with safe vs. unsafe Rust? Absolutely! Is it worth cordoning off a few cases that don't technically need unsafe behavior, to ensure all other Rust code performs safely? Emphatically yes.
So I'd think a better way than saying "don't do that - or if you have to, you're on your own" would be to analyze use cases and see which scenarios the language can satisfy. (As another poster suggested in making "parent pointers" an explicit language feature(
- Back pointers. (They're not owning pointers, and they have a well defined relationship with some other pointer. The language may need some way to explicitly say that.)
- Collections where not all slots are initialized. (This requires simple proofs by induction as you grow a collection into previously allocated unused space.)
For real, honest-to-god, cyclic data structures — just use unsafe Rust. Again, unsafe Rust isn't "bad". It's just unsafe. More care will be expected of the code to ensure that it exports a safe interface, but nothing in the language stops you from doing it. There's quite literally no loss of expressive power.
It indicates that idiomatic Rust doesn't like cyclic references and thus you must step outside safe, idiomatic Rust to do that, it really just means that every language has an idiomatic way to do things to stay on that idiomatic road and not every way of doing things fits the idioms - they're still possible but not idiomatic. Given how the ownership system works, it makes sense
You may say that that indicates a flaw in the ownership system, but it doesn't. The ownership system can do certain things, but not all of them - it's designed to prevent the majority of common memory safety violations, but if it can't prove everything. That doesn't indicate a design flaw, it indicates a system limitation, same way a GC pause it's not a design flaw, but rather a limitation of a well deigned system.
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.
I believe that the JS engine has ownership over the DOM, and pointers into the DOM are GC'd by the JS engine. This is part of the motivation for adding hooks for GC's in Rust. These posts [1][2] discusses this, although I think there is a more recent one. Edit: more recent one here [4].
> 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.
This seems like a good use case for a Weak<> pointer [3].
[1]: http://blog.pnkfx.org/blog/2015/11/10/gc-and-rust-part-1-spe... [2]: http://blog.pnkfx.org/blog/2016/01/01/gc-and-rust-part-2-roo... [3]: https://doc.rust-lang.org/std/rc/struct.Weak.html [4]: http://manishearth.github.io/blog/2016/08/18/gc-support-in-r...
The road to hell is paved with good intentions, and I know myself and my cohort well enough that I appreciate the Rust sentiment on this subject. It was the main feature that drew my attention.
I'm wondering if this is a concrete concept that could be build into the ownership system. Logically speaking, this back pointer only exists to allow objects that are part of a Composition to reason about their environment, or be reasoned upon by an outside observer.
Maybe some of this information already exists in the language internals and you just need a function that can expose the owner of record of the object... There can only be one, right?
I doubt they have to be. There are other ways to do GUI, see for instance how Light Table uses a database-like Entity Component System. https://www.youtube.com/watch?v=V1Eu9vZaDYw
However, that does not solve the problem that all the mature existing UI widget toolkits are based on inheritance, and that causes a serious "impedance mismatch" with languages that don't have inheritance.
As I expect more languages to start privileging composition over inheritance, I also therefore expect this problem to continue to become more acute until "someone" finally solves it. However, GUI toolkits are huge and "someone" is likely to be a substantially-sized organization. The problem is going to have to become very painful before it is solved well.
I'm pretty sure properly written GUI toolkits can be much smaller. As in, satisfying 90% of our needs in a couple thousand lines of code. (The remaining 10% might require heaps and heaps of code, but I'm sure it doesn't have to affect the core.)
It's only an intuition at this point (I have yet to implement my own GUI toolkit). But I have reasons to believe this intuition is right: http://www.vpri.org/pdf/tr2012001_steps.pdf
The "long tail" is like the long tail of Excel or Word; yeah, everybody only uses 5% of it but everybody uses a different 5%.
I'm pretty sure properly written GUI toolkits can be much smaller...
Like, I'm sure you can write a procedural generator in a handful of lines of code that spits out the full works of Shakespeare. It's probably possible, if you have the right seed and the right algorithm.
...but practically speaking, how do you actually build one?
The same goes for UI libraries; certainly it should be possible (in theory) to have a minimal beautiful GUI libraries with an excellent API; but every attempt to build one seems to have failed.
Perhaps the problem domain is actually more difficult than you're giving it credit for...
I'm pretty sure we haven't explored the sheer depth of simplifications that can still be done.
I can't find anything on their website that seems to be that sort of thing?
Their writing is here: http://vpri.org/html/writings.php
Their various reports are there (most recent first):
http://www.vpri.org/pdf/tr2012001_steps.pdf
http://www.vpri.org/pdf/tr2011004_steps11.pdf
http://www.vpri.org/pdf/tr2010004_steps10.pdf
http://www.vpri.org/pdf/tr2009016_steps09.pdf
- http://www.fltk.org/index.php - https://github.com/froggey/Mezzano
Then again most gui libraries end up including networking, file handling, etc...
Any details on this? GCs and finalizers don't really work well together, which is why I gave up on my cycle detector implementation.
The reason Servo in particular would like GC hooks is because JavaScript is GCd and we want to be able to pass around Spidermonkey-managed pointers safely. We have a framework in place that does this, but proper compiler support would be nice.
Servo doesn't need to worry about finalizers because our DOM structs never have nontrivial destructors (explicit Drop impls).
The blog post throws around some ideas for dealing with the finalized problem though.
> traditional object-oriented GUI designs may be awkward
For example, Qt has moved that tricky part into a specialized language. I think that it's the way to go.
So it's okay if a low-level language is not designed to do that ancient stuff with pointers to widgets.
I understand his rant, but I don't think it is a valid one. You must change your design or change your tool, he opted to change the tool.
There's not much that I miss from OOP, and I now see its utility as more about making the ability to program scale predictably with an unpredictable workforce.
But title is too dramatizing.
Bad idea. Try F# first.
Seriously: my current favourite language is Ocaml, and it would have basically the same problems. But I don't care, because I don't think like that. I have other ways to solve my problems.
Yes, but the language is immutable and eager by default. That makes circular references a chore.
> and supports class based inheritance
Yes, but hardly anybody uses that part of the language. We tend to stick with modules and variations over them.
You can have inheritance via polymorphic variants: see Garrigue's `Code reuse through polymorphic variants`.
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.
I really like traits/type classes over OOP-style type systems but sometimes it causes a bit of impedance mismatch.
I agree and would like to expound on that idea. One of my biggest frustrations with inheritance in traditional statically typed languages (I program in C++ for a living) is that inheritance is performing two functions at once: code reuse and typing. Confusing the two seems to cause a lot of pain. Inheritance as a type system is describing the kinds of things the object can do. Inheritance is (usually) a sufficient condition to say that the types can be used interchangeably. Making inheritance the only way to express the type information often forces some very unfortunate code.
The author is trying to use traits as a code re-use mechanism. He wants the trait to be able to see into the implementation and be a function of the implementation's private data. If that were allowed, that would invite all of the pain of inheritance for that kind of trait. Types with a different internal implementation would end up being awkward at best.
I'm still interested and motivated to learn more. I hope to get a chance to spend time on it at work because a free hour here and there isn't enough for me to absorb this stuff.
And confession time: I haven't even done too much fighting w/the borrow checker, I'm still slowly absorbing the type system and other general stuff.
My confession: I've fought the borrow checker and lost a few times, and just scaled back what I wanted to do, so far.
Maybe someday I'll know what I'm doing :-) but I do like it so far, certainly more than C++.
It's hard to describe, and to say "if it compiles, it works" is not 100% accurate, but I would say "if it compiles, it works, and if it doesn't work, then I know it's my own logic error". It's like Rust guides you into the space of correct solutions and cleaner code when compared to other languages.
The other thing: there are huge dividends you reap from spending time in Rust that are realized when you go back to other languages. If you've spent your life in managed runtimes or more loosely-typed languages, you come away better for the time spent in Rust.
Yup, this has been my experience too. I started using Rust for my primary project last March and was worried a little at first about the risk of wasting too much time, but at this point I'm ~1.5x to 2x as productive as in C++11:
* essentially no more "head-scratching action-at-a-distance bugs" (I've spent N years in C++ and I still sometimes invalidate an iterator) -- as you say, any errors that still exist are higher-level logic errors, which are (in my experience) much more straightforward to track down.
* enums and match/destructuring and all the builtin types (e.g. Option, Result) have me thinking in a much more strongly-typed and principled way. So even logic errors tend to be less frequent because I break down the problem the 'right' way immediately. Algebraic datatypes let one describe a state space really succinctly.
Rust is one of those languages that really, strongly wants you to be idiomatic, but it pays off!
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.
He only way for Rust's type system to understand these kinds of access patterns in a way that doesn't require the insertion of "shared mutability" types (e.g. Mutexes) involves mutating the tree during traversals.
A simple version of such a pattern: a "doubly linked" list which is actually two singly linked lists. One "traverses" this list by popping nodes off one and pushing them onto the other. The user has easy access to the heads of both lists. You could probably do the same with trees but this is a pretty unpleasant pattern.
1. The borrow checker assumes accessors can do anything, freezing all other fields. This does not happen with trait fields. 2. Accessors have to use dynamic dispatch in case of trait objects, resulting in worse performance.
I'm curious if anyone has tried developing a Qt5 app in Rust -- are there any Rust-ic bindings out there?
It seems like if you want to have back-references you either would need to use Rc<RefCell<T>> or Arcs, which is not the end of the world.
The best way to do it would be to not have back references at all. Then you could simply have Vec<Box<Widget>> for children.
If I were going to build a GUI system in rust I certainly wouldn't design it to be OO. I think you would repeatedly run into problems. An entity component system or something like react might work better in rust.
This is a misunderstanding of what traits do. Interfaces in Java have no knowledge of the underlying implementation, either. And more generally, neither does an ABC: you can't use fields you don't declare in the ABC in methods declared in the ABC.
It is sad that Rust traits can declare only functions, not fields; so you must redeclare your fields as methods if you want to be able to use them as part of a default implementation (I think). Later the author explores this option -- but notes the "field methods" must be public along with the real interface of the trait. I am not sure what options Rust provides for making them private. For example, it might be possible to split the trait into a public and a private half. (But maybe not: https://github.com/rust-lang/rfcs/blob/master/text/0136-no-p...)
I do question the wisdom of the author's design at a higher level, because the author is using a trait for provide an implementation, not just an interface. If the implementation really applies to everything that matches the trait, it should probably be provided with a generic. If not, it is at worst tedious, but hardly limiting, to recycle a generic definition by calling it in an implementation.
That's a great question! So, uh, what is the answer?
> No warnings are emitted for objects of type ``std::unique_ptr`` and
> ``std::shared_ptr``, as they have defined move behavior.
Perhaps std::mem::forget
The issue about parent/children pointers mentioned in this article seems more a lack of understanding on the concepts of ownership and the traits system, for instance. It's indeed a harder problem to deal with in Rust if trying to apply a OO mentality, but one can find a way out if trying to understand the language first.
I have my personal thoughts about parts is Rust that could be improved; nevertheless, I don't see any issue with us excursions, and consider it an evolutionary step which brings system programming languages to a new level.
Why the redirect from medium.com?
Oh cool an anti-pattern being described as an "easy solution".
It's just fluff.
Please read this:
It's a basic assumption that anyone who speaks positively about a thing is biased in favor of that thing. We don't need to point out every instance of that bias because it would dominate every discussion while providing no value because it is something everyone fundamentally assumes in the first place.
And it isn't bias if you're right.
Then again, that'd make it easier to filter out all the uninformed/overly cynical/inflammatory posts!
(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?)
It is also possibly helpful if the commenter is elaborating on product that they are involved in to establish that their input is authoritative.
And not to give cause for inflated heads here :) but seriously, if you are seriously interested in this space, you sh/would already know the cast of mvps and thus major contributors such as Russ Cox or Patrick Walton (et al) would not require introductions.
To put it another way, is his argument or point invalid somehow? But then it would be invalid regardless if he worked for Mozilla or Microsoft or Google
We appreciate your concern for the integrity of the community. On the other hand, posts like this lead to flurries of offtopicness, so their cost/benefit is usually poor. We detached this subthread from https://news.ycombinator.com/item?id=12474588 and marked it off-topic.