It's (mildly) concerning how the answer to complicated ownership situations is (sometimes) to defeat the borrow checker by reimplementing a pointer system that the borrow checker can't check.
Why? Sometimes you don't know how ahead of time how many references to a thing your program will need.
For example, consider a program that reads in a git fast-import stream. The first commit creates a file named README.txt. How many more commits will touch the same path? You’ve no idea, of course, but it could be hundreds of thousands. Do you want hundreds of thousands of individual strings all containing that same filename? That would be fine in the first draft of your program, but in the long term it is too big of a cost to pay (believe me, I know). So you want some kind of pool to store filenames. It could be a grow-only arena, so that you can use plain references, or a mutable pool using reference counting (Arc obviously).
Rust gives you the power to start writing your program using ordinary strings for filenames (or OsStr, obviously), and then later graduate to something both more complicated and more efficient just by swapping out the implementation of one type.
Yes, but that’s a heavyweight solution that you don’t always need. Notice that in my example problem an arena that only ever grows can use ordinary references. You don’t need any kind of handle type in that case.
And if you are manipulating real graphs that can grow and shrink and you reach for handles as a solution then you’ve introduced that kind of problem in a controlled setting. Rust also gives you the tools to minimize the risks. In practice this rarely comes up, unlike in C where use-after-free bugs are endemic.
It's (mildly) concerning how the answer to complicated ownership situations is (sometimes) to defeat the borrow checker by reimplementing a pointer system that the borrow checker can't check.
Why? Sometimes you don't know how ahead of time how many references to a thing your program will need.
For example, consider a program that reads in a git fast-import stream. The first commit creates a file named README.txt. How many more commits will touch the same path? You’ve no idea, of course, but it could be hundreds of thousands. Do you want hundreds of thousands of individual strings all containing that same filename? That would be fine in the first draft of your program, but in the long term it is too big of a cost to pay (believe me, I know). So you want some kind of pool to store filenames. It could be a grow-only arena, so that you can use plain references, or a mutable pool using reference counting (Arc obviously).
Rust gives you the power to start writing your program using ordinary strings for filenames (or OsStr, obviously), and then later graduate to something both more complicated and more efficient just by swapping out the implementation of one type.
The article talks about using handles, which reintroduce all the same use-after-free issues that the borrow checker is claimed to solve.
Yes, but that’s a heavyweight solution that you don’t always need. Notice that in my example problem an arena that only ever grows can use ordinary references. You don’t need any kind of handle type in that case.
And if you are manipulating real graphs that can grow and shrink and you reach for handles as a solution then you’ve introduced that kind of problem in a controlled setting. Rust also gives you the tools to minimize the risks. In practice this rarely comes up, unlike in C where use-after-free bugs are endemic.
You appear to be arguing about something I didn't say; feel free to continue, but I'm going elsewhere now, cheers.
Or just use C++
Ha... I'll confess "don't use Rust" was my immediate reaction.
Skill issue.
Gottem