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

121–130 of 164 posts

Re: Why I’m dropping Rust

#121

Post by eriknstr »

steveklabnik wrote: post #24
TillE wrote: post #15

Earlier quoted context omitted.

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.

There are already some CS courses in Rust, Penn is running another one this upcoming semester. (It's not a basic course, but you absolutely could.)

CIS 198 or something else? https://cis198-2016f.github.io/

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.

Re: Why I’m dropping Rust

#122

Post by ben0x539 »

lossolo wrote: post #68
paulddraper wrote: post #16

Earlier quoted context omitted.

While disclaimers are common (for some reason), it has no effect on the virtue of his points. It's just fluff.

I have different opinion on that matter. Sure, some of his points are valid, I even agree with some of them but not all and not always. That's why disclaimers exist, for that reason. Especially when there are cases of glorifying your own product and bashing others. Please read this: https://en.wikipedia.org/wiki/Bias

Have you made positive experiences with linking fairly long Wikipedia article to people who disagree with you?

Re: Why I’m dropping Rust

#123

Post by shadowmint »

loup-vaillant wrote: post #84
jerf wrote: post #78

Earlier quoted context omitted.

I am fairly confident "someone" could write a composition-based UI. I know of no fundamental reason why that would be impossible, or even any more difficult than doing one with inheritance. 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 languag…

Granted, current GUI toolkits are huge. On the other hand, I have worked with Qt, and this convinced me most of the complexity there was a blend of avoidable bloat and a long tail of features few people ever use (a bit like offices suites). 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 an…

    I'm pretty sure properly written GUI toolkits can be much smaller...
Given that as far as I know, there are no examples of tiny fully-featured GUI libraries (it's all either trivial like cgui or a massive bloated mammoth like qt/wpf/android), isn't that a bit of a rich statement?

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

Re: Why I’m dropping Rust

#124

Post by shmerl »

Someone should write a good book on Rust's approach to OOP and how it differs let's say from classic C++ when doing actual library design. Despite all the good documentation on Rust, this topic is really lacking clarity.

Re: Why I’m dropping Rust

#125

Post by barrkel »

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.

Using handles / indexes instead of pointers is a type hole and introduces similar problems of memory safety through the back door. The problems will be semantic in nature rather than more fundamental but will still be bugs.

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.

Re: Why I’m dropping Rust

#126

Post by pcwalton »

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.

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

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.

Re: Why I’m dropping Rust

#127

Post by pcwalton »

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.

Yes, it does. You can use a trait to provide extensibility.

Re: Why I’m dropping Rust

#128

Post by pcwalton »

hinkley wrote: post #29
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…

Given that Rust was designed by a group known for writing web browsers, how does that work out in practice, given that the DOM is a deep bidirectional graph? 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…

The JS engine manages the life cycle of all DOM objects. Other trees such as the flow tree just use reference counting and traits.

Re: Why I’m dropping Rust

#129

Post by wyager »

indolering wrote: post #120
partiallattice wrote: post #37

Earlier quoted context omitted.

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

This sounds like a failure of the Rust documentation.

The documentation is supposed to tell you what the language is, not exhaustively detail everything the language is not.

Re: Why I’m dropping Rust

#130

Post by chaostheory »

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.

Overall it's a great post detailing one of Rust's issues by the author, but this got me as well

> 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

Post reply on HN