The idea of ubiquitous need for significant enforced correctness assurance is one of the worst things in software. Correctness is a resource like time or memory. Some applications need extremely high resource of correctness, some applications don’t (and can even fail badly, usually due to delay or rigidity, if they have an over-provisioning of correctness).
The presumption that every type of project should fundamentally begin with adherence to patterns guaranteeing high resource usage of correctness is a bad type of premature optimization / premature abstraction.
Rust & Haskell are great tools in the rare cases you do need extreme correctness. But in my experience most situations do not benefit from spending that cost (the ways Haskell & Rust enforce program structure is a huge cost) to get correctness, and you can get approximately just as much correctness with pretty low-touch unit & integration tests in most languages, without heavy costs of roundtrip compile times, static typing, forced (instead of selective) management of mutability and ownership, and so on.
The presumption that every type of project should fundamentally begin with adherence to patterns guaranteeing high resource usage of correctness is a bad type of premature optimization / premature abstraction.
Rust & Haskell are great tools in the rare cases you do need extreme correctness. But in my experience most situations do not benefit from spending that cost (the ways Haskell & Rust enforce program structure is a huge cost) to get correctness, and you can get approximately just as much correctness with pretty low-touch unit & integration tests in most languages, without heavy costs of roundtrip compile times, static typing, forced (instead of selective) management of mutability and ownership, and so on.