Take the set of all finite C programs without loops or recursive function calls. They (clearly?) halt.

Or: the set of all finite Brainfuck programs that don't contain a `[` or `]` instruction. Those also halt.

Also, see Idris: https://www.idris-lang.org/. It's a language that has dependent types and a totality checker.

A dependent type is a value which depends on another value. For example, the length of an array depends on how many elements there are in the array.

A totality checker means that you must prove that a program that you write halts; otherwise, it fails to compile.

In Idris, if you ever write the equivalent of reduce recursively, you must prove that the recursion will terminate. This is done by noting that the length of an array is dependent on how many elements are in the array, noting that if an array has zero length then reduce will terminate, and noting that every time reduce is called with a non-zero array length it returns reduce called with that array length decremented by one. Then, since repeatedly subtracting one from a positive number eventually reaches zero (at which point the recursion halts) you're guaranteed that your reduce function halts.

EDIT: I guess you are right in the strict sense that languages like Idris aren't Turing complete. But they still can do a huge number of computable and useful things (and most of the things you'd want other languages to do), so I feel like "Turing complete" is mostly a semantic argument here.

In my mind it's more like an acceptable upper bound on provability of immutable and eternal transactions on some distributed machine. The downside to unexpected exploits far outweighs the upside to unlimited flexibility. Bitcoin chose a non turing-complete script for its transactions, and the short history of cryptocurrency has already prove that is much more secure than the infinite-possibilities of the Ethereum VM. Time will tell, but I personally expect "shocking" exploits of Ethereum smart contracts to continue ad-infinitum.

Perhaps there remains some unexplored region in the limited yet flexible yet verifiable space of languages that was until now uninteresting.

My point is that the halting problem doesn’t prevent you from analyzing any particular program for exploits.

I wasn't claiming that it is not possible to analyze a program to detect known exploits. Rather that it is extremely probable that another exploit will be found after the last one has been patched, and it is impossible to prove otherwise.

The halting problem doesn't prevent playing whack-a-mole against previous exploits, but it ensures that proving more exploits do not exist is impossible. That's why I think a turing-complete language for smart contracts is a poor choice.