This thought came to mind while reading this and was a lesson I had learned sometime earlier in my career: your customer (both internal and external) doesn't ca

This thought came to mind while reading this and was a lesson I had learned sometime earlier in my career: your customer (both internal and external) doesn't care about the tools you used to create their product or service. Just like you don't care what tools were used to create your dining room table. Why then does it matter to us? These are the usual suspects: 1. Availability of labor. That also affects cost of labor. The more esoteric your technology stack then the harder it's going to be to find labor and the more expensive it's going to be to get it. 2. Implementation efficiency. You may not care about (1) if your technology stack allows the person to do the work of 10 using a mainstream technology stack. 3. Flexibility. Change is inevitable and continual. Some technology stacks are more flexible than others and allow you to rapidly respond to change. This is often coupled with (2). 4. Longevity. You should plan for your product/service to be in place for 10 years before a major overhaul may make sense. This could be as high as 15 to 20 years in some corporate environments. Not only do you need the support, but you need to make sure (1) is still true throughout the product lifetime. Notice what I didn't mention: how "cool" the language or its technology stack is, or is the language object-oriented, functional, or whatever. None of that matters, unless (1)-(4) have led you to a couple of different options then you could use that to differentiate those options. But you have to make sure you have (1)-(4) covered first. But at the end of the day, only you care about the code.