At work? The best tool for the job. A lot of people say that but never provide their criteria, so here are the major points I consider in order to determine whether or not a language is the best tool to use for a given project:

1. Time to useful knowledge: Do I already know this language or does it look like something I can learn quickly? This is a personal thing which requires honest self-assessment. I can typically learn a programming language to the point of (professional) usefulness within a weekend, sometimes I need a bit longer, but I've gotten pretty good at guesstimating how long it will take me to learn something. If you're a professional software engineer, then you should definitely take the time to self-assess if you're not already doing so.

2. Is runtime performance a concern and if so, to what degree?: If runtime performance is a major concern or if the application requires heavy computation, data manipulation, or parsing of large amounts of text (companies still do this...), then I start comparing task-specific benchmarks online and/or writing my own benchmarks in various languages in order to make an adequate comparison.

3. External dependencies: For each language under consideration, given the tasks, will I require the use of lots of external libraries? Does using those external libraries carry with it additional risks and are those risks acceptable? In general, pulling in a ton of outside dependencies and to a lesser extent, internally maintained dependencies, carries certain risks. For example, if we rely on an external library that all of a sudden ceases to be maintained, or the developer is not very good about keeping up with security fixes. This is a huge problem when required to use a proprietary library or tool, less so in the Free Software and Open Source worlds.

4. Is my team already proficient in the language being considered?: Very similar to #1. It's all well and good if you can learn a language in a matter of hours to the point of usefulness because you're an excellent engineer who knows how to self-assess, but what about your team? If the project requirements don't offer much in the way of prep-time (as is the case in most startups) and your team in general is not quick to pick up languages (or frameworks), then consider placing bonus points on languages they already know.

5. Development time: Is this a time-sensitive project? Is the average speed of development in the considered language acceptable given the project's time constraints? Typically development times are better for languages where I'm "more than just useful", same for my team. This isn't always the case though. Sometimes a language just lends itself to faster dev times, whether it be due to minimal syntax or well designed grammar or ease of understanding the language API docs. For example, Go might have easy to grasp syntax, but the docs, while technically complete, are lacking in the "readable by mere mortals" department. Meanwhile (and I'm probably committing a cardinal sin here), C# has some strange conventions, but the docs are clear as day. If I have a young team and the other criteria point to either Go or C#, as a lead dev, I might lean more toward C# for the benefit of team dev time (and confidence building).


At home? I use what's fun. Typically I'll choose a language that I have less practice in (C, Rust, the lisps, etc) because it's fun to observe self-improvement and I enjoy the puzzles that come up.