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

41–50 of 164 posts

Re: Why I’m dropping Rust

#41

Post by lossolo »

acemarke wrote: post #26
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.

Honestly, just about anyone who's read an HN thread or two on Rust should be familiar with pcwalton's involvement with Rust at this point. I also don't see why he should have to insert a disclaimer paragraph in every single HN comment he makes.

He can make it inside his profile. Then i am not anyone because i didn't know he was involved in Rust some time ago, i learned that by a coincidence some time later.

Re: Why I’m dropping Rust

#42

Post by lossolo »

MaulingMonkey wrote: post #21
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.

Sounds like overkill to me? Would a comment in a profile be sufficient? (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?)

Sure, comment in profile would be sufficient.

Re: Why I’m dropping Rust

#43

Post by lossolo »

scott_s wrote: post #17
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.

I think pcwalton's extensive knowledge on not just how to program in Rust, but the rationale behind various design decisions should indicate to a careful reader that he is involved in Rust.

I disagree. I can know various decision behind various designs from reading what's going on github. And i know some of those decisions in different languages other than Rust, which doesn't indicate that I am involved with them.

Re: Why I’m dropping Rust

#45

Post by oldmanjay »

Animats wrote: post #32
partiallattice wrote: post #28

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.

Which flaw does it indicate? It seems like there is nothing about the solution that contravenes the design goals of the language.

Re: Why I’m dropping Rust

#46

Post by derkha »

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.

But widgets do have the same type: Widget, which the author already uses as a trait object. I think he was getting confused by mixing &Widget and Rc>. Just declare a type alias for the latter, use it everywhere, and it should work. You would do the about the same thing in C++, I believe.

Re: Why I’m dropping Rust

#47

Post by mcguire »

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.

Re: Why I’m dropping Rust

#48

Post by amq »

EugeneOZ wrote: post #8

You can drop something when you use it some noticeable amount of time, not just couple of weeks. Otherwise it's more "I tried but it's not for me". There's nothing wrong with it - somebody will love Rust, somebody will not, somebody will love even Go - it's ok. But title is too dramatizing.

> somebody will love even Go

Re: Why I’m dropping Rust

#49

Post by kevingadd »

lossolo wrote: post #39
mercurial wrote: post #20

Earlier quoted context omitted.

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?

If actually knowing what you're talking about is a harmful form of 'bias', pretty much any informed post on HN would need a disclaimer at the bottom.

Then again, that'd make it easier to filter out all the uninformed/overly cynical/inflammatory posts!

Re: Why I’m dropping Rust

#50

Post by stouset »

Animats wrote: post #32
partiallattice wrote: post #28

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.

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

Post reply on HN