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

21–30 of 89 posts

Re: Rust Sucks If I Fail to Write X

#21

Post by sidlls »

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.

That may be technically true but in practice and rhetoric "unsafe" is often used in contexts with much broader, implicit connotations. For example, putting Rust-compiler-proven-safety as the top, first, or best feature to consider. In that context, saying "C++ isn't Rust-safe" is essentially defining Rust to be "better", not advancing a coherent argument that it is in fact better.

Re: Rust Sucks If I Fail to Write X

#22

Post by ThatGeoGuy »

vvanders wrote: post #2

> Rustaceans usually opt for continuous data layout (known in C/C++ lingua as array-of-struct or struct-of-array depending on priorities), which is more cache-friendly than reference-heavy data structures anyway. Yes! This is a point that I try to hammer home that's missed by many people who write C/C++ on a daily basis. Everyone wants to use the fanciest data structures when most of the times arrays will be faster a…

> Everyone wants to use the fanciest data structures when most of the times arrays will be faster and simpler to use.

I'm not sure I comprehend this, since I don't often encounter code where people use advanced data structures to do simple things. For most collections, you're typically talking about an array of some kind, since you just want to iterate through many objects doing the same thing. However, there is a reason for more complex data structures to exist. KDTrees, for example, are great for performing nearest-neighbour search, and I can't see any situation where I'd want to use a straight array if I knew I was doing nearest-neighbour searches.

In the most broad, general case I agree: array-of-struct or struct-of-arrays is probably the way to go. You can even see this in the data science world where data frames (effectively struct-of-arrays) are the tool of the trade. However, there are algorithms where if you want an advanced data structure, you really want it (e.g. KDTree). Is it really so common in systems programming to see people trying to incorporate all sorts of magic from The Art of Computer Programming into their programs? I can't say I've ever seen it myself (obvious disclaimer that while I'm a programmer by trade I don't read too many large Rust / C++ projects).

Re: Rust Sucks If I Fail to Write X

#23

Post by msbarnett »

charles-salvia wrote: post #17
vvanders wrote: post #2

> Rustaceans usually opt for continuous data layout (known in C/C++ lingua as array-of-struct or struct-of-array depending on priorities), which is more cache-friendly than reference-heavy data structures anyway. Yes! This is a point that I try to hammer home that's missed by many people who write C/C++ on a daily basis. Everyone wants to use the fanciest data structures when most of the times arrays will be faster a…

C++ programmers usually prefer contiguous data layout as well. I mean std::vector is just a contiguous array that dynamically reallocates and copies/move-constructs everything as needed. But many interesting data structures are hard to write in a memory-efficient manner without resorting to non-contiguous nodes. Even a hashtable often will use linked lists within each bucket for collision resolution. You can argue th…

> All in all, it remains true that Rust doesn't really provide any safety above C++ in regard to writing these kinds of node-based data structures

Debatable. It certainly does for the consumers of these structures, and data structures are consumed a lot more often than they are rewritten.

> Yes, Rust has some downsides and tradeoffs. Is it so bad to just say that out loud?

Of course not. But that doesn't mean you shouldn't expect some pushback if you're incorrectly describing those tradeoffs.

Is it really so bad to say "at the end of the day, the difficulty of complex graphs in safe Rust is symptomatic not of a flaw in Rust but of how hard it is to build these things without memory errors even in C or C++" out loud?

Re: Rust Sucks If I Fail to Write X

#24

Post by ianbertolacci »

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 that will be encountered writing a 'real' program.

For people like me, if writing trivial data-structures in Rust is a great challenge, it shows that writing other, less trivial things in Rust will be much more challenging than might be preferred.

Hand waving the comment "writing data-structures in Rust is hard" with "well you shouldn't be doing that anyway" misses, I think, the point that Rust (while very neat) is generally a difficult language to pick-up.

[Edit]

Again, the issue isn't data-structures or about them.

The issue is: Can I write something in scratch in this language 1) at all and 2) with some amount of daily progress.

Writing data-structures is a test case of my ability to thing and program in the context of Rust. It serves to answer the question: Can I write a program that implements a well defined, well understood construct so that I may learn the building blocks of rust?

This leads up to an application, the behavior and design of which may not be extremely well defined in the context of Rust and requires more thinking when working out the data-structure in rust.

If the answer to "can I write a data-structure in Rust" is "Ya totally got this makes sense" then writing an application will be relatively easy.

However if the answer is "Wow I did it but there were a lot of pain points and I still have no idea if I've done it in the right or canonical way" then writing an application is going to be very difficult.

Re: Rust Sucks If I Fail to Write X

#25

Post by ekidd »

charles-salvia wrote: post #17
vvanders wrote: post #2

> Rustaceans usually opt for continuous data layout (known in C/C++ lingua as array-of-struct or struct-of-array depending on priorities), which is more cache-friendly than reference-heavy data structures anyway. Yes! This is a point that I try to hammer home that's missed by many people who write C/C++ on a daily basis. Everyone wants to use the fanciest data structures when most of the times arrays will be faster a…

C++ programmers usually prefer contiguous data layout as well. I mean std::vector is just a contiguous array that dynamically reallocates and copies/move-constructs everything as needed. But many interesting data structures are hard to write in a memory-efficient manner without resorting to non-contiguous nodes. Even a hashtable often will use linked lists within each bucket for collision resolution. You can argue th…

> All in all, it remains true that Rust doesn't really provide any safety above C++ in regard to writing these kinds of node-based data structures,

Yup! Rust does not fix all your problems, sadly. Maybe some of them. :-)

If you're working with graph-like structures in Rust, then you have two choices:

1. You can work with pointers using 'unsafe' blocks, and then wrap everything inside a nice, safe API. This is a good tradeoff if your data structure is only a tiny portion of your code, or if it's reusable. (Most of the data structures in Rust's 'std' crate are written like this.)

2. You can work with indices instead of pointers. This is the approach taken by petgraph (https://docs.rs/petgraph/0.4.3/petgraph/), which is currently one of the best graph libraries for Rust.

Not all Rust code needs to be safe. It's OK to write "unsafe" code and put it behind a "safe" API. If I can eliminate 98% of the opportunities for pointer bugs, I'm happy to eyeball the remaining 2% manually.

Re: Rust Sucks If I Fail to Write X

#26

Post by vvanders »

charles-salvia wrote: post #17
vvanders wrote: post #2

> Rustaceans usually opt for continuous data layout (known in C/C++ lingua as array-of-struct or struct-of-array depending on priorities), which is more cache-friendly than reference-heavy data structures anyway. Yes! This is a point that I try to hammer home that's missed by many people who write C/C++ on a daily basis. Everyone wants to use the fanciest data structures when most of the times arrays will be faster a…

C++ programmers usually prefer contiguous data layout as well. I mean std::vector is just a contiguous array that dynamically reallocates and copies/move-constructs everything as needed. But many interesting data structures are hard to write in a memory-efficient manner without resorting to non-contiguous nodes. Even a hashtable often will use linked lists within each bucket for collision resolution. You can argue th…

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 pointer access are going to be the least of your worries :).

Re: Rust Sucks If I Fail to Write X

#27

Post by oconnor663 »

ekidd wrote: post #7

In my programming experience, there are two kinds of code: 1. Code where my objects form a tree. Rust's ownership model is great for this. 95% of my code looks this way naturally, and maybe another 3% can be rewritten to look like this. 2. Code where my objects form a complex graph. At this point, I need to make a choice between manual pointer management (C++, unsafe Rust) and a garbage collector (lots of languages).…

The off-the-shelf standard library solutions to #2 are Rc> (single threaded) and Arc> (multi-threaded). Those aren't super high performance, and they're a little verbose, but they usually satisfy the borrow checker.

Re: Rust Sucks If I Fail to Write X

#29

Post by webkike »

charles-salvia wrote: post #20
webkike wrote: post #18

Earlier quoted context omitted.

Well when most people ask for a linked list my first response would be "why?"

an LRU cache?

I'm not saying there aren't reasons to use link lists, but often the correct approach is a hybrid one and additionally for cache aware programs a vector of entries with indirection integers is going to be more local

Re: Rust Sucks If I Fail to Write X

#30

Post by vvanders »

ThatGeoGuy wrote: post #22
vvanders wrote: post #2

> Rustaceans usually opt for continuous data layout (known in C/C++ lingua as array-of-struct or struct-of-array depending on priorities), which is more cache-friendly than reference-heavy data structures anyway. Yes! This is a point that I try to hammer home that's missed by many people who write C/C++ on a daily basis. Everyone wants to use the fanciest data structures when most of the times arrays will be faster a…

> Everyone wants to use the fanciest data structures when most of the times arrays will be faster and simpler to use. I'm not sure I comprehend this, since I don't often encounter code where people use advanced data structures to do simple things. For most collections, you're typically talking about an array of some kind, since you just want to iterate through many objects doing the same thing. However, there is a re…

Guess how every Quad/KDTree I've seen has been implemented(I've seen 3 in high-perf domains)?

SoA + indices, because locality of the search is critical and you want explicit control over the layout.

Post reply on HN