Post History

There are a few main and a few minor factors involved in most "which tool should I use" decisions.

## Evaluation Criteria

1. "What do I already know how to competently use?" OR "What do I want to learn how to competently use in the course of writing this project?"
2. Are there any peculiar needs served best by one tool over another?
3. Am I being mandated to use any particular tool by a customer or The Management?

In the ideal world question 2 above would be the only way we ever evaluate anything, but in the real world humans are irrational and we tend to pick the absolute worst tools for a given job from a technical standpoint but make those decisions in a way that is emotionally satisfying for us at the moment we make the decision (and never mind how much pain this may cause us months later).

## Separation of In-Development VS Runtime Concerns

When thinking about a tool it is useful to make two separate value judgements about it, one on how we interact with that tool (its interface) and the other on what utility it will provide for us when it is applied.

1. How will the project feel to interact with during development?
2. How will the resulting system actually run in production? (Performance characteristics and so on.)

### Your Main Languages *Are* Your Main Interface

Your main interface to most projects is the language you decide to code in as this is where you will be spending most of your time. Dealing with customer data it is also likely that you will be spending a fair amount of time dealing with your DB schema and actually programming the DB itself (depending on how far into "make the DB do the work" you want to get VS "make the DB remember some things but do the work in the application code procedurally") -- so the decision to use Oracle instead of Postgres winds up implicitly also becoming the decision between flavors of SQL and possible PL/SQL vs PLpg/SQL vs PL/Python or whatever else vs non-relational DBs vs writing your own data handling and storage procedures from scratch.

This isn't always a significant difference but it certainly can be (money can also be a big difference when picking between Oracle and Postgres). One of the most annoying things is to build 90% of a project using a set of tools or libraries only to realize that they *almost* do what you want but *not quite* and to get that final, crucial 10% of functionality out of it you have to decide between performing major surgery to cover the gap or engaging in [Workaround Oriented Programming](https://en.uncyclopedia.co/wiki/Workaround-oriented_programming) to make the thing go (one reason the web is itself such a weird stack of idiosyncratic tools, languages and techniques is because it is a prime example of an entire ecosystem of workarounds).

Interfaces are important and that's why after using dozens of languages and learning them well enough to hate all of them at least a little, I have settled on a handful of go-to languages that have features I consider to be the most expressive, easiest to read months later (as opposed to writing "clever" code in a language that rewards that sort of thing, and then being confused months later why anything does anything), and most compatible across different coders who use the same language. For me this means picking languages with *limited* feature sets that rely more on functions than nifty syntax-driven features and data structures as opposed to OOP style [objects](https://www.youtube.com/watch?v=KrhmkWP_HwA). But everyone has their favorite things.

### The Bestest Language Can't Beat a Garbage Runtime

Language decision is one thing, but runtime decision is an entirely separate concern in many cases. Whether or not to use Python, for example, may be a far less influential decision than whether you continue to run the resulting code on the standard Python runtime or move to Cython or Jython, or in the case of Java stick with Oracle's JVM, the OpenJVM or IBM's JVM.

None of this even addresses the issue of concurrency, distribution, robust behavior (fault tolerance), or other runtime considerations of course. If runtime concerns are your primary criteria for selection because they dwarf every other requirement of your project (which is very often the case for me) then the cost of learning a language you've never even seen before might be trivial compared to the relative cost of trying to implement some desired characteristic of a runtime yourself in a language you already know well. (This has been so true for me over the last several years that I went from being an Erlang tourist to lately working almost exclusively in Erlang!)

## At The End of The Day...

By the time your project is complete you'll have spent more time comprehending your project and what it *does* than the incidental details of what particular DB you picked or what language you happened to write a given component in, aside of course from the cases where a particular runtime requirement could only be well served by a runtime and language designed specifically to handle your particular problem (for example, consider that SQL and the PL/[foo] variants are just ways to drive a runtime that has optimized primitives for handling relational data). If the tools you pick don't match the problem you are solving then it doesn't matter how cool the language you get to code it in might be: the solution will be either kludgy or extremely time consuming to implement properly.

I'm a lot less intimidated by the prospect of learning a new language to work on a given project than I am to actually have to learn a large project's internal libraries, coding practices and inner quirks.

I can't tell you what technology to use for your application. I know what I would use to start with (no guarantee I wouldn't switch after a few days realizing it wasn't going to work out), but familiarity and personal experience plays a lot into that. Hopefully I've instead explained a little bit about how I would think about tool and tooling choices, though, and you can apply that to your own decisions.

As always, the only truly correct answer is: "It depends"