3 ms·

> you wonder why you wouldn't just write rust Because it is another language. If the researchers behind the borrow checker had implemented it on a safe variat

> you wonder why you wouldn't just write rust Because it is another language. If the researchers behind the borrow checker had implemented it on a safe variation of C/C++, then it would have been much easier to push for it in many companies. Something like the Python 2/3 split is better than another completely different language. Don’t get me wrong, Rust brings improvement in other areas too, which is fine, but when we are talking about many-million-LOCs, you don’t care that much. I am still waiting for someone to bring lifetime annotations to C and C++. Those I could use right away. Rust, not so much.

tgv 6y ago
But adding rust-like lifetime annotations to a many-million-LOC code base would result in totally bricking the code with 99.99999% certainty. I tried to port an (Earley) parser from C to Rust. It wasn't even a port, but more of a rewrite with similar function structure. The first part worked well, even though I had to resort to an arena (a special type of allocator that can guarantee lifetimes at the expense of freeing them later than strictly possible). Then I tried to get in shared parse trees. It was a nightmare. It could simply not be done with the same efficiency as in C. I had to resort to using array indices instead of pointers, or use ref counting where it wasn't needed. This had quite some impact on the calling functions. And that was a few hundred lines of plain, non-tricky C.
- jfkebwjsbx 6y ago
  If your C/C++ is sane, then your code was already written with lifetimes in mind and enforcing them is not a big deal. There will be places, no doubt, that you cannot do it, but if you can easily cover 80% of the code, that is way better than nothing and then you can work on redesigning the 20% (perhaps even rewriting it in another language since it has to be changed, for instance to Rust). Same argument as Rust uses for unsafe blocks. There have been specialized annotations for things like mutexes for a while in several projects which help static analyzers prove things too, so it is not new.
ma2rten 6y ago
Doesn't unique_ptr in C++ provide that?
- saagarjha 6y ago
  unique_ptr allows for use-after-move, so it's not perfect.

tgv 6y ago

But adding rust-like lifetime annotations to a many-million-LOC code base would result in totally bricking the code with 99.99999% certainty. I tried to port an (Earley) parser from C to Rust. It wasn't even a port, but more of a rewrite with similar function structure. The first part worked well, even though I had to resort to an arena (a special type of allocator that can guarantee lifetimes at the expense of freeing them later than strictly possible). Then I tried to get in shared parse trees. It was a nightmare. It could simply not be done with the same efficiency as in C. I had to resort to using array indices instead of pointers, or use ref counting where it wasn't needed. This had quite some impact on the calling functions. And that was a few hundred lines of plain, non-tricky C.

jfkebwjsbx 6y ago
If your C/C++ is sane, then your code was already written with lifetimes in mind and enforcing them is not a big deal. There will be places, no doubt, that you cannot do it, but if you can easily cover 80% of the code, that is way better than nothing and then you can work on redesigning the 20% (perhaps even rewriting it in another language since it has to be changed, for instance to Rust). Same argument as Rust uses for unsafe blocks. There have been specialized annotations for things like mutexes for a while in several projects which help static analyzers prove things too, so it is not new.

ma2rten 6y ago

Doesn't unique_ptr in C++ provide that?

saagarjha 6y ago
unique_ptr allows for use-after-move, so it's not perfect.