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

Rust Sucks If I Fail to Write X

llogiq.github.io

Post reply on HN
Print view View original

61–70 of 89 posts

Re: Rust Sucks If I Fail to Write X

#61

Post by jstimpfle »

ekidd wrote: post #10
jstimpfle wrote: post #6

> As an aside, remember that the only difference to C/c++ is that if you write a “basic linked list” in them, all of your code will be unsafe. I stopped reading here.

I think he means "unsafe" in the sense of Rust's 'unsafe' keyword, which allows you work with pointers just you normally would in C++. It doesn't mean all C++ is broken! Just that all C++ code has the right to use pointers or invoke undefined behavior without getting smacked down by the compiler.

He clearly states that code which depends on a linked list implementation is "unsafe" for that very reason.

To me that's not convincing argumentation. If code depends on a broken "unsafe" linked list implementation, that's bad no matter what language the code is.

What you say is true under some interpretation of "unsafe", but it doesn't relate with a broken "unsafe" linked list implementation.

Btw. since I'm not a Rust user I might miss something here. And I admit my post was a little short and thus maybe provoking. But just to let everybody know, I got at least 5 downvotes.

Given that answers to my post don't even see that OP implied a causal relationship, that doesn't help with my perception of the "Rust echo chamber on HN" (not my wording).

Re: Rust Sucks If I Fail to Write X

#62

Post by jstimpfle »

tyoverby wrote: post #16
jstimpfle wrote: post #6

> As an aside, remember that the only difference to C/c++ is that if you write a “basic linked list” in them, all of your code will be unsafe. I stopped reading here.

In the rust world "unsafe" is synonymous with "isn't proven to be safe by the compiler". Under this definition, every C/C++ program that uses pointers is "unsafe" because the languages make no memory safety guarantees.

No. He clearly stated that usage of an "unsafe" implementation is safer in Rust than C/C++. See my other post.

Re: Rust Sucks If I Fail to Write X

#63

Post by jstimpfle »

Manishearth wrote: post #54
charles-salvia wrote: post #36

Earlier quoted context omitted.

When you need them you really need them. A Patricia Trie for example, which includes back pointers to ancestor nodes, is simply an ideal structure for prefix search.

How about a rephrasing: how many times do you really need to write these? Rust will make it tricky to implement these, but then you can use the datastructure safely as much as you want. It's a "write once use everywhere" thing.

Usually there's no good library that fits your use case. There's always subtle differences (to quote John Carmack)

Or it's really hard to find the good one amongst a hundred bad ones (to paraphrase ESR, when he tried Rust in all seriousness).

"Write once use everywhere" is wishful thinking, it's important to make adaptions (to paraphrase Knuth).

Re: Rust Sucks If I Fail to Write X

#64

Post by burntsushi »

jstimpfle wrote: post #61
ekidd wrote: post #10

Earlier quoted context omitted.

I think he means "unsafe" in the sense of Rust's 'unsafe' keyword, which allows you work with pointers just you normally would in C++. It doesn't mean all C++ is broken! Just that all C++ code has the right to use pointers or invoke undefined behavior without getting smacked down by the compiler.

He clearly states that code which depends on a linked list implementation is "unsafe" for that very reason. To me that's not convincing argumentation. If code depends on a broken "unsafe" linked list implementation, that's bad no matter what language the code is. What you say is true under some interpretation of "unsafe", but it doesn't relate with a broken "unsafe" linked list implementation. Btw. since I'm not a Ru…

The point the OP was trying to convey (and the OP could have been clearer) is that Rust will allow you to button up an unsafe core behind a completely safe interface. That is, no use of the safe interface could ever possibly lead to memory unsafety, and this is checked by the compiler.

A core value proposition of Rust is not necessarily that you will never need to utter `unsafe`, but rather, you can build safe abstractions on top of `unsafe`.

Re: Rust Sucks If I Fail to Write X

#65

Post by jstimpfle »

vvanders wrote: post #13
jstimpfle wrote: post #9

Earlier quoted context omitted.

SOA is the widely accepted approach to performance design. Not an argument vs C/C++, though.

Sure, but maybe 10% of C/C++ developers I've worked with over my career was actually aware of it :). I wasn't putting it out there as a dig against C/C++ but more a general comment on how rarely it's understood/appreciated in native code.

> I wasn't putting it out there as a dig against C/C++

It very much sounded like that.

Re: Rust Sucks If I Fail to Write X

#66

Post by Animats »

Manishearth wrote: post #56
Animats wrote: post #55

Earlier quoted context omitted.

All the other datastructures in the stdlib would still need unsafe. Why?

How would you implement the robin hood Hash{Set,Map} with this? Or BTreeMap? Maybe I misunderstood your proposal, at first it seemed like dependent types (which makes vectors awesome but really doesn't address other things), but your Pascal thing makes it sound more like complete formal verification, which is what Rustbelt is doing. I don't expect that to become part of the language (maybe? would be cool), but it wou…

Rustbelt is a research project, and they're using Coq, which is interactive and requires a lot of user effort. What I'm talking about is doing it within the language and automatically.

Looking at BTreeMap, the extensive use of unwrap_unchecked seems to be unnecessary. That looks like premature optimization - omitting the check saves maybe two instruction on the main path.

The other unsafe code there seems to mostly involve backpointers, which was covered above. "Drop" apparently is unsafe only for backpointer reasons, although the comments don't make this clear.

Re: Rust Sucks If I Fail to Write X

#67

Post by Animats »

comex wrote: post #60
Manishearth wrote: post #56

Earlier quoted context omitted.

How would you implement the robin hood Hash{Set,Map} with this? Or BTreeMap? Maybe I misunderstood your proposal, at first it seemed like dependent types (which makes vectors awesome but really doesn't address other things), but your Pascal thing makes it sound more like complete formal verification, which is what Rustbelt is doing. I don't expect that to become part of the language (maybe? would be cool), but it wou…

You can implement a hash map safely on top of an array; indeed you could do it with `Box ` today. You would just miss the optimization where missing buckets can be represented by zero in the "hash value" field rather than an explicit Option.

Doesn't Option() on a Rust pointer optimize down to a zero pointer value anyway?

Much of the unsafe Rust code I come across looks like either premature optimization or trying to write C in Rust.

Re: Rust Sucks If I Fail to Write X

#68

Post by jstimpfle »

burntsushi wrote: post #64
jstimpfle wrote: post #61

Earlier quoted context omitted.

He clearly states that code which depends on a linked list implementation is "unsafe" for that very reason. To me that's not convincing argumentation. If code depends on a broken "unsafe" linked list implementation, that's bad no matter what language the code is. What you say is true under some interpretation of "unsafe", but it doesn't relate with a broken "unsafe" linked list implementation. Btw. since I'm not a Ru…

The point the OP was trying to convey (and the OP could have been clearer) is that Rust will allow you to button up an unsafe core behind a completely safe interface. That is, no use of the safe interface could ever possibly lead to memory unsafety, and this is checked by the compiler. A core value proposition of Rust is not necessarily that you will never need to utter `unsafe`, but rather, you can build safe abstra…

That's not the reason why C/C++ code that uses a linked list is "unsafe". It's "unsafe" because it doesn't protect the use. In other words, because the client code is itself "unsafe". If the use was protected (whether dynamically with a lock or statically by some Rust-like language extension, I don't care), there was no more of an issue than in Rust.

And if the linked list is itself broken, Rust can't help you either.

So I still don't see a causal relationship. Is it because I'm drunk?

Re: Rust Sucks If I Fail to Write X

#69

Post by Manishearth »

Animats wrote: post #66
Manishearth wrote: post #56

Earlier quoted context omitted.

How would you implement the robin hood Hash{Set,Map} with this? Or BTreeMap? Maybe I misunderstood your proposal, at first it seemed like dependent types (which makes vectors awesome but really doesn't address other things), but your Pascal thing makes it sound more like complete formal verification, which is what Rustbelt is doing. I don't expect that to become part of the language (maybe? would be cool), but it wou…

Rustbelt is a research project, and they're using Coq, which is interactive and requires a lot of user effort. What I'm talking about is doing it within the language and automatically. Looking at BTreeMap, the extensive use of unwrap_unchecked seems to be unnecessary. That looks like premature optimization - omitting the check saves maybe two instruction on the main path. The other unsafe code there seems to mostly i…

> which was covered above

I don't really see how the backpointer thing could work, I find that it too will be limited, but I'm probably just wrong here.

> What I'm talking about is doing it within the language and automatically.

Once the language is verified, more user-friendly abstractions over the verification can be built.

Re: Rust Sucks If I Fail to Write X

#70

Post by Manishearth »

Animats wrote: post #67
comex wrote: post #60

Earlier quoted context omitted.

You can implement a hash map safely on top of an array; indeed you could do it with `Box ` today. You would just miss the optimization where missing buckets can be represented by zero in the "hash value" field rather than an explicit Option.

Doesn't Option() on a Rust pointer optimize down to a zero pointer value anyway? Much of the unsafe Rust code I come across looks like either premature optimization or trying to write C in Rust.

> Doesn't Option() on a Rust pointer optimize down to a zero pointer value anyway?

There aren't pointers here though.

But yes, you could use NonZero to mark the hash value as never-zero so that the option gets optimized. You'd still need unsafe code to construct the nonzero, but that's okay.

At least for the Hashmap I don't think the code is premature optimization; it seems to be pretty "idiomatic" unsafe Rust, with unsafe used exactly where needed. I haven't really looked at the btreemap in a while.

Post reply on HN