5 ms·

So it’s the difference between crash early (C) and don’t crash but run wrong (Rust), inherent by design in the main selling point of Rust (borrow checker)?

Tuna-Fish 8y ago
No. Most modern C++ ECS take the same approach as the Rust ECS that is being discussed. Also, since I started using generational indexes, I have never had a bug caused by using stale data, so at least for me it hasn't been a real issue.
andrewflnr 8y ago
Broadly speaking, C is the king of running wrong without crashing, so no. The borrow checker isn't really making anything worse, it's just failing to save you from this particular problem. In C you could still write the exact same bug, or you could even write it with actual pointers. I gather a lot of browser exploits start that way these days.
gliptic 8y ago
Why is everyone assuming C is "crash early" as opposed to "undefined behaviour will crash if you're lucky and cause RCE in the worst case, or any weird thing in between". The selling point of the borrow checker (at least one of them) is that it doesn't allow undefined behaviour unless you explicitly enable unsafe operations. If there was a way to detect UB and predictably crash in a performant way, you could probably implement that in Rust as well. In fact, that's often what is done with generational indexes and similar.
- shawn 8y ago
  https://doc.rust-lang.org/nomicon/print.html https://doc.rust-lang.org/nomicon/print.html Rust is otherwise quite permissive with respect to other dubious operations. Rust considers it "safe" to: Deadlock Have a race condition Leak memory Fail to call destructors Overflow integers Abort the program Delete the production database However any program that actually manages to do such a thing is probably incorrect. Rust provides lots of tools to make these things rare, but these problems are considered impractical to categorically prevent.
  - dx87 8y ago
    None of those are related to anything in the post you're replying to. What point are you trying to make?
ummonk 8y ago
I believe the example here is where you bypass the borrow checker by keeping your own pool of memory and then allocating objects on that pool, using a custom heap implementation with manual memory management (or with a custom garbage collector). You can do that in either C or Rust (or any other language for that matter).
gpm 8y ago
I'd say that rust crashes early in a strict superset of when C crashes early. The case where rust fails to crash early is you have are using indexes into an array as a pseudo pointer, but you've "freed" the object you wanted to use and put another (of the exact same type) in it's place. If you do the same with malloc/free in C you also aren't going to crash early. But in C you can also fail to crash early because of things like "and now an object of a different type is in it's place".
tree_of_item 8y ago
I don't see what there is about C that forces things to crash early. It's more like the difference between full of bugs that no one sees (C), and get the problem with your approach highlighted by the type system (Rust).

Tuna-Fish 8y ago

No. Most modern C++ ECS take the same approach as the Rust ECS that is being discussed. Also, since I started using generational indexes, I have never had a bug caused by using stale data, so at least for me it hasn't been a real issue.

andrewflnr 8y ago

Broadly speaking, C is the king of running wrong without crashing, so no. The borrow checker isn't really making anything worse, it's just failing to save you from this particular problem. In C you could still write the exact same bug, or you could even write it with actual pointers. I gather a lot of browser exploits start that way these days.

gliptic 8y ago

Why is everyone assuming C is "crash early" as opposed to "undefined behaviour will crash if you're lucky and cause RCE in the worst case, or any weird thing in between". The selling point of the borrow checker (at least one of them) is that it doesn't allow undefined behaviour unless you explicitly enable unsafe operations. If there was a way to detect UB and predictably crash in a performant way, you could probably implement that in Rust as well. In fact, that's often what is done with generational indexes and similar.

shawn 8y ago
https://doc.rust-lang.org/nomicon/print.html https://doc.rust-lang.org/nomicon/print.html Rust is otherwise quite permissive with respect to other dubious operations. Rust considers it "safe" to: Deadlock Have a race condition Leak memory Fail to call destructors Overflow integers Abort the program Delete the production database However any program that actually manages to do such a thing is probably incorrect. Rust provides lots of tools to make these things rare, but these problems are considered impractical to categorically prevent.
- dx87 8y ago
  None of those are related to anything in the post you're replying to. What point are you trying to make?

ummonk 8y ago

I believe the example here is where you bypass the borrow checker by keeping your own pool of memory and then allocating objects on that pool, using a custom heap implementation with manual memory management (or with a custom garbage collector). You can do that in either C or Rust (or any other language for that matter).

gpm 8y ago

I'd say that rust crashes early in a strict superset of when C crashes early. The case where rust fails to crash early is you have are using indexes into an array as a pseudo pointer, but you've "freed" the object you wanted to use and put another (of the exact same type) in it's place. If you do the same with malloc/free in C you also aren't going to crash early. But in C you can also fail to crash early because of things like "and now an object of a different type is in it's place".

tree_of_item 8y ago

I don't see what there is about C that forces things to crash early. It's more like the difference between full of bugs that no one sees (C), and get the problem with your approach highlighted by the type system (Rust).