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

71–80 of 164 posts

Re: Why I’m dropping Rust

#71

Post by oldmanjay »

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

Do you honestly feel like this comment would help a person to see your side of 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.

Re: Why I’m dropping Rust

#72

Post by dang »

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.

Nah, most HN readers know that and the rest are smart enough to figure it out.

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.

Re: Why I’m dropping Rust

#73

Post by Manishearth »

mcguire wrote: post #47
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…

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

http://manishearth.github.io/blog/2016/08/18/gc-support-in-r...

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.

Re: Why I’m dropping Rust

#74

Post by lossolo »

woodman wrote: post #67
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.

It sounds like you'd like a signal that allows one to more quickly switch off their brain, like network television prefixing party affiliation to politician's names. "Oh it is a R talking? Well as a D I can assume that everything said is wrong, no need to evaluate individual points."

No, for me it's making the brain to see the whole picture, not turning it off. If you choose to turn off your brain when you have more information about person that is giving his personal opinions then it's your own choice. I even wrote in other comment that i agree with some of his points which contradicts your "no need to evaluate individual points".

Re: Why I’m dropping Rust

#75

Post by mastax »

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…

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

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

Re: Why I’m dropping Rust

#76

Post by woodman »

lossolo wrote: post #74
woodman wrote: post #67

Earlier quoted context omitted.

It sounds like you'd like a signal that allows one to more quickly switch off their brain, like network television prefixing party affiliation to politician's names. "Oh it is a R talking? Well as a D I can assume that everything said is wrong, no need to evaluate individual points."

No, for me it's making the brain to see the whole picture, not turning it off. If you choose to turn off your brain when you have more information about person that is giving his personal opinions then it's your own choice. I even wrote in other comment that i agree with some of his points which contradicts your "no need to evaluate individual points".

What possible use for the additional information is there except for an appeal to authority (which isn't useful in technical discussions)?

Re: Why I’m dropping Rust

#77

Post by lossolo »

oldmanjay wrote: post #71
lossolo wrote: post #68

Earlier quoted context omitted.

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

Do you honestly feel like this comment would help a person to see your side of 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.

As i noted before i agree with some of his points which means that i don't think that all his opinions are only driven by his bias. But that doesn't change what i wrote before especially if one can distinguish between what's valid technical fact and what's not.

Re: Why I’m dropping Rust

#78

Post by jerf »

loup-vaillant wrote: post #38
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

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

Re: Why I’m dropping Rust

#79

Post by __s »

stouset wrote: post #40
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?

He expects them to say "fuck it, we'll do it live"

Re: Why I’m dropping Rust

#80

Post by generic_user »

stouset wrote: post #50
Animats wrote: 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…

All languages have design flaws. Thats why people keep making new languages. Arguing that Rust does not have design flaws is going to arouse more skepticism then anything else.

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.

Post reply on HN