Choosing a programming language: a language map for investors and operators
The choice of a programming language is not a technical question about which language is “best.” It is the management answer to “who will build this, what will they build, at what scale, and on what timeline?”
When investors and operators ask “why are you using Python?” or “what would it cost to move to Go?”, whether they have a framework to evaluate the answer changes the quality of their tech DD substantially. This is a tech literacy problem, not a coding problem — reading language choice through the right lenses is entirely possible without being able to write code. This article lays out five lenses for evaluating language selection and walks through the major languages in a form usable for investment and operating decisions.
Language choice is a business choice: five evaluation lenses
A programming language is a tool, but choosing a tool is also choosing a set of constraints. The following five lenses are useful for organizing the discussion.
Lens 1: Development speed (velocity in the early stage)
How quickly can the team move from hypothesis to PMF (product-market fit)? With small teams and shifting requirements, this lens carries the most weight in the early stage. Python, Ruby, and TypeScript come out ahead here. Their syntax is concise, the libraries are abundant, and small teams can move fast.
Lens 2: Talent availability (depth of the hiring market)
Choosing a language is also choosing a hiring market. Job postings in your country, the size of the engineering community, and onboarding cost are all directly affected. Java and Python have large pools and are easy to hire for; Rust has a smaller pool that is harder to source from, but the average technical level of applicants is typically higher.
Lens 3: Ecosystem maturity (libraries, references, support)
Are the capabilities you need available as standard libraries or open source? For AI/ML, the answer is essentially Python or nothing. For web frontend, the de facto standard is TypeScript (a strict superset of JavaScript). When the ecosystem is thin, teams reinvent the wheel and development cost rises.
Lens 4: Runtime performance (cost and performance at scale)
As user counts grow, language performance translates directly into infrastructure cost. Python and Ruby are interpreted and slow at execution, but for I/O-bound web applications the difference is often invisible. Go and Rust are compiled and fast, and they shine in high-load workloads — API gateways, distributed systems, and embedded use cases.
Lens 5: Long-term maintainability (type safety, readability, community lifespan)
Will a 10-person team still be able to read this code in five years? The presence or absence of a type system has a major effect on maintainability. TypeScript (JavaScript with types) and Kotlin (Java’s successor) score highly thanks to type inference and readable syntax. PHP and untyped JavaScript tend to see complexity grow rapidly as the codebase expands.
Major language map: seven languages across five lenses
| Language | Dev speed | Hiring market | Ecosystem | Performance | Maintainability | Primary use cases |
|---|---|---|---|---|---|---|
| Python | Excellent | Strong | Excellent (best for AI/ML) | Weak | Strong | AI/ML, data, backend APIs |
| TypeScript | Strong | Excellent | Excellent | Strong | Excellent | Web frontend, full-stack |
| Go | Strong | Moderate | Strong | Excellent | Excellent | High-perf backend, infra, CLI |
| Rust | Weak | Limited | Moderate | Excellent | Excellent | Systems, embedded, perf-critical |
| Java/Kotlin | Weak | Excellent | Excellent | Strong | Excellent | Enterprise, Android |
| Ruby | Excellent | Moderate | Strong (Rails) | Weak | Weak | Early-stage startups, web apps |
| PHP | Strong | Strong | Strong | Weak | Weak | Web systems, CMS, legacy |
Per-language profiles: depth for investment and operating decisions
Python: a “scientist’s language” that became a business mainstay
Python’s design philosophy is “readability counts more than writability.” Indentation defines blocks, and the syntax is close to English — both factors that made it approachable for non-engineers (researchers, data scientists). That accessibility is the foundation of its later expansion.
The dominant strength is the AI/ML ecosystem. NumPy (numerical computing), Pandas (data analysis), TensorFlow/PyTorch (deep learning), and scikit-learn (classical ML) are all designed around Python as the primary interface. If you want to embed AI in your product, Python is effectively the only realistic choice. The gap with other languages here is enormous and unlikely to flip in the next several years.
The weakness is execution performance. Python’s GIL (Global Interpreter Lock) makes it hard to fully exploit multi-core CPUs. Workloads heavy on CPU-bound parallelism (large-scale numerical computing, high-frequency trading) become expensive at scale. As a web service grows, traffic forces you to add more servers, and you carry a structurally higher compute bill than competitors on faster languages.
What to watch for in diligence: If AI/ML is core to the product, Python is a defensible choice. If the team is “writing in Python but not doing AI/ML,” accept the development-speed argument but ask what the plan is for handling cost growth at scale (caching strategies, async processing, partial migration to Go or Rust). And note: Python web-backend engineers and data scientists are different roles. “We use Python” tells you nothing about which skill set the company actually has.
TypeScript: how “grown-up JavaScript” took over the frontend
TypeScript is Microsoft’s strict superset of JavaScript that adds static typing. Typing means making it explicit in the code what kind of data each variable holds. By writing into the code that “this variable is a number” or “this function returns a string,” you catch bugs before runtime.
Why TypeScript became the standard. JavaScript was originally designed as a lightweight scripting language for browsers. A flexible, untyped language is fine for prototypes, but in a codebase of hundreds of thousands of lines you lose track of “what should I pass to this function?” and “what shape does it return?” — fertile ground for bugs. TypeScript solved this by encoding type information into the code itself. Google rewrote Angular in TypeScript in 2017, the React community adopted TypeScript as the norm through the early 2020s, and the language became the de facto frontend standard.
The reach has expanded from frontend to backend. Node.js (a runtime that lets JavaScript run outside browsers) made TypeScript usable on the server. Frameworks like Next.js, Remix, and NestJS make full-stack development in a single language possible. Small teams favor “one engineer can write everything from the UI to the API in one language” for the organizational efficiency it offers.
The weakness is the complexity of the type system and the lack of runtime safety. TypeScript’s type system is powerful, but as it grows complex the code becomes harder to read, and managing type definitions itself becomes a maintenance cost. TypeScript also compiles to JavaScript, and the type information disappears at runtime — you can hit cases where “the types check out but the behavior is wrong.”
What to watch for in diligence: A web-services startup choosing TypeScript is making a technically standard, sound decision. The hiring market is the broadest of any language, and both job listings and candidates are abundant — a rational hiring strategy. The thing to verify is whether the team is actually using the type system. A codebase that relies heavily on the any escape hatch (which skips type checking) is effectively untyped JavaScript and gets none of the maintainability benefit.
Go: “boring but reliable” — Google’s pragmatist language
Go was designed inside Google starting in 2007 and released in 2009. The design context was a reaction to the complexity of C++. Across thousands of engineers maintaining large distributed systems, Google found that complex language features were a tax on code review and a generator of human bugs. Go deliberately constrained the language so that “anyone writes broadly the same code” — aiming to be a “boring language.”
Go’s headline strength is concurrency. Goroutines (lightweight threads) and channels (a built-in mechanism for inter-thread communication) are first-class language features. The language can handle thousands to tens of thousands of concurrent operations on modest memory, which makes it a natural fit for high-frequency API workloads, microservice communication, and streaming. Docker and Kubernetes are written in Go for this reason — container management is exactly the kind of problem (“handle thousands of simultaneous requests while using resources efficiently”) that Go was designed for.
Simplicity yields maintainability. Go was late to add generics and has no inheritance. Without elaborate object-oriented design patterns to lean on, code stays “flat.” The gap between code written by an expert and a beginner is smaller than in most languages — a property that compounds in value as teams and codebases grow.
The weaknesses are verbose error handling and a younger ecosystem. Go has no exceptions; functions return errors explicitly. The if err != nil { return err } pattern appears everywhere and adds noise. Unlike Python, you cannot count on “there’s always a library for what you want to do” — in particular, AI/ML, scientific computing, and GUI domains are thin on libraries.
What to watch for in diligence: Go is the typical pick for API gateways, microservices, CLI tools, and infrastructure layers. “We’re writing the high-traffic backend in Go” is a coherent technical story. The thing to flag is hiring difficulty. The Go talent pool is smaller than Python, TypeScript, or Java in most markets, and hiring takes longer. Evaluate Go selection together with the hiring strategy — open-source contributions, sponsorship of community events, and similar moves.
Rust: the next-generation systems language combining speed and safety
Rust is a language Mozilla (the organization behind Firefox) began developing around 2010 and released as 1.0 in 2015. The core design goal: “C-equivalent execution speed while guaranteeing memory safety.”
What is memory safety? C and C++ are extremely fast but require the programmer to manually manage memory. Forget to free memory and you get a “memory leak”; access already-freed memory and you get a “use-after-free” bug. These are major sources of security vulnerabilities. Microsoft’s security team has reported that roughly 70% of CVEs in Windows trace back to memory-safety issues (see Microsoft Security Response Center, “A proactive approach to more secure code”). Rust’s “ownership” system guarantees memory safety without a garbage collector — you get safe code with no runtime overhead. That combination is genuinely novel.
Where it is being used. The Linux kernel (the core of the operating system) accepted Rust in 2022; Windows and Android are also expanding their Rust adoption. Rust has strong synergy with WebAssembly (the technology that runs high-performance code in browsers), and is widely used in blockchain and crypto implementations. Cloudflare, Discord, and Dropbox have all reported migrating high-load components from Go or Python to Rust.
The weakness is a steep learning curve. The ownership model is conceptually difficult, and even experienced programmers spend a while fighting the compiler. It is not unusual to wait several months before a Rust engineer reaches full productivity. Rust is not the right language when the goal is to ship a prototype quickly.
What to watch for in diligence: When a startup chooses Rust, examine the reason carefully. “We’re using Rust where performance is essential — a game engine, cryptography, real-time processing” is a reasonable judgment. “Our founding CTO likes Rust so we wrote everything in Rust” is a technical preference masquerading as a decision and carries a very different risk profile. In the latter case, hiring difficulty and slow early development can hurt the business. Determine whether Rust is functioning as “defensible core technology” or generating “ballooning hiring cost.”
Java / Kotlin: the enterprise mainstay and its successor
Java was released by Sun Microsystems (now Oracle) in 1995 with the design philosophy of “write once, run anywhere.” Code runs on the JVM (Java Virtual Machine), so the same program can run regardless of operating system. Java has 30-plus years of track record across enterprise IT, finance, and manufacturing core systems.
Java’s strengths are ecosystem maturity and corporate adoption. Spring Framework (the de facto standard for web apps and microservices), Hibernate (database access), and Maven/Gradle (build tooling) are all mature. Adoption among large SI firms (system integrators), financial institutions, and government agencies is widespread, which is viewed as low-risk from procurement and maintenance angles. Java is still in production at hyperscale services like Amazon, Netflix, and LinkedIn.
Kotlin is rising as Java’s successor. Google made Kotlin the official language for Android development in 2017. Kotlin’s concise syntax, null safety (which prevents the very common NullPointerException class of bug), and coroutines (which make async programming easier) address Java’s shortcomings while reusing the JVM’s library and tool ecosystem. Android apps are increasingly Kotlin-only, and on the server, Kotlin + Spring Boot is a growing stack.
Weaknesses are verbosity and complex initial setup. Java’s “everything must be in a class” forces object-oriented structure even for simple operations, which inflates code size. Complex configuration files, slow JVM startup (which clashes with serverless environments), and abundant boilerplate often constitute over-engineering at the early-stage startup level.
What to watch for in diligence: Most startups that pick Java are either targeting enterprise B2B customers or building products in regulated industries like finance and healthcare. “We aligned the stack with what enterprise security teams expect” is a sensible business reason. For a B2C consumer-facing startup, however, Java’s slow development speed is often a constraint in the early stage. Whether the team is migrating to Kotlin is also a meaningful signal.
Ruby: a language built for “developer happiness,” and the legacy of Rails
Ruby was released in 1995 by Japanese engineer Yukihiro Matsumoto (Matz). The design principle was “a language for the happiness of programmers,” prioritizing readable and writable syntax. The framework built on top of it, Ruby on Rails (2004), changed startup development culture.
What Rails changed: “Convention over Configuration.” Rails encoded a long list of conventions — database table names should be the plural of the model name, URL structures should follow this pattern — eliminating the configuration tax. With this philosophy, startups from 2005 to 2015 could build prototypes at remarkable speed. GitHub, Shopify, Airbnb, and Cookpad all built their initial products on Rails and grew rapidly.
Where Ruby stands today: rich legacy, shrinking new adoption. Entering the 2020s, new project adoption of Ruby has been declining. The rise of TypeScript made “one language across frontend and backend” realistic, Python became more attractive for backend work, and the Ruby hiring market began contracting. Japan has comparatively more Ruby engineers than other markets, but competition for them is intensifying.
Ruby’s runtime performance has been improving. Ruby 3.0 (2020) hit the “Ruby 3x3” target (3x faster than Ruby 2.0), and performance has continued to improve. That said, throughput still trails Go and Node. Shopify is able to keep using Rails at scale only because of substantial optimization investment.
What to watch for in diligence: When evaluating a startup with an existing Rails codebase, check two things. First, sustainability of engineer hiring and retention. The Ruby talent pool is shrinking; ask whether the company can still hire on the same stack 10 years from now. Second, whether there is a migration plan to other languages. As Shopify shows, at scale you eventually need to move performance-critical components to Go or Rust. The presence or absence of that plan and awareness is a long-term risk indicator.
PHP: the silent backbone of the web, and modernization efforts
PHP was developed in 1994 by Rasmus Lerdorf as a server-side language for the web. It originally stood for “Personal Home Page,” but is now the recursive acronym “PHP: Hypertext Preprocessor.” Statistics suggest that 75–80% of dynamic websites use PHP — driven heavily by CMSs like WordPress and Drupal — making it a quietly indispensable backbone of the internet (see W3Techs, “PHP usage statistics”).
WordPress and Laravel: two faces. PHP has two distinct personas — “the language of WordPress” and “the modern development language used through Laravel.” WordPress is used by more than 40% of all websites in the world (see W3Techs, “WordPress usage statistics”) and dominates blogs, corporate sites, and media. Laravel (2011-) is a modern MVC framework that delivers a developer experience similar to Rails, and is widely used in Japan for e-commerce, media, and enterprise applications.
Modernization in the PHP 8 series. Pre-PHP 5 had a deserved reputation as “a language where it’s easy to write bad code.” PHP 7 (2015) brought major performance improvements, and PHP 8 (2020-) added a real type system, a JIT compiler (faster execution), named arguments, and other modern features. Evaluating PHP through its older reputation is no longer accurate.
The weaknesses are the legacy of “old PHP” code and a polarized hiring market. PHP carries historical inconsistencies — no enforced typing, easy use of global variables, inconsistent function naming. Modern PHP and legacy PHP are essentially different languages in terms of quality. The hiring market is also bifurcated: a Laravel engineer and a WordPress maintenance engineer have very different expected skill sets.
What to watch for in diligence: When evaluating a PHP-using startup, always ask “which PHP?” A modern stack (“Laravel + Composer (package management) + PSR standards (coding standards)”) and a legacy one (“untyped, heavy use of globals, no framework”) have fundamentally different technical-debt profiles. Note also that some companies describe a WordPress-based service as “in-house web system development.” WordPress is a CMS, and the technical context differs significantly from custom backend development.
A matrix of “what you build” and “who builds it”
To evaluate whether a language choice is appropriate, look at it through two axes — product characteristics (what to prioritize) and team characteristics (how many people are building).
The case to flag is when the chosen language does not match the quadrant. “A 5-person seed-stage company is using Rust” warrants a check: is the team consciously accepting the higher hiring cost and reduced development speed as a trade-off? It can be a signal that technical preference has overridden business judgment.
Estimating the cost of switching languages
Changing languages is not just rewriting code. The following costs apply.
1. Learning cost: The lost time and reduced velocity while the existing team learns the new language. For some languages, this represents a slowdown of half a year to a year.
2. Ecosystem rebuild: Rebuilding existing tooling — testing, CI/CD, monitoring — for the new language.
3. Hiring strategy revision: Updating hiring requirements for the new language and adjusting to a different talent pool.
As a practical rule of thumb, a full migration of a codebase larger than 50,000 lines is typically a one-to-two-year project. For a startup, this is essentially equivalent to a rebuild.
Three diligence questions to evaluate language selection
When evaluating language choice in tech DD, the following questions are effective.
Question 1: When you ask “why this language?”, do you get a business reason?
“Our engineers were good at it” or “it was popular” are warning signs. “AI/ML is core to the product, so Python was a must” or “we picked Java because of the size of the hiring market” — answers that connect to business requirements, hiring strategy, or scaling plans — indicate a high-quality decision-making process.
Question 2: Can the current language handle the projected growth?
When users grow 10x or 100x, can the current language and architecture absorb that? If a Python web service grows rapidly, is there a plan for resolving performance bottlenecks (partial migration to Go or Rust, leveraging async)? Scaling without a plan is a technical landmine.
Question 3: Is language diversity controlled?
The more languages in use, the higher the cost of hiring, maintenance, and onboarding. “Backend in Python, infrastructure in Go, frontend in TypeScript” is a realistic three-language setup, but five or more languages in active use suggests the codebase has outgrown what the organization can manage. It tends to be a hotbed for technical debt.
How language choice relates to technical advantage
Finally, does language choice itself become a competitive advantage?
Conclusion: The language by itself is not a differentiator.
Any language can build the same product (performance requirements aside). Differentiation lies in the proprietary data, algorithms, and domain knowledge built on top of the language. “We’re building our web service in Rust” is not by itself an advantage; what matters is “is the language choice aligned with the business requirements, and can we sustain hiring and maintenance with it?”
Language evaluation should never be done in isolation. Read it together with organizational capability, hiring strategy, and scaling plans.
Related reading
A natural counterpart to language choice in tech DD is evaluating the quality of the code written in that language and the technical debt it carries. “The true nature of technical debt and the patterns that hurt startups” reframes technical debt as a framework usable for investment decisions.
For the broader picture of tech DD, see The big picture of technical due diligence and seven evaluation lenses. For concrete techniques a non-engineer can use to assess an organization, see How to read an engineering organization before an acquisition.
Tied Inc. provides technical due diligence support for VCs and operating-company M&A teams. For details on tech evaluation, including language selection, see our services for investors, or contact us directly.