Live data from Hacker News

Why I’m dropping Rust

medium.com

51–60 of 164 posts

Re: Why I’m dropping Rust

#51
post #30

On trees: Can you use regular references for the children, and weak references for the link back to the parent? That's a valid structure that tears down properly. With strong backpointers, when one of the objects is deleted, there's a moment when there's still a live reference to it. That's invalid under Rust's rules, so you can't do that. There's also the option to own all tree objects with some collection for alloc…

The only real difference between a weak and strong pointer is that weak pointers are less prone to leaking memory (in exchange for the possibility of "sorry I'm dead" being a response to accesses). As soon as you upgrade such a pointer you've created a cyclic graph.

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.

Re: Why I’m dropping Rust

#52
post #32

Earlier quoted context omitted.

> > 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. The point about C++ is important. Cyclic graphs are hard in any…

The usual solution is to put the cyclic graph code into a library, and to use pointers and about 20 lines of unsafe code. That indicates a fundamental design flaw in the language.

The fundamental flaw being the lack of a GC?

Re: Why I’m dropping Rust

#53
post #14

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.

Why do you think it would be fair? Are you implying he is biased? But aren't we all biased for our own pet technologies we advocated, use and convinced others to use?

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

Re: Why I’m dropping Rust

#54

So, you want class based polymorphism, and you want trees of objects with back references. Sounds like Qt to me. I have the feeling the author tried to translate his knowledge of OOP languages to Rust. 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.

Ocaml has a GC and supports class based inheritance, right?

Re: Why I’m dropping Rust

#55
post #4

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…

> GUI libraries are an interesting special case

> 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.

Re: Why I’m dropping Rust

#57
post #50
post #32

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. That indicates a fundamental design flaw in the language.

In what conceivable way? 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, y…

And if something goes wrong, you can at least narrow down your search to unsafe areas of the code.

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.

Re: Why I’m dropping Rust

#58
post #53
post #14

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.

Why do you think it would be fair? Are you implying he is biased? But aren't we all biased for our own pet technologies we advocated, use and convinced others to use? 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

Because humans are only humans, we are biased more if we are emotionally involved in something, more time you spent creating something, investing your time, more you are biased. It's about level of bias also, someone that is only using some technology is not so biased as someone that is creating one. It's psychology 101.

Re: Why I’m dropping Rust

#59
post #47
post #4

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…

" 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. " Any details on this? GCs and finalizers don't really work well together, which is why I gave up on my cycle detector implementation.

They want objects that can be shared with Javascript.

Re: Why I’m dropping Rust

#60
I have been feeling that way ever since two years ago when I first looked at the language. I still don't understand why this language has such popularity. It's really bad for the reasons mentioned. C++ is a solid language where you can do everything you want and also write memory safe code in a clean way with unique_ptr. C++ is not perfect but to me no alternative come close yet, rust and go comprised.
Post reply on HN