It’s one backed by a lot of data. One example is from the Android project.

The percent of vulnerabilities caused by memory safety issues continues to correlate closely with the development language that’s used for new code. Memory safety issues, which accounted for 76% of Android vulnerabilities in 2019, and are currently 24% in 2024, well below the 70% industry norm, and continuing to drop.

https://security.googleblog.com/2024/09/eliminating-memory-safety-vulnerabilities-Android.html

There’s an argument that critical infrastructure software vendors are already meeting standards for basic, non-memory related items. Yes, there are other categories, but memory safety is one that’s harder to verify. Moving to memory safe languages is an ensure a category of correctness. This excludes usage of unsafe escape hatches.

#DonaldTrumpIsAHumanToilet

We have a mathematical model, Navier-Stokes (NS), that seems to describe motion of fluids well. In practice NS and related approximation models with simpler numerical solutions can be used to derive useful results. In that sense we can simulate turbulence for some sets of conditions and get useful approximations out. In general it’s still an open problem if NS has, given an initial velocity field, a solution that is globally defined and smooth. Practically this means we don’t know one way or the other if NS has initial conditions under which the velocity or pressure fields of the solution tend to infinity in finite time. This is the unsolved Navier-Stokes problem.

https://en.m.wikipedia.org/wiki/Navier–Stokes_existence_and_smoothness

…whoosh

https://en.m.wikipedia.org/wiki/Three-fifths_Compromise