Kyren

I've tried Rust before. in the end I concluded that I don't really need it over C++ for the following reasons:

- I tend to store references to other objects using indices instead of pointers/references anyway, so the borrow checker isn't really that important for me. Memory errors that comes from indexing can be caught with runtime assertions, or if you can't use assertions because of performance constraints you can still use sanitizers to debug these issues. (You're probably going to run sanitizers even in Rust anyway if you are using unchecked array indexing...) Further use-after-free errors that come up with reusing indices in an object pool can be caught at runtime using the generational index trick. (See https://kyren.github.io/2018/09/14/rustconf-talk.html for the gist of what I'm talking about. The presenter listed this as a reason why Rust is good because the compiler nudges you circumvent the borrow checker to design better code, but for me this was actually a reason why Rust doesn't actually help that much at all: I don't need the guidance of the borrow checker to have this decision in the first place! She's actually giving a reason for why the borrow checker is useless!)

- Also, Rust's compile-time facilities are still not as powerful as C++'s. For example in Rust you can't still do operations with integers in generics in compile time, you need to wait that until the full version of const generics. (This is important if you want to make a convenient math/linear…

Still, inside that copy constructor you're going to write the exact boilerplate code for recursively copying each node, so the complexity of code won't change that much. Also, you're going to call quite a lot of malloc/free, which could be a potential performance hit if you're creating/destroying large trees a lot, as well as fragmenting your memory if you're not careful.

Personally I have a much easier time dealing with tree/graph data structures using indices, regardless of the language I'm using. Using indices as handles in general are just so much easier than using pointers in terms of memory management, and generally performs much better in terms of cache coherency. Indices are also easier to serialize/deserialize, and sometimes it just "makes sense" (for example, if you're developing a physics simulation, representing objects as indices are natural because you're going to use those index values inside various math equations.)

The downside might be that if you're creating and destroying nodes in a tree continuously. then you have to be careful about reusing indices. There's a pattern in gamedev (generational indices) that solve the issue (basically, in addition to an index you also store a counter value with it, and you increment the counter everytime you allocate a new node in the same spot of the array. It's a bit more bookkeeping, but there's lots of code examples for it. It's kind of a well-known trick inside gamedev (and recently in the Rust community, in order…

I've been programming in C and C++ since sometime around 1992 (and Pascal before that). For the last 3 years, I've been writing Rust professionally.

Here's my Rust advice for C and C++ programmers:

- Rust is a higher-level language than C. A C/C++ programmer could think of Rust as "C++ without most of the footguns and magic."

- Certain types of C/C++ code will translate very easily to Rust. For example, if your code mostly transforms bytes (or data structures) into other bytes (or data structures), then Rust will usually be fairly easy to learn. We could call this "mostly functional" C code, with only localized mutability, and with clear, hierarchical data structures. Examples: Most typical Unix CLI tools.

- Certain kinds of C and C++ will translate very badly to Rust. If you have a big web of mutable objects, all of which point to each other and update each other, then your first experience of Rust will probably be frustrating. Examples: doubly-linked lists, traditional GUIs, typical video games. You can do all these things in Rust, but you'll need to either re-architect them or use more advanced features. (See http://cglab.ca/~abeinges/blah/too-many-lists/book/ for doubly-linked lists, or https://kyren.github.io/2018/09/14/rustconf-talk.html for video games.)

- Async Rust is not ready for prime-time. We make limited use of async Rust at work. It's rock-solid and powerful, but it's missing critical ergonomic features and it demands a surprisingly high level of Rust…

I think that we are subtly talking past each other, because what you're saying doesn't line up against what I thought I was saying. I'm not looking for additional type safety or security protections from this model. See my sibling comment to your earlier comment for a little more context [1].

As someone who works with Rust often, your assertions don't match my experience. I want to engage honestly and understand where Rust itself falters, versus where we need to invest in educating newcomers about what kinds of models are better represented in Rust than others. I have found the model I'm describing to be valuable in many ways -- more than a "hack" to get around Rust.

> And of course the extra indirection is costly, especially for a systems language.

To my knowledge, base-offset addressing is natively present on at least x86. With a vector-based index space like I was describing, a[b] == * (a + b) is no more costly than * b. If you would need a more complex index space, you were probably doing more than bare pointers already.

> And you're also doing much more memory management.

> because such hacks turn a simple logical operation into a series of multiple memory allocations

No, no more than you would have needed with pointer-based naming. The top-level arena (a vector in the graph example) owns everything and can be deallocated all at once when you're done with it. Arenas were already a well-known pattern before Rust, and they can reduce the amount of manual memory…

I would even take your learnings from your experience a step further and say that one should be proactive in talking to teammates and exploring ideas on how to improve the codebase if you think there is room for improvement. For instance, it may well be that inheritance is the wrong pattern for that given codebase, but there are indications that the current architecture isn't scalable.

With more investment, more research could have been put into looking at better suited architectures such as the Entity Component System architecture, where Entities such as Rects and Ellipsis are composed of units of functionality (position, resizability, etc), which is a proven architecture for this sort of application. Then, implementation would be a matter of getting team buy-in / weighing the refactor pros and cons with your team.

Tangential, but Entity Component Systems are a great way to structure systems with many types of entities that share subsets of functionalities.
https://kyren.github.io/2018/09/14/rustconf-talk.html.

"As the compiler will stop you from borrow checking or something unsafe again and again, you are being distracted constantly by focusing on the language itself instead of the problem you are solving. I know the friction is greater because I am still a Rust learner, not a veteran, but I think this experience stops a lot of new comers, speaking as someone who already conquered the uncomfortable syntax of Rust, coming from a C/C++ background."

To be honest, this article seems somewhat ingenuous. The author wasn't comfortable with Rust, and it seems like he missed the point of the borrow checker. This article will now be circulated whenever Rust is discussed.

Here is a good article that arrives at the opposite conclusion:
https://kyren.github.io/2018/09/14/rustconf-talk.html

I've been writing Rust full time for the last month and a half or so and the language is a joy to use. The main difference is that the code I write feels very sturdy and permanent. I've heard other people say the same thing.