Choosing a language for software you will maintain
Rust, Rails or another stack? Choose for the application, the people maintaining it and the cost of operating it, rather than a benchmark ranking.
· Updated · 
Paul Bădărău
The programming language affects who can maintain an application and what it costs to run. It does not tell you whether the application solves the right problem. A business buying software needs an explanation of the choice in terms of its own requirements.
Start with the work the application must do
Describe the important workflows, expected use, integrations and constraints. A reporting tool used by a small team has different demands from a service processing a continuous stream of events.
Ask the developer which requirement makes the proposed language a good choice. An existing team, a library the application needs, or compatibility with a current system may matter more than a performance comparison.
Treat benchmarks as a question to investigate
A benchmark measures a particular implementation on particular hardware, with a particular workload. Different database access, caching or error handling can change the result. Throughput without correct results does not establish that a system meets its users' needs.
Before paying for a migration on performance grounds, reproduce the problem in your application. Identify where the time goes and compare changes under the same conditions. The useful result is the improvement to the workflow that matters to the business.
Include maintenance in the decision
A language choice also determines which developers can review changes, which dependencies you rely on, and how releases work. Ask who will maintain the system after launch and how another developer would take over.
Our experience includes Ruby on Rails, Elixir, Rust and native iOS development. We choose within that experience according to the project. We discuss compatibility and maintenance before proposing a new stack.
A working application needs a reason to change
An application written in Rails or Phoenix does not need a rewrite because another language is popular. Improvements to queries, deployment, monitoring or a specific slow component may address the actual problem with less disruption.
Our modernization service begins with the existing system. We compare targeted improvements and replacement against the work you need the application to support.
What to ask before agreeing a stack
- Which business requirement does this choice address?
- Who can maintain the application and review changes?
- Which operating costs and external services does it introduce?
- How will you measure whether performance is sufficient?
- What would justify changing this decision later?
You do not need to choose a programming language before contacting us. Describe the task, the users, what already exists and any constraints. We can discuss the technical choices as part of scoping a custom software project.