Debugging code is like sorting + searching a boolean function of the code ("looks_good(line of code)"). So debugging is for all intents and purposes O(n log n).

Debugging code is like sorting + searching a boolean function of the code ("looks_good(line of code)"). So debugging is for all intents and purposes O(n log n). So writing more lines of code leads to even greater debugging. And, let's throw in another 'unfamiliarity' factor k, where k is high if you are using a new technology. So, I would say, either keep lines of code low (don't bother learning a framework that will make you take months to get to an MVP) or keep unfamiliarity low (use what you know, or something that can act as a bridge between what you know and what seems hot). Another approach: use the language/framework that you know that you think tends to result in the tersest resultant code :^)