>Non-turing complete languages are also ... less susceptible to technical debt.
Well, except the technical debt of writing all the code in a language that may not support solving your problem once you know it better.
Well, except the technical debt of writing all the code in a language that may not support solving your problem once you know it better.
In nutshell to those who may not be familiar with the field: total languages differ from partial TC languages in that they must always include internally a "hit the reset button" exit from potential infinite loops, and this is enforced by the type system.
Since we can't actually observe an infinite number of program steps even in TC languages, this makes total languages effectively just as powerful as TC ones, but total languages are better-behaved in the sense that we can make a statically enforced distinction between provably terminating and possibly nonterminating code, therefore having all optimization/reasoning benefits in total parts, but also infinite processes in coindutive parts.
Then, total languages are just a subset of the non TC languages, and those are as prone to accumulating technical debit as TC languages. For avoiding technical debit, one needs something much less expressive.
Better to start out and keep the core configuration representation simple (e.g. json, protobuf, ini file) and generated by something powerful like Flabbergast.org.