4 ms·

> Anyone writing these things today in C or C++ already understands object lifetimes and Rust just adds a static checker for them. I've certainly seen seasoned

by twic 3y ago

> Anyone writing these things today in C or C++ already understands object lifetimes and Rust just adds a static checker for them. I've certainly seen seasoned C++ programmers saying this. Of course, a few of them of say they understand object lifetimes so well, they they don't need the static checker! > Why on earth would you try to rewrite python CRUD apps in Rust? This is one of the great mysteries of our times. I do think the enthusiasm for using Rust for web apps and such (a) is misplaced and (b) has been a drag on Rust developing into a better C++ replacement.

bluGill 3y ago
> Of course, a few of them of say they understand object lifetimes so well, they they don't need the static checker! There is a difference between understanding lifetimes and being able to keep track of them. I have a lot of objects in my more than 10 million lines of code. Most of them have simple lifetimes that are easy to track, but a few for reasons (which may or may not be valid - often the reasons are it was built in C++98 and updating to modern lifetimes is hard when it is used all over) have complex lifetimes that are tedious to track. It isn't that I can't, it is that I get bored/make mistakes and the static analyzer wouldn't (Or course C++ can't be statically analyzed, but if it could the static analyzer wouldn't fail for the same reasons I fail)
- iMerNibor 3y ago
  Being able to stop constantly keeping things in the back of your head and just trusting the compiler to complain if something is off was the biggest differentiator for me by far. Less footguns = more better
  - bluGill 3y ago
    When I switch to C++11 and unitue_ptr things got a lot better. There is still a lot of cruft from old code, but C++ is a lot better as of 12 years ago. I don't let people manage raw pointers without good reason (I wouldn't let someone use unsafe rust without good reason either)
- xiphias2 3y ago
  I think there's enough data that even the best human programmers and lifetime checkers aren't able to track lifetimes over a 10 million line code base. That's why we're stuck with lifetimes as function contracts.

by twic 3y ago

bluGill 3y ago

> Of course, a few of them of say they understand object lifetimes so well, they they don't need the static checker! There is a difference between understanding lifetimes and being able to keep track of them. I have a lot of objects in my more than 10 million lines of code. Most of them have simple lifetimes that are easy to track, but a few for reasons (which may or may not be valid - often the reasons are it was built in C++98 and updating to modern lifetimes is hard when it is used all over) have complex lifetimes that are tedious to track. It isn't that I can't, it is that I get bored/make mistakes and the static analyzer wouldn't (Or course C++ can't be statically analyzed, but if it could the static analyzer wouldn't fail for the same reasons I fail)

iMerNibor 3y ago
Being able to stop constantly keeping things in the back of your head and just trusting the compiler to complain if something is off was the biggest differentiator for me by far. Less footguns = more better
- bluGill 3y ago
  When I switch to C++11 and unitue_ptr things got a lot better. There is still a lot of cruft from old code, but C++ is a lot better as of 12 years ago. I don't let people manage raw pointers without good reason (I wouldn't let someone use unsafe rust without good reason either)
xiphias2 3y ago
I think there's enough data that even the best human programmers and lifetime checkers aren't able to track lifetimes over a 10 million line code base. That's why we're stuck with lifetimes as function contracts.