3 ms·

Do you find any issues with Rust that bothers you, as a former C++ developer? I'm still in my C++ days, but I avoid reinterpret_cast, as well as RTTI and C++ ex

Do you find any issues with Rust that bothers you, as a former C++ developer? I'm still in my C++ days, but I avoid reinterpret_cast, as well as RTTI and C++ exceptions. Looking forward trying out Rust.

Animats 5y ago
The biggest headache I've hit is that you can't have back references. When A owns B, it's really hard to get from B to A. You have to reference count everything, even if B is a field of A. A key concept in Rust is that no code can have access to two mutable references to the same object at the same time. That's the issue with std::launder, of course. The Rust mechanism for doing it enforces stronger restrictions than absolutely necessary. Not that enforcing the minimal set of restrictions is easy. The general argument of Rust enthusiasts is that you don't need that. But many of them are writing web back-end stuff, which does not have much state. I'm writing a client for a virtual world, which has an entire visible scene of constantly changing state. Representations for that sort of thing have extensive cross-links. Hammering that into the Rust model tends to result in things such as having to look up things in hashes where you'd use a direct link in C++. What's desirable is safe single ownership with backlinks. That's hard. You need something like a weak reference to a singly owned object, along with the compile time checking needed to prevent its misuse. Right now, you can do that with reference counted weak links, which are checked at run time. But you're often calling ".borrow()" to follow a link, and that will fail if the mutable borrow count becomes > 1. If that check could be replaced with static analysis by the borrow checker, more safe data structures would be possible. Trees with backlinks, doubly linked lists, etc. Not having this means you can reach the point where your program is one error away from compiling, and days of rewrite are needed to fix the problem. This is where unsafe code tends to sneak in, as an escape hatch.
- erwincoumans 5y ago
  I try to avoid circular references in C++ as well, at all cost, in my physics engines and game engines. For example, there is a unidirectional access from World -> Object -> Contact Point -> Vector3 and never the other way around (Vector3 doesn't know about Point, Object or World). Would Rust allow to have all data in 'structs' (no private data), and make all logic pure functional (functions without side effects, data in, data out)? That way, you won't need circular references or stateful objects and it simplifies memory management.
  - Animats 5y ago
    Some parts of the system map well to a purely functional model, and some don't. The part that decodes incoming messages is almost entirely functional. The part that maintains the scene graph isn't. There's a continual stream of update messages coming in, requests for assets go out, and assets come back. One asset reply may update many objects that use the same mesh or texture, so there's not the one-to-one relationship that an "async" model wants. Admittedly this is a somewhat unusual application. It's somewhere between writing an MMO client and a web browser. I once wrote a RSS feed reader in Rust, and that didn't have any of these hard problems.

Animats 5y ago

The biggest headache I've hit is that you can't have back references. When A owns B, it's really hard to get from B to A. You have to reference count everything, even if B is a field of A. A key concept in Rust is that no code can have access to two mutable references to the same object at the same time. That's the issue with std::launder, of course. The Rust mechanism for doing it enforces stronger restrictions than absolutely necessary. Not that enforcing the minimal set of restrictions is easy. The general argument of Rust enthusiasts is that you don't need that. But many of them are writing web back-end stuff, which does not have much state. I'm writing a client for a virtual world, which has an entire visible scene of constantly changing state. Representations for that sort of thing have extensive cross-links. Hammering that into the Rust model tends to result in things such as having to look up things in hashes where you'd use a direct link in C++. What's desirable is safe single ownership with backlinks. That's hard. You need something like a weak reference to a singly owned object, along with the compile time checking needed to prevent its misuse. Right now, you can do that with reference counted weak links, which are checked at run time. But you're often calling ".borrow()" to follow a link, and that will fail if the mutable borrow count becomes > 1. If that check could be replaced with static analysis by the borrow checker, more safe data structures would be possible. Trees with backlinks, doubly linked lists, etc. Not having this means you can reach the point where your program is one error away from compiling, and days of rewrite are needed to fix the problem. This is where unsafe code tends to sneak in, as an escape hatch.

erwincoumans 5y ago
I try to avoid circular references in C++ as well, at all cost, in my physics engines and game engines. For example, there is a unidirectional access from World -> Object -> Contact Point -> Vector3 and never the other way around (Vector3 doesn't know about Point, Object or World). Would Rust allow to have all data in 'structs' (no private data), and make all logic pure functional (functions without side effects, data in, data out)? That way, you won't need circular references or stateful objects and it simplifies memory management.
- Animats 5y ago
  Some parts of the system map well to a purely functional model, and some don't. The part that decodes incoming messages is almost entirely functional. The part that maintains the scene graph isn't. There's a continual stream of update messages coming in, requests for assets go out, and assets come back. One asset reply may update many objects that use the same mesh or texture, so there's not the one-to-one relationship that an "async" model wants. Admittedly this is a somewhat unusual application. It's somewhere between writing an MMO client and a web browser. I once wrote a RSS feed reader in Rust, and that didn't have any of these hard problems.