4 ms·

> Rust makes it nearly impossible to accomplish. No it doesn't. It's literally adding one extra simple function to a library. > Not necessarily. Well-perform

> Rust makes it nearly impossible to accomplish. No it doesn't. It's literally adding one extra simple function to a library. > Not necessarily. Well-performing safety is hard, then. Safety is hard in C++ and Rust, less so in C#. Yes, it is easier to write a linked list in C++, but ensuring it is used safely is hard. > Can’t in Rust, because the library designers (not just std, the rest of them as well) think I better have my own implementation if I need that level of control. Right, and that is solely a library issue. Rust doesn't prohibit having composable unsafe libraries either. The ecosystem just hasn't produced those yet, because people probably didn't need it yet; and it is mostly preferred for libraries to keep the unsafety encapsulated inside behind a safe abstraction.

Const-me 10y ago
> It's literally adding one extra simple function to a library. No function will transfer ownership of N nodes to the new container for O(1) complexity. And if you’ll refactor the list to reference counted nodes, you’ll introduce costs to traversal. > it is easier to write a linked list in C++ And a tree. And a graph. Trees / graphs structures and algorithms are everywhere, too bad Rust language designers forgot that. > Rust doesn't prohibit having composable unsafe libraries either. Does not prohibit but makes it hard, because Rust’s primary design goal was that safety thing.
- Manishearth 10y ago
  > No function will transfer ownership of N nodes to the new container for O(1) complexity. No safe function. It is easy to do with unsafe. This has been explained already. > And a tree. And a graph. Trees / graphs structures and algorithms are everywhere, too bad Rust language designers forgot that. Rust's designers are mainly from the C++ world. They know this. And we have seen tons of these datastructures crop up that are written in Rust code everywhere. The idea is that you find a safe abstraction boundary for you low level data structure, and stick to it. For an LRU cache, the boundary is the LRU cache (not the internal linked list, which needs to be accessed using `unsafe`). The stdlib exposes a linked list that can be used standalone, but as part of a larger unsafe datastructure you should copy it out and integrate directly to get finer grained unsafe access.
  - Const-me 10y ago
    Sure, they wanted a safe language. What they actually did, they created a language where data is a second-class citizen. The strategy “find a safe abstraction boundary for you low level data structure, and stick to it” works well for a scripting language. Or for high-level code that’s not performance-critical, like business logic. It doesn’t work well for a general-purpose language that’s used for algorithms-heavy performance critical tasks. There’s no “low level data structures”, because data structures are all the way down, and composed all the way down. Very often I need unsafe things at my API boundaries, because performance or because interop. I can’t implement my data structures once and stick to them, because as I work on the project I change both code and data structures (the main input here is profiler). That safety thing makes data structures impractical. As you see from my linked list example, they are hard to create, use, and compose. BTW, graphs (including trees and lists) are just one example how pointers are useful in data structures. Here’s another one. In C++, I can add an index to a collection using unordered_map<tKey, Value*>. This index allows constant-time lookups, and if the tKey is something small like an int, the RAM cost is very low, because only keys + pointers are stored in the hash map, not the values themselves. If I’ll want to do same in Rust, I suppose you’ll tell me I need to copy-paste the collection source code and add index there, because what’s in stdlib ain’t composable the way I want :-)

Const-me 10y ago

> It's literally adding one extra simple function to a library. No function will transfer ownership of N nodes to the new container for O(1) complexity. And if you’ll refactor the list to reference counted nodes, you’ll introduce costs to traversal. > it is easier to write a linked list in C++ And a tree. And a graph. Trees / graphs structures and algorithms are everywhere, too bad Rust language designers forgot that. > Rust doesn't prohibit having composable unsafe libraries either. Does not prohibit but makes it hard, because Rust’s primary design goal was that safety thing.

Manishearth 10y ago
> No function will transfer ownership of N nodes to the new container for O(1) complexity. No safe function. It is easy to do with unsafe. This has been explained already. > And a tree. And a graph. Trees / graphs structures and algorithms are everywhere, too bad Rust language designers forgot that. Rust's designers are mainly from the C++ world. They know this. And we have seen tons of these datastructures crop up that are written in Rust code everywhere. The idea is that you find a safe abstraction boundary for you low level data structure, and stick to it. For an LRU cache, the boundary is the LRU cache (not the internal linked list, which needs to be accessed using `unsafe`). The stdlib exposes a linked list that can be used standalone, but as part of a larger unsafe datastructure you should copy it out and integrate directly to get finer grained unsafe access.
- Const-me 10y ago
  Sure, they wanted a safe language. What they actually did, they created a language where data is a second-class citizen. The strategy “find a safe abstraction boundary for you low level data structure, and stick to it” works well for a scripting language. Or for high-level code that’s not performance-critical, like business logic. It doesn’t work well for a general-purpose language that’s used for algorithms-heavy performance critical tasks. There’s no “low level data structures”, because data structures are all the way down, and composed all the way down. Very often I need unsafe things at my API boundaries, because performance or because interop. I can’t implement my data structures once and stick to them, because as I work on the project I change both code and data structures (the main input here is profiler). That safety thing makes data structures impractical. As you see from my linked list example, they are hard to create, use, and compose. BTW, graphs (including trees and lists) are just one example how pointers are useful in data structures. Here’s another one. In C++, I can add an index to a collection using unordered_map<tKey, Value*>. This index allows constant-time lookups, and if the tKey is something small like an int, the RAM cost is very low, because only keys + pointers are stored in the hash map, not the values themselves. If I’ll want to do same in Rust, I suppose you’ll tell me I need to copy-paste the collection source code and add index there, because what’s in stdlib ain’t composable the way I want :-)