I don't know of a magical language that can result in excellent code without discipline. But languages do vary significantly in how hard it is to take non-excellent code written without discipline and safely make it better code. The dynamic scripting languages are on the bottom of that list; all the freedom they enable also simultaneously make that harder.
This is probably the best way to understand the increasing push towards static types lately. It isn't so much necessarily the experience of writing the code the first time, where static types may at least sometimes indeed be a bit harder to work with. It's that it's a relatively easy to work with code that takes a list of OrderIDs and CustomerIDs and returns a map of CustomerID -> Order, and calls a function that takes an OrderID and yields an Order, a method that takes an Order and yields a Customer structure, and a method that takes a Customer and yields a CustomerID, and finally constructs exactly the promised structure. You can change it and feel pretty good about what's going on and what's going to happen both to the code it calls and the code that call it.
On the other hand, working with code that takes a something and a something and returns a something, calling a function that takes as something and yields a something, another function that yields a something and a something, and a method on one of those somethings that takes a something and yields and something, and then returns something, is harder to work with, before we even talk about the fact that these somethings may have no literal source code existence because there were dynamically assembled, and after the somethings were dynamically assembled, other somethings may have come along and turned those somethings into something else.
Obviously, the first case still isn't heavenly and the second case isn't as bad as I make it sound in this brief summary, but there's still a real difference.
I think the spirit of their argument is that there are plenty of languages with more benefits from an engineering standpoint and fewer downsides. Static typing, cleanser language construction, etc.
This is probably the best way to understand the increasing push towards static types lately. It isn't so much necessarily the experience of writing the code the first time, where static types may at least sometimes indeed be a bit harder to work with. It's that it's a relatively easy to work with code that takes a list of OrderIDs and CustomerIDs and returns a map of CustomerID -> Order, and calls a function that takes an OrderID and yields an Order, a method that takes an Order and yields a Customer structure, and a method that takes a Customer and yields a CustomerID, and finally constructs exactly the promised structure. You can change it and feel pretty good about what's going on and what's going to happen both to the code it calls and the code that call it.
On the other hand, working with code that takes a something and a something and returns a something, calling a function that takes as something and yields a something, another function that yields a something and a something, and a method on one of those somethings that takes a something and yields and something, and then returns something, is harder to work with, before we even talk about the fact that these somethings may have no literal source code existence because there were dynamically assembled, and after the somethings were dynamically assembled, other somethings may have come along and turned those somethings into something else.
Obviously, the first case still isn't heavenly and the second case isn't as bad as I make it sound in this brief summary, but there's still a real difference.