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

51–60 of 89 posts

Re: Rust Sucks If I Fail to Write X

#51

Post by Manishearth »

ianbertolacci wrote: post #24

I think this misses the problem. Should you write your own data-structures? Not unless absolutely necessary. But mostly everyone knows that. So why are people complaining about data-structures? For me, writing the data-structures is the canary in the mine. It's the next step from hello world when trying to pick up a new language. Most importantly, trying to write a few simple data-structures hints at the difficulty t…

> For me, writing the data-structures is the canary in the mine. It's the next step from hello world when trying to pick up a new language. Most importantly, trying to write a few simple data-structures hints at the difficulty that will be encountered writing a 'real' program.

You're missing the point of the post here, and drawing the exact correlation that the post is warning against.

Just because something is easy in C++ does not mean that it must be easy in other languages. In fact, writing good data structures in C++ is hard too (try writing an actually safe std::vector clone, it gets tricky), just that C++ will happily let you have an unsafe API; Rust will complain.

This is the old "grade the intelligence of a fish by its ability to climb a tree" problem. There is no intrinsic reason why the difficulty of writing datastructures should correlate with the difficulty of writing actual code. It is an easy task in C/C++, and thus it is often an early part of the learning experience.

Re: Rust Sucks If I Fail to Write X

#52

Post by Manishearth »

dbaupp wrote: post #50
Manishearth wrote: post #45

Earlier quoted context omitted.

> The checker needs a few simple theorems, such as "valid_array(A,0,n) and valid_element(A[n+1)) implies valid_array(A,0,n+1)" to check this. This is basically dependent types. Rust doesn't really want to go that far from a language level. > Handling these two classes of unsafe code takes care of a sizable fraction of the unsafe code really needed in Rust. Not really. All the other datastructures in the stdlib would…

> FWIW you can use Weak for this. There's a performance cost though. The sentence before your quote mentions ref-counting. This is referring to Weak.

Somehow missed that, thanks.

Re: Rust Sucks If I Fail to Write X

#53

Post by [deleted] »

dbaupp wrote: post #50
Manishearth wrote: post #45

Earlier quoted context omitted.

> The checker needs a few simple theorems, such as "valid_array(A,0,n) and valid_element(A[n+1)) implies valid_array(A,0,n+1)" to check this. This is basically dependent types. Rust doesn't really want to go that far from a language level. > Handling these two classes of unsafe code takes care of a sizable fraction of the unsafe code really needed in Rust. Not really. All the other datastructures in the stdlib would…

> FWIW you can use Weak for this. There's a performance cost though. The sentence before your quote mentions ref-counting. This is referring to Weak.

[deleted]

Re: Rust Sucks If I Fail to Write X

#54

Post by Manishearth »

charles-salvia wrote: post #36
vvanders wrote: post #26

Earlier quoted context omitted.

How often do you really need those interesting structures(and the memory fragmentation that comes with them)? I've seen countless times where a developer reached for std::hash_map/linked_list when there will never be more than 10 values in their dataset. In that case an array would be at least as fast and much easier on your data layout. Also if you're trying to implement lockfree data structures then safe/unsafe poi…

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.

Re: Rust Sucks If I Fail to Write X

#55

Post by Animats »

Manishearth wrote: post #45
Animats wrote: post #33

You can do linear lists and trees in Rust. The problem is backlinks. If you refcount everything, you can have backlinks, but otherwise there's a safety problem. Backlinks require an invariant which covers two variables, and you can't express that in Rust. Back pointers are a special sort of pointer from an ownership perspective. They don't carry ownership, but are locked in an invariant relationship with the pointer…

> The checker needs a few simple theorems, such as "valid_array(A,0,n) and valid_element(A[n+1)) implies valid_array(A,0,n+1)" to check this. This is basically dependent types. Rust doesn't really want to go that far from a language level. > Handling these two classes of unsafe code takes care of a sizable fraction of the unsafe code really needed in Rust. Not really. All the other datastructures in the stdlib would…

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

Why?

Re: Rust Sucks If I Fail to Write X

#56

Post by Manishearth »

Animats wrote: post #55
Manishearth wrote: post #45

Earlier quoted context omitted.

> The checker needs a few simple theorems, such as "valid_array(A,0,n) and valid_element(A[n+1)) implies valid_array(A,0,n+1)" to check this. This is basically dependent types. Rust doesn't really want to go that far from a language level. > Handling these two classes of unsafe code takes care of a sizable fraction of the unsafe code really needed in Rust. Not really. All the other datastructures in the stdlib would…

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 would help reason about unsafe code.

Re: Rust Sucks If I Fail to Write X

#57

Post by andrewflnr »

ianbertolacci wrote: post #24

I think this misses the problem. Should you write your own data-structures? Not unless absolutely necessary. But mostly everyone knows that. So why are people complaining about data-structures? For me, writing the data-structures is the canary in the mine. It's the next step from hello world when trying to pick up a new language. Most importantly, trying to write a few simple data-structures hints at the difficulty t…

If it's really not about data structures, then pick a different canary. A more accurate one. That's basically all we're asking.

Re: Rust Sucks If I Fail to Write X

#58

Post by klodolph »

Let's get this out of the way: Rust is great. Rust apologia like this article is not so great.

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

There's a bit of mental gymnastics going on here. The word "unsafe" is performing double duty, since it means "memory safety not guaranteed by the compiler" in Rust and it means something else entirely when you are talking about C++, since memory safety was never guaranteed by the compiler in the first place. The other problem with this statement is that linked lists in C or C++ aren’t really that hard to get right, in fact, they’re easy. Maybe you draw out a diagram on pen and paper before you write the code, but you’re unlikely to be facing segfaults.

I admit I’m biased here, because I’ve been using Haskell for something like 15 years now, but I feel like the Haskell community acknowledges that Haskell’s type system gets in the way and prevents you from doing useful, interesting work, and that even a great library ecosystem isn’t enough to overcome this. That’s how safety generally works. It’s harder to write programs that do useful things, but in exchange, it’s also harder to write programs that behave unpredictably or do dangerous things. Because Rust and Haskell put you in such restrictive type systems, sometimes you have to break out to get real work done.

Haskell’s pitch, in my mind, is, “Let’s make it easy to reason about side effects and value semantics.” From the article, Rust’s pitch could be, “Let’s make it easy to reason about control- and data flow.” These are both evolutionary steps in the development of programming languages, all programming languages being somewhat flawed. Future languages will steal ideas from Rust the same way modern languages have stolen ideas from Haskell.

But apologia still leaves a bad taste in my mouth. The article says, “Is this a problem with Rust? Not at all.” There’s a worrying unwillingness to acknowledge that Rust is flawed, and the article describes Rust users as “Rustaceans” and makes broad generalizations about how they behave. This reminds me of the excesses of 2000s-era object-oriented programming. The comment about “Rust’s facilities for code reuse” could have been taken straight out of a press release for Java back in the late 1990s for all I know.

Rust is great, but this article is further cementing my distaste for the Rust community.

By comparison, here is Simon Peyton Jones talking about how Haskell is useless: https://www.youtube.com/watch?v=iSmkqocn0oQ

Re: Rust Sucks If I Fail to Write X

#59

Post by comex »

It's interesting what this issue reveals about Rust culture.

After all, you can write basic (tree-like) data structures without resorting to `unsafe`. It's not that hard: just wrap all your nodes in `Rc`, plus either `RefCell` or `Cell` if you need mutability. Yeah, this adds some overhead, but really not very much. It'll probably still run faster than equivalent code in most safe languages, often using less memory, without GC pauses. Or even if it loses to some language in some tree microbenchmark, in a real application Rust will probably make up for it with better performance elsewhere.

But culturally, the baseline for comparison isn't safe languages. It's C/C++. Rust is supposed to be about zero cost abstractions, so non-zero-cost abstractions are suspect. And so people recommend raw pointers and `unsafe` - which is no less safe than C++, but still leaves newcomers with a bad taste in their mouths.

To some extent this attitude is built into the language itself. `Rc>` is ugly; needing two nested generics, one with a rather abstruse name, for what in other languages is just `Foo`, i.e. a basic object reference, makes you feel like you're doing something wrong. In the olden days of Rust, `RefCell` was called `Mut`, and there was a type `RcMut` which combined `Rc` and `Mut`. Much more appealing to a newbie: `Mut` is what you use to add (inner) mutability, and `RcMut` is the mutable version of `Rc`, for the common case where you need both reference counting and mutability. No need for ugly nesting. But well before 1.0, `Mut` was renamed and `RcMut` deemed unnecessary, and Rust ended up where it is today. Arguably this is a good thing, as it discourages unnecessary use of both reference counting and inner mutability, each of which comes with a runtime cost. But for newbies, I think it makes Rust look more intimidating than it needs to be.

Re: Rust Sucks If I Fail to Write X

#60

Post by comex »

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…

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.
Post reply on HN