Oh boy, that is so not true. Anything where the boundaries of the lifetimes are easily determined at runtime but unknown at compile time is extremely easy to model safely in C, and a nightmare in Rust. At least if you want the same level of performance and a similar modeling of the data
With all due respect to Michael Palin, "this isn't an argument ... it's just contradiction."
Perhaps, for the benefit of those of us observing if nothing else, it might be beneficial to identify some concrete examples to discuss before proceeding.
I dislike when a discussion turns into "I have to teach you the basics now". I'm just not willing to engage in that most of the time with strangers on the internet because they usually don't want to be taught, they want to be right.
Explaining that you can express complex dynamic lifetimes in Rust using 'unsafe' and module-level safety is a waste of my time because it's empirically true.
But you are engaging with strangers on the internet. You're just not doing it in a way that's particularly edifying. Indirectly insulting me and others doesn't help your case on that front.
Let me turn it back on you. By refusing to educate people on what you think they got wrong, you come across looking like just what you're worried about: someone who just wants to be right.
If your goal is to defend Rust, I would suggest you either teach for yourself, or share links to others teaching the thing you want to communicate but don't want to type out, or, if neither of those, then to simply keep your peace and let someone else do the responding. Speaking for myself as an on-and-off Rust learner, I've got to say that the single biggest frustration I've experienced with learning the language is wading through all the low effort gainsaying in order to find the nuggets of digestible, practical advice about how to effectively use the language for non-toy problems. It's not that I can't do so, per se. It's just that it's really hard, and perhaps even counterproductive, to work up the motivation to wade through all the snark and invective when my original purpose was to try and unwind at the end of the day.
In my experience, the vast majority of examples where that fails is because of two reasons: project evolution that doesn't spend time re-evaluting memory managemnt together with the new requirements on the data, or inexperienced C coders. So that goes to my last point in my original post, yes as an industry there are use cases where rust is better because of the provably safe memory management (let's forget unsafe for the moment). But as a language you _can_ safely model those situations in C esily. The problem is that the solution is not robust to change. If you don't agree with that it will be me who doesn't know how to take what you say seriously
Um, lifetimes are not a made up concept of rust to be in your way. It helps you understand issues that would be real and undetected in your C app.
Your C app would work by happy accident and you would not notice until later when data is corrupted in another part of your program. This is the rest of us wanted to leave C/C++.
Rust lifetimes are just the lifetimes of the memory, exactly the same as C. The only difference is you simply need to (sometimes) tell Rust where the memory for a reference comes from explicitly, where as in C you don't (but in C if you get it wrong your program will segfault, unlike Rust, or worse it might not...sometimes).
> Rust lifetimes are just the lifetimes of the memory, exactly the same as C.
Rust lifetimes are only the lifetimes of the memory that are provable by the type system. There are many valid lifetimes that are not provable. For example lifetimes that change at runtime, and self referencing lifetimes, or cyclic lifetimes. Newer versions of the borrow checker enable it to prove more lifetimes correct, but it will never be able to express all valid lifetimes of the actual memory.
This means some patterns the are completely valid cannot be expressed in safe Rust due to the limitations of the type system, but can be expressed in C.
