> 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.

> 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)

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.

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

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)

> Why on earth would you try to rewrite python CRUD apps in Rust?

Because Rust has a lot of incredibly helpful features that make bigger systems far less of a pain to maintain. I work in Java/Kotlin, and my entirely gut-based estimate is that 66% of problems wouldn't happen in Rust.

My big favorites are: - Sane, well-defined, enforced, opt-out error handling - Sane, well-defined, enforced, opt-out handling of "missing" values - Exhaustive switching - WITH usable ADTs (enums) for encoding valid state

None of the web languages I know have all of that.

Scala has all of that and predates Rust by far.

But even Java is pretty much there: checked exceptions are available (and imo superior), but Optional is also an.. option. Kotlin/scala can handle nulls, but java can also statically analyse every usage with annotations.

switch expressions are exhaustive in java over enums and sealed ADTs. (Rust has a misnomer, their enums are ADTs, java has both real enums and ADTs now).

Rust enums cover both ADTs and enums.

So... Haskell, OCaml, F#, Elm?

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

As someone who only used Rust casually - understanding object lifetimes and knowing how to encode this in Rust type system is not the same thing. Not to mention that Rust can't statically prove some things that are valid (eg. cyclic references).

I personally really like the type-system, for any kind of project really