Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why I’m dropping Rust

medium.com

Post reply on HN
Print view View original

31–40 of 164 posts

Re: Why I’m dropping Rust

#31

Post by ekidd »

TillE wrote: post #15
pcwalton wrote: post #7

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.

"Safe" Rust works for almost everything in a typical CS curriculum.

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.

Re: Why I’m dropping Rust

#32

Post by Animats »

partiallattice wrote: post #28
ekidd wrote: 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…

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

Re: Why I’m dropping Rust

#33

Post by loup-vaillant »

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.

Re: Why I’m dropping Rust

#34

Post by mcguire »

pcwalton wrote: post #3

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/…

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

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?

Re: Why I’m dropping Rust

#35

Post by ekidd »

mercurial wrote: post #23
pcwalton wrote: post #3

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/…

> The preferred solution to having multiple types of nodes in the same tree is to use an enum That's not really a great option for a widget library, because it means no custom widgets.

In that case, just use Vec>, which means "a vector of objects which implement the Widget interface."

Re: Why I’m dropping Rust

#36

Post by [deleted] »

mercurial wrote: post #23
pcwalton wrote: post #3

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/…

> The preferred solution to having multiple types of nodes in the same tree is to use an enum That's not really a great option for a widget library, because it means no custom widgets.

[deleted]

Re: Why I’m dropping Rust

#37

Post by partiallattice »

wyager wrote: post #5

The 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 defin…

> The author seems to be confusing typeclass composition with OOP.

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.

Re: Why I’m dropping Rust

#38

Post by loup-vaillant »

ekidd wrote: 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: They involve huge class hierarchies, lots of implementation inheritance, circular references, and tricky ownership.

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

Re: Why I’m dropping Rust

#39

Post by lossolo »

mercurial wrote: post #20
lossolo wrote: 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? It would be fair if he was trying to push a product, but here it's just a technical discussion.

I am not claiming that he is pushing the product, just that his opinion can be biased, but then how would you want to push clearly technical product like Rust without technical discussion?

Re: Why I’m dropping Rust

#40

Post by stouset »

skywhopper wrote: post #10

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

Exactly. If you read that thread you can see there's careful and ongoing technical discussion of the details necessary to implement the feature.

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?

Post reply on HN