Library · Interactive guide
Programming Languages 2026 — Interactive Atlas
Don’t choose a language. Choose trade-offs.
An interactive atlas of programming languages: execution and memory models, performance, safety and security, use cases, emerging languages, AI coding agents and a decision framework. This edition is translated and restructured from the original Polish atlas, Programming Languages 2026 — Interactive Atlas. It is not a ranking: read it from start to finish, or go straight to the language explorer, the use cases, the decision matrix or the cheat sheet. As the note under the title says, it was researched and drafted with AI tools, then translated from Polish, restructured and checked by Nexate.
How the tools work
- Language explorer. Search the 31 languages and narrow them with five filters: use case, execution, memory, typing and status. The search and the filters are kept in the page address, so a filtered view can be shared. ‘Details’ opens a language’s full profile, and every language has its own link, for example #lang-rust. Tick ‘Compare’ on two to four languages, then open the comparison from the tray at the bottom of the screen. The selection is also kept in the page address, and saved in this browser on this device only; nothing is sent anywhere. ‘Clear’ removes it.
- Performance table. Sort the table by the language or by any rating column. The ‘Memory / control’ and ‘Predictability’ columns come from a stated rule of thumb, explained under the table.
- Break-even calculator. Move the sliders to set the developer cost, the development time in Python and in Rust, and the monthly infrastructure cost of each. The result shows when a rewrite would pay for itself, and ‘How it works’ gives the formula.
- Use cases. Choose one of the 29 use cases to see the recommended start, good alternatives, when to consider something else, what to usually avoid, the main trade-off and why. The arrow keys, Home and End move between them, and every use case has its own link, such as #use-case-rest-api.
- Decision helper. Choose a domain, a priority, a runtime preference and a level of risk to get up to four candidates. ‘How it works’ lists the rules it applies.
- Decision matrix. Filter the 29 use cases by text and sort any column; each use case links to its panel above.
- Glossary. Search the terms; every term has its own link.
Keyboard, links and printing
- ⌘K or Ctrl+K, or / outside a text field, opens the search for this guide. The arrow keys move through the results, Enter goes to the item and Esc closes the search. The search can also filter the language explorer for what you typed.
- Esc closes the details and comparison dialogs, and the focus returns to where you were.
- Every section heading has a copy-link button. Links from the original atlas, such as
#usecases,#matrix,#cases,#cheator a language name such as#rust, still work. - ‘Print or save as PDF’ prints the whole guide with every disclosure open and the address of every external link shown.
Ratings
Every language rating uses the same five steps, always shown as a number and a word:
The ratings are qualitative and contextual; ‘very high’ is not a universal win. The scale is heuristic and contextual — not a benchmark and not a judgement of a language’s ‘quality’. Very low → very high describes relative fit or trait in typical scenarios, not a universal ranking.
The qualitative ratings are an educational heuristic, not a benchmark or a universal architectural recommendation. Evidence: Interpretation
What each rating describes
The original atlas does not define the rating keys. The meanings below are inferred from where it uses each key and from the values; on every key, 5 is the most favourable end.
- Performance
- Raw runtime / CPU performance ceiling.
- Startup
- Startup speed (5 = fastest start).
- Productivity
- Developer productivity / time-to-market.
- Safety
- Memory and type safety guarantees.
- Ecosystem
- Breadth and maturity of libraries and community.
- Ease of learning
- How easy the language is to learn (5 = easiest).
- Tooling
- Maturity of the toolchain (compilers, IDEs, formatters, linters).
- Ease of deployment
- How simple it is to deploy and distribute (5 = simplest).
- AI / data fit
- Fit for AI and data work.
- Web fit
- Fit for web development.
- Cloud fit
- Fit for cloud and backend services.
- Systems fit
- Fit for systems programming.
- Mobile fit
- Fit for mobile apps.
Evidence and tiers
The original atlas marks its claims with the five labels defined under the title, and this edition keeps them:
- Evidence: Verified fact checked against a primary source listed under Sources and methodology, such as the memory-safety guidance from the NSA and CISA, or the status of an emerging language.
- Evidence: Industry observation surveys and engineering case studies.
- Evidence: Benchmark-dependent the performance table and notes, and the case-study results that depend on one workload.
- Evidence: Interpretation the ratings, the computed performance columns, the calculator, the decision helper and matrix, the trends, the future scenarios and the section on coding agents.
- Evidence: Emerging / uncertain the hypothesis about coding agents, and Roc’s maturity, ‘Alpha’, which is not the project’s own wording.
In the use cases and the cheat sheet, the recommended start is marked Recommendation: Default and the option to consider for a specific, nameable need is marked Recommendation: Specialised. Nothing else is tiered.
Executive summary
This is not a ranking. Every recommendation depends on the workload, the ecosystem, the team and the operational constraints.
Raw native performance
C · C++ · Rust · Zig
A high CPU/latency ceiling and memory control. The algorithm and data layout still matter more than the language’s logo.
AI & Data
Python + SQL
Ecosystem dominance; the heavy compute is often done by C++/CUDA/Rust/accelerator kernels.
Modern Web
TypeScript
The browser ecosystem + static guardrails + very mature tooling.
Cloud / Infra
Go
Concurrency, fast builds, single binaries and a simple operational model.
Enterprise
Java · C#
Mature runtimes, tooling, integrations, observability and a hiring pool.
Systems safety
Rust
Ownership moves a large class of memory bugs to compile time without GC.
Mobile
Swift · Kotlin · Dart
Native platforms reward Swift/Kotlin; Flutter/Dart gives a consistent cross-platform UI.
Emerging 2026
Mojo · Zig · Gleam
Mojo 1.0 changed the project’s status; Zig is still pre-1.0, Gleam is growing as a niche typed BEAM language.
Guiding principle
There is no single ‘best language’. There is a language that is better matched to a specific set of constraints.
In practice you choose, all at once, a language, a runtime, an ecosystem of libraries, a framework, a toolchain, a deployment model and the cost of maintaining the skills in the organisation.
- Performance
- Productivity
- Safety
- Ecosystem
- Operations
- Hiring
- Maintainability
- Platform
- Deployment
- Longevity
Fundamentals
The most important differences are not about syntax but about execution, memory, types and the concurrency model.
Execution model
Why does it matter?: Execution model
compiled ≠ always faster; interpreted ≠ always slow, if the heavy computation is done by native libraries.
Memory
Why does it matter?: Memory
The memory model affects safety, latency, ergonomics and footprint.
Typing
Why does it matter?: Typing
Types are becoming the interface for compiler tooling, refactoring and agents.
Concurrency
Why does it matter?: Concurrency
Concurrency ≠ parallelism; the choice of model depends on I/O, CPU and reliability requirements.
Paradigm
Why does it matter?: Paradigm
Most modern languages are multi-paradigm; the team’s practice matters more than the label.
Principle
Language performance ≠ implementation performance ≠ runtime performance ≠ the performance of a specific program.
The same language can have different runtimes, and a ‘slow’ language can drive extremely fast native code. Example: Python + NumPy/PyTorch/CUDA.
Taxonomy
Classify a language on several axes at once. This helps you avoid false analogies.
Abstraction level
- Low-level
- Systems
- General purpose
- Scripting
- Domain-specific
Execution model
- Native AOT
- VM/JIT
- Interpreted
- Transpiled
- Multi-target
Paradigm
- Procedural
- OOP
- Functional
- Declarative
- Logic
- Multi-paradigm
Memory model
- Manual
- Garbage collection
- Ownership
- ARC / reference counting
Dominant use case
- AI/Data
- Web
- Backend
- Cloud
- Enterprise
- Systems
- Embedded
- Mobile
- Scientific
- Games
- Security
Language vs runtime vs framework
‘Is JavaScript better than Java?’ is often a question without context. You are comparing whole technology stacks.
JavaScript ecosystem
- JavaScript
- V8 / JavaScriptCore
- Node.js / Browser
- TypeScript (static checker/transpiler)
- React / Vue / Svelte
- Next.js / app frameworks
Python ecosystem
- Python
- CPython
- FastAPI / Django
- NumPy / PyTorch / Polars
- Native C/C++/Rust/CUDA kernels
JVM
- Java / Kotlin / Scala
- JVM
- JIT / GC / runtime
- Spring / Ktor / Spark
- Containers / cloud
.NET
- C# / F#
- CLR / .NET
- JIT or Native AOT
- ASP.NET Core / MAUI / Unity
- Azure / cross-platform
Rust
- Rust
- rustc + LLVM
- Cargo
- Tokio / Axum / ecosystem crates
- Native binaries / Wasm
Kotlin multiplatform
- Kotlin
- JVM / Native / JS / Wasm
- Coroutines
- Compose / Ktor
- Android / backend / multiplatform
Language explorer
The ratings are qualitative and contextual. ‘Very high’ does not mean a universal win. Evidence: Interpretation
31 languages / ecosystems
No results. Change the filters or the search.
C
Status: MatureA minimal, close-to-the-hardware language with a very small runtime. Still fundamental in kernels, drivers and embedded.
- Static
- Native AOT
- Manual
- Performance
- 5 of 5, very high
- Productivity
- 2 of 5, low
- Safety
- 1 of 5, very low
Full profile: C
A minimal, close-to-the-hardware language with a very small runtime. Still fundamental in kernels, drivers and embedded.
- Philosophy
- Maximum control, little abstraction, a predictable execution model.
- Typing
- Static
- Execution
- Native AOT
- Memory
- Manual
- Concurrency
- OS threads / atomics
- Poor fit
- Large business applications in which memory safety and speed of development matter more than full control.
Qualitative profile
- Performance
- 5 of 5, very high
- Startup
- 5 of 5, very high
- Productivity
- 2 of 5, low
- Safety
- 1 of 5, very low
- Ecosystem
- 5 of 5, very high
- Ease of learning
- 3 of 5, medium
- Tooling
- 4 of 5, high
- Ease of deployment
- 5 of 5, very high
- AI / data fit
- 1 of 5, very low
- Web fit
- 1 of 5, very low
- Cloud fit
- 2 of 5, low
- Systems fit
- 5 of 5, very high
- Mobile fit
- 1 of 5, very low
The scale is heuristic and contextual — it is not a benchmark or a judgement of a language’s ‘quality’.
C++
Status: MatureA very high performance ceiling and a huge ecosystem; widely used in game engines, HFT, graphics and systems.
- Static
- Native AOT
- Manual + RAII
- Performance
- 5 of 5, very high
- Productivity
- 2 of 5, low
- Safety
- 2 of 5, low
Full profile: C++
A very high performance ceiling and a huge ecosystem; widely used in game engines, HFT, graphics and systems.
- Philosophy
- Zero-overhead abstractions and compatibility with low-level programming.
- Typing
- Static
- Execution
- Native AOT
- Memory
- Manual + RAII
- Concurrency
- Threads / atomics / async libraries
- Poor fit
- Small CRUD/MVP projects with no performance requirements, where the complexity of the language brings no return.
Qualitative profile
- Performance
- 5 of 5, very high
- Startup
- 5 of 5, very high
- Productivity
- 2 of 5, low
- Safety
- 2 of 5, low
- Ecosystem
- 5 of 5, very high
- Ease of learning
- 1 of 5, very low
- Tooling
- 4 of 5, high
- Ease of deployment
- 4 of 5, high
- AI / data fit
- 2 of 5, low
- Web fit
- 1 of 5, very low
- Cloud fit
- 3 of 5, medium
- Systems fit
- 5 of 5, very high
- Mobile fit
- 2 of 5, low
The scale is heuristic and contextual — it is not a benchmark or a judgement of a language’s ‘quality’.
Rust
Status: GrowingNative performance with strong memory-safety guarantees without a garbage collector.
- Static
- Native AOT
- Ownership / borrowing
- Performance
- 5 of 5, very high
- Productivity
- 3 of 5, medium
- Safety
- 5 of 5, very high
Full profile: Rust
Native performance with strong memory-safety guarantees without a garbage collector.
- Philosophy
- Move as many errors as possible from runtime to the compiler without giving up control and performance.
- Typing
- Static
- Execution
- Native AOT
- Memory
- Ownership / borrowing
- Concurrency
- Threads + async; compile-time safety
- Poor fit
- Very quick CRUD prototypes, if the team does not know Rust and there are no performance/safety requirements.
Qualitative profile
- Performance
- 5 of 5, very high
- Startup
- 5 of 5, very high
- Productivity
- 3 of 5, medium
- Safety
- 5 of 5, very high
- Ecosystem
- 4 of 5, high
- Ease of learning
- 2 of 5, low
- Tooling
- 5 of 5, very high
- Ease of deployment
- 5 of 5, very high
- AI / data fit
- 2 of 5, low
- Web fit
- 2 of 5, low
- Cloud fit
- 5 of 5, very high
- Systems fit
- 5 of 5, very high
- Mobile fit
- 2 of 5, low
The scale is heuristic and contextual — it is not a benchmark or a judgement of a language’s ‘quality’.
Zig
Status: EmergingA modern systems language that focuses on explicitness, cross-compilation, C interoperability and comptime.
- Static
- Native AOT
- Manual
- Performance
- 5 of 5, very high
- Productivity
- 3 of 5, medium
- Safety
- 2 of 5, low
Full profile: Zig
A modern systems language that focuses on explicitness, cross-compilation, C interoperability and comptime.
- Philosophy
- No hidden control flow and no hidden allocations; simple tools for the low level.
- Typing
- Static
- Execution
- Native AOT
- Memory
- Manual
- Concurrency
- Low-level primitives / libraries
- Poor fit
- Enterprise/web with a requirement for a very mature ecosystem and stable APIs.
Qualitative profile
- Performance
- 5 of 5, very high
- Startup
- 5 of 5, very high
- Productivity
- 3 of 5, medium
- Safety
- 2 of 5, low
- Ecosystem
- 2 of 5, low
- Ease of learning
- 3 of 5, medium
- Tooling
- 3 of 5, medium
- Ease of deployment
- 5 of 5, very high
- AI / data fit
- 1 of 5, very low
- Web fit
- 1 of 5, very low
- Cloud fit
- 3 of 5, medium
- Systems fit
- 5 of 5, very high
- Mobile fit
- 1 of 5, very low
The scale is heuristic and contextual — it is not a benchmark or a judgement of a language’s ‘quality’.
Go
Status: GrowingA simple language geared towards quickly building services, tools and network infrastructure.
- Static
- Native AOT
- GC
- Performance
- 4 of 5, high
- Productivity
- 4 of 5, high
- Safety
- 4 of 5, high
Full profile: Go
A simple language geared towards quickly building services, tools and network infrastructure.
- Philosophy
- A small language, fast compilation, consistent tooling and practical concurrency.
- Typing
- Static
- Execution
- Native AOT
- Memory
- GC
- Concurrency
- Goroutines + channels
- Poor fit
- Advanced HPC/graphics/game engines or applications that need a very expressive type system.
Qualitative profile
- Performance
- 4 of 5, high
- Startup
- 5 of 5, very high
- Productivity
- 4 of 5, high
- Safety
- 4 of 5, high
- Ecosystem
- 4 of 5, high
- Ease of learning
- 5 of 5, very high
- Tooling
- 5 of 5, very high
- Ease of deployment
- 5 of 5, very high
- AI / data fit
- 2 of 5, low
- Web fit
- 2 of 5, low
- Cloud fit
- 5 of 5, very high
- Systems fit
- 4 of 5, high
- Mobile fit
- 1 of 5, very low
The scale is heuristic and contextual — it is not a benchmark or a judgement of a language’s ‘quality’.
Java
Status: MatureA mature foundation for enterprise, backend and distributed systems, with the powerful JVM ecosystem.
- Static
- JVM JIT / AOT options
- GC
- Performance
- 4 of 5, high
- Productivity
- 4 of 5, high
- Safety
- 4 of 5, high
Full profile: Java
A mature foundation for enterprise, backend and distributed systems, with the powerful JVM ecosystem.
- Philosophy
- Portability, stability, strong tooling and the longevity of large systems.
- Typing
- Static
- Execution
- JVM JIT / AOT options
- Memory
- GC
- Concurrency
- Threads, virtual threads, structured concurrency APIs
- Poor fit
- Tiny CLI, hard real-time, very small footprints.
Qualitative profile
- Performance
- 4 of 5, high
- Startup
- 2 of 5, low
- Productivity
- 4 of 5, high
- Safety
- 4 of 5, high
- Ecosystem
- 5 of 5, very high
- Ease of learning
- 4 of 5, high
- Tooling
- 5 of 5, very high
- Ease of deployment
- 3 of 5, medium
- AI / data fit
- 2 of 5, low
- Web fit
- 2 of 5, low
- Cloud fit
- 5 of 5, very high
- Systems fit
- 2 of 5, low
- Mobile fit
- 3 of 5, medium
The scale is heuristic and contextual — it is not a benchmark or a judgement of a language’s ‘quality’.
Kotlin
Status: GrowingAn ergonomic, null-safe JVM language and the main language of modern Android; it is developing Kotlin Multiplatform.
- Static
- JVM / Native / JS / Wasm
- GC / platform-dependent
- Performance
- 4 of 5, high
- Productivity
- 5 of 5, very high
- Safety
- 5 of 5, very high
Full profile: Kotlin
An ergonomic, null-safe JVM language and the main language of modern Android; it is developing Kotlin Multiplatform.
- Philosophy
- A practical modernisation of Java with interoperability and less boilerplate.
- Typing
- Static
- Execution
- JVM / Native / JS / Wasm
- Memory
- GC / platform-dependent
- Concurrency
- Coroutines / structured concurrency
- Poor fit
- Low-level systems and areas where a minimal runtime is required.
Qualitative profile
- Performance
- 4 of 5, high
- Startup
- 2 of 5, low
- Productivity
- 5 of 5, very high
- Safety
- 5 of 5, very high
- Ecosystem
- 4 of 5, high
- Ease of learning
- 4 of 5, high
- Tooling
- 5 of 5, very high
- Ease of deployment
- 3 of 5, medium
- AI / data fit
- 2 of 5, low
- Web fit
- 2 of 5, low
- Cloud fit
- 4 of 5, high
- Systems fit
- 2 of 5, low
- Mobile fit
- 5 of 5, very high
The scale is heuristic and contextual — it is not a benchmark or a judgement of a language’s ‘quality’.
C#
Status: MatureA versatile .NET language with very good tooling, strong in enterprise, Azure, desktop and Unity.
- Static
- .NET JIT / Native AOT
- GC
- Performance
- 4 of 5, high
- Productivity
- 5 of 5, very high
- Safety
- 4 of 5, high
Full profile: C#
A versatile .NET language with very good tooling, strong in enterprise, Azure, desktop and Unity.
- Philosophy
- Productivity and strong abstractions on a mature runtime with a wide range of applications.
- Typing
- Static
- Execution
- .NET JIT / Native AOT
- Memory
- GC
- Concurrency
- Threads, Tasks, async/await
- Poor fit
- Kernel/firmware and ultra-minimal embedded.
Qualitative profile
- Performance
- 4 of 5, high
- Startup
- 3 of 5, medium
- Productivity
- 5 of 5, very high
- Safety
- 4 of 5, high
- Ecosystem
- 5 of 5, very high
- Ease of learning
- 4 of 5, high
- Tooling
- 5 of 5, very high
- Ease of deployment
- 4 of 5, high
- AI / data fit
- 3 of 5, medium
- Web fit
- 3 of 5, medium
- Cloud fit
- 5 of 5, very high
- Systems fit
- 2 of 5, low
- Mobile fit
- 3 of 5, medium
The scale is heuristic and contextual — it is not a benchmark or a judgement of a language’s ‘quality’.
Python
Status: MatureThe dominant language of AI/data/automation; its strength is the ecosystem and speed of development, not raw scalar CPU.
- Dynamic + optional hints
- VM / interpreter; native extensions
- Reference counting + GC
- Performance
- 2 of 5, low
- Productivity
- 5 of 5, very high
- Safety
- 4 of 5, high
Full profile: Python
The dominant language of AI/data/automation; its strength is the ecosystem and speed of development, not raw scalar CPU.
- Philosophy
- Readability, simplicity and fast iteration; performance is often delegated to native libraries.
- Typing
- Dynamic + optional hints
- Execution
- VM / interpreter; native extensions
- Memory
- Reference counting + GC
- Concurrency
- Threads, async, multiprocessing; free-threaded builds
- Poor fit
- Hard real-time, game engine, kernel, hot CPU loops without native extensions.
Qualitative profile
- Performance
- 2 of 5, low
- Startup
- 4 of 5, high
- Productivity
- 5 of 5, very high
- Safety
- 4 of 5, high
- Ecosystem
- 5 of 5, very high
- Ease of learning
- 5 of 5, very high
- Tooling
- 5 of 5, very high
- Ease of deployment
- 3 of 5, medium
- AI / data fit
- 5 of 5, very high
- Web fit
- 3 of 5, medium
- Cloud fit
- 4 of 5, high
- Systems fit
- 1 of 5, very low
- Mobile fit
- 1 of 5, very low
The scale is heuristic and contextual — it is not a benchmark or a judgement of a language’s ‘quality’.
JavaScript
Status: MatureThe universal runtime of the browser and one of the foundations of the web; a huge ecosystem.
- Dynamic
- JIT / browser or Node runtime
- GC
- Performance
- 3 of 5, medium
- Productivity
- 5 of 5, very high
- Safety
- 3 of 5, medium
Full profile: JavaScript
The universal runtime of the browser and one of the foundations of the web; a huge ecosystem.
- Philosophy
- Dynamism and the ubiquity of the web platform.
- Typing
- Dynamic
- Execution
- JIT / browser or Node runtime
- Memory
- GC
- Concurrency
- Event loop + async; workers
- Poor fit
- Hard real-time, kernel, HFT and systems that require strong compile-time guarantees.
Qualitative profile
- Performance
- 3 of 5, medium
- Startup
- 4 of 5, high
- Productivity
- 5 of 5, very high
- Safety
- 3 of 5, medium
- Ecosystem
- 5 of 5, very high
- Ease of learning
- 5 of 5, very high
- Tooling
- 5 of 5, very high
- Ease of deployment
- 4 of 5, high
- AI / data fit
- 3 of 5, medium
- Web fit
- 5 of 5, very high
- Cloud fit
- 4 of 5, high
- Systems fit
- 1 of 5, very low
- Mobile fit
- 4 of 5, high
The scale is heuristic and contextual — it is not a benchmark or a judgement of a language’s ‘quality’.
TypeScript
Status: GrowingStatic guardrails and tooling for the JavaScript ecosystem; a key language of modern web/full-stack.
- Static structural (compile-time)
- Transpiles / runs as JavaScript
- GC via JS runtime
- Performance
- 3 of 5, medium
- Productivity
- 5 of 5, very high
- Safety
- 4 of 5, high
Full profile: TypeScript
Static guardrails and tooling for the JavaScript ecosystem; a key language of modern web/full-stack.
- Philosophy
- JavaScript that scales: types without giving up interoperability with existing JS.
- Typing
- Static structural (compile-time)
- Execution
- Transpiles / runs as JavaScript
- Memory
- GC via JS runtime
- Concurrency
- JS event loop + async / workers
- Poor fit
- Kernel, firmware, HPC kernels and hard real-time.
Qualitative profile
- Performance
- 3 of 5, medium
- Startup
- 4 of 5, high
- Productivity
- 5 of 5, very high
- Safety
- 4 of 5, high
- Ecosystem
- 5 of 5, very high
- Ease of learning
- 4 of 5, high
- Tooling
- 5 of 5, very high
- Ease of deployment
- 4 of 5, high
- AI / data fit
- 4 of 5, high
- Web fit
- 5 of 5, very high
- Cloud fit
- 4 of 5, high
- Systems fit
- 1 of 5, very low
- Mobile fit
- 4 of 5, high
The scale is heuristic and contextual — it is not a benchmark or a judgement of a language’s ‘quality’.
Swift
Status: MatureA modern native language for Apple with a strong type system and growing concurrency-safety guarantees.
- Static
- Native AOT
- ARC
- Performance
- 5 of 5, very high
- Productivity
- 4 of 5, high
- Safety
- 5 of 5, very high
Full profile: Swift
A modern native language for Apple with a strong type system and growing concurrency-safety guarantees.
- Philosophy
- Safer, expressive native programming for Apple platforms.
- Typing
- Static
- Execution
- Native AOT
- Memory
- ARC
- Concurrency
- async/await, actors, structured concurrency
- Poor fit
- Cross-platform backend, if the organisation is not tied to the Apple ecosystem.
Qualitative profile
- Performance
- 5 of 5, very high
- Startup
- 5 of 5, very high
- Productivity
- 4 of 5, high
- Safety
- 5 of 5, very high
- Ecosystem
- 3 of 5, medium
- Ease of learning
- 4 of 5, high
- Tooling
- 5 of 5, very high
- Ease of deployment
- 3 of 5, medium
- AI / data fit
- 1 of 5, very low
- Web fit
- 1 of 5, very low
- Cloud fit
- 2 of 5, low
- Systems fit
- 3 of 5, medium
- Mobile fit
- 5 of 5, very high
The scale is heuristic and contextual — it is not a benchmark or a judgement of a language’s ‘quality’.
Objective-C
Status: Legacy / decliningThe historical foundation of Cocoa; important mainly for the maintenance and interoperability of older Apple applications.
- Static/dynamic runtime mix
- Native AOT
- ARC / manual legacy
- Performance
- 4 of 5, high
- Productivity
- 2 of 5, low
- Safety
- 2 of 5, low
Full profile: Objective-C
The historical foundation of Cocoa; important mainly for the maintenance and interoperability of older Apple applications.
- Philosophy
- Smalltalk-style messaging on a C/Objective-C runtime.
- Typing
- Static/dynamic runtime mix
- Execution
- Native AOT
- Memory
- ARC / manual legacy
- Concurrency
- GCD / threads
- Poor fit
- New greenfield Apple applications with no legacy-compatibility requirement.
Qualitative profile
- Performance
- 4 of 5, high
- Startup
- 5 of 5, very high
- Productivity
- 2 of 5, low
- Safety
- 2 of 5, low
- Ecosystem
- 3 of 5, medium
- Ease of learning
- 2 of 5, low
- Tooling
- 4 of 5, high
- Ease of deployment
- 3 of 5, medium
- AI / data fit
- 1 of 5, very low
- Web fit
- 1 of 5, very low
- Cloud fit
- 1 of 5, very low
- Systems fit
- 2 of 5, low
- Mobile fit
- 3 of 5, medium
The scale is heuristic and contextual — it is not a benchmark or a judgement of a language’s ‘quality’.
PHP
Status: MatureA very mature web ecosystem; still a huge production base and fast time-to-market.
- Dynamic / gradual features
- VM/JIT
- GC/ref counting
- Performance
- 3 of 5, medium
- Productivity
- 5 of 5, very high
- Safety
- 3 of 5, medium
Full profile: PHP
A very mature web ecosystem; still a huge production base and fast time-to-market.
- Philosophy
- Pragmatic building of web applications and simple deployment.
- Typing
- Dynamic / gradual features
- Execution
- VM/JIT
- Memory
- GC/ref counting
- Concurrency
- Process/request models, async frameworks
- Poor fit
- Systems/HPC/embedded and low-latency workloads.
Qualitative profile
- Performance
- 3 of 5, medium
- Startup
- 4 of 5, high
- Productivity
- 5 of 5, very high
- Safety
- 3 of 5, medium
- Ecosystem
- 5 of 5, very high
- Ease of learning
- 5 of 5, very high
- Tooling
- 4 of 5, high
- Ease of deployment
- 5 of 5, very high
- AI / data fit
- 1 of 5, very low
- Web fit
- 5 of 5, very high
- Cloud fit
- 3 of 5, medium
- Systems fit
- 1 of 5, very low
- Mobile fit
- 1 of 5, very low
The scale is heuristic and contextual — it is not a benchmark or a judgement of a language’s ‘quality’.
Ruby
Status: Legacy / decliningA very productive language associated with Rails; still great for part of SaaS, though with less momentum.
- Dynamic
- VM/JIT options
- GC
- Performance
- 2 of 5, low
- Productivity
- 5 of 5, very high
- Safety
- 3 of 5, medium
Full profile: Ruby
A very productive language associated with Rails; still great for part of SaaS, though with less momentum.
- Philosophy
- Programmer happiness, expressiveness and building a product quickly.
- Typing
- Dynamic
- Execution
- VM/JIT options
- Memory
- GC
- Concurrency
- Threads/fibers; runtime-dependent
- Poor fit
- HPC, embedded and very low latency.
Qualitative profile
- Performance
- 2 of 5, low
- Startup
- 3 of 5, medium
- Productivity
- 5 of 5, very high
- Safety
- 3 of 5, medium
- Ecosystem
- 4 of 5, high
- Ease of learning
- 5 of 5, very high
- Tooling
- 4 of 5, high
- Ease of deployment
- 3 of 5, medium
- AI / data fit
- 1 of 5, very low
- Web fit
- 4 of 5, high
- Cloud fit
- 3 of 5, medium
- Systems fit
- 1 of 5, very low
- Mobile fit
- 1 of 5, very low
The scale is heuristic and contextual — it is not a benchmark or a judgement of a language’s ‘quality’.
Scala
Status: MatureAn advanced JVM language that combines FP and OOP, important in, among other areas, part of the data/Spark ecosystem.
- Static
- JVM JIT
- GC
- Performance
- 4 of 5, high
- Productivity
- 3 of 5, medium
- Safety
- 5 of 5, very high
Full profile: Scala
An advanced JVM language that combines FP and OOP, important in, among other areas, part of the data/Spark ecosystem.
- Philosophy
- A highly expressive type model and functional programming with JVM interoperability.
- Typing
- Static
- Execution
- JVM JIT
- Memory
- GC
- Concurrency
- JVM + functional concurrency ecosystems
- Poor fit
- Simple teams, where the complexity of the language will make onboarding harder.
Qualitative profile
- Performance
- 4 of 5, high
- Startup
- 2 of 5, low
- Productivity
- 3 of 5, medium
- Safety
- 5 of 5, very high
- Ecosystem
- 4 of 5, high
- Ease of learning
- 1 of 5, very low
- Tooling
- 4 of 5, high
- Ease of deployment
- 3 of 5, medium
- AI / data fit
- 2 of 5, low
- Web fit
- 2 of 5, low
- Cloud fit
- 4 of 5, high
- Systems fit
- 1 of 5, very low
- Mobile fit
- 1 of 5, very low
The scale is heuristic and contextual — it is not a benchmark or a judgement of a language’s ‘quality’.
Elixir
Status: MatureAn excellent model of concurrency and fault tolerance on BEAM for realtime and distributed systems.
- Dynamic
- BEAM VM
- GC per process
- Performance
- 3 of 5, medium
- Productivity
- 4 of 5, high
- Safety
- 4 of 5, high
Full profile: Elixir
An excellent model of concurrency and fault tolerance on BEAM for realtime and distributed systems.
- Philosophy
- Let it crash, process isolation, message passing and system resilience.
- Typing
- Dynamic
- Execution
- BEAM VM
- Memory
- GC per process
- Concurrency
- Actor-like isolated processes
- Poor fit
- CPU-heavy HPC and low-level components.
Qualitative profile
- Performance
- 3 of 5, medium
- Startup
- 2 of 5, low
- Productivity
- 4 of 5, high
- Safety
- 4 of 5, high
- Ecosystem
- 3 of 5, medium
- Ease of learning
- 4 of 5, high
- Tooling
- 4 of 5, high
- Ease of deployment
- 3 of 5, medium
- AI / data fit
- 1 of 5, very low
- Web fit
- 3 of 5, medium
- Cloud fit
- 4 of 5, high
- Systems fit
- 1 of 5, very low
- Mobile fit
- 1 of 5, very low
The scale is heuristic and contextual — it is not a benchmark or a judgement of a language’s ‘quality’.
Erlang
Status: MatureThe classic language of telecommunications systems and highly resilient distributed services.
- Dynamic
- BEAM VM
- GC per process
- Performance
- 3 of 5, medium
- Productivity
- 3 of 5, medium
- Safety
- 4 of 5, high
Full profile: Erlang
The classic language of telecommunications systems and highly resilient distributed services.
- Philosophy
- Fault tolerance, hot upgrades, supervision and massive concurrency.
- Typing
- Dynamic
- Execution
- BEAM VM
- Memory
- GC per process
- Concurrency
- Actor-like processes
- Poor fit
- UI, data science and HPC kernels.
Qualitative profile
- Performance
- 3 of 5, medium
- Startup
- 2 of 5, low
- Productivity
- 3 of 5, medium
- Safety
- 4 of 5, high
- Ecosystem
- 3 of 5, medium
- Ease of learning
- 3 of 5, medium
- Tooling
- 3 of 5, medium
- Ease of deployment
- 3 of 5, medium
- AI / data fit
- 1 of 5, very low
- Web fit
- 2 of 5, low
- Cloud fit
- 4 of 5, high
- Systems fit
- 1 of 5, very low
- Mobile fit
- 1 of 5, very low
The scale is heuristic and contextual — it is not a benchmark or a judgement of a language’s ‘quality’.
Haskell
Status: MatureA purely functional language with a very strong type system; great for learning formal domain modelling.
- Static advanced
- Native / runtime
- GC
- Performance
- 4 of 5, high
- Productivity
- 3 of 5, medium
- Safety
- 5 of 5, very high
Full profile: Haskell
A purely functional language with a very strong type system; great for learning formal domain modelling.
- Philosophy
- Pure functions, algebraic types, composability and moving invariants into types.
- Typing
- Static advanced
- Execution
- Native / runtime
- Memory
- GC
- Concurrency
- Lightweight threads, STM, async abstractions
- Poor fit
- Teams without FP expertise and products that need mainstream hiring/ecosystem.
Qualitative profile
- Performance
- 4 of 5, high
- Startup
- 3 of 5, medium
- Productivity
- 3 of 5, medium
- Safety
- 5 of 5, very high
- Ecosystem
- 3 of 5, medium
- Ease of learning
- 1 of 5, very low
- Tooling
- 3 of 5, medium
- Ease of deployment
- 3 of 5, medium
- AI / data fit
- 1 of 5, very low
- Web fit
- 2 of 5, low
- Cloud fit
- 2 of 5, low
- Systems fit
- 2 of 5, low
- Mobile fit
- 1 of 5, very low
The scale is heuristic and contextual — it is not a benchmark or a judgement of a language’s ‘quality’.
OCaml
Status: MatureA pragmatic ML-family language used in, among other areas, compiler tooling and finance.
- Static
- Native / bytecode
- GC
- Performance
- 4 of 5, high
- Productivity
- 4 of 5, high
- Safety
- 5 of 5, very high
Full profile: OCaml
A pragmatic ML-family language used in, among other areas, compiler tooling and finance.
- Philosophy
- Strong types, algebraic data types and efficient, practical functional programming.
- Typing
- Static
- Execution
- Native / bytecode
- Memory
- GC
- Concurrency
- Domains/effects ecosystem
- Poor fit
- Mainstream web/mobile, when the ecosystem and hiring are critical.
Qualitative profile
- Performance
- 4 of 5, high
- Startup
- 4 of 5, high
- Productivity
- 4 of 5, high
- Safety
- 5 of 5, very high
- Ecosystem
- 2 of 5, low
- Ease of learning
- 3 of 5, medium
- Tooling
- 3 of 5, medium
- Ease of deployment
- 4 of 5, high
- AI / data fit
- 1 of 5, very low
- Web fit
- 2 of 5, low
- Cloud fit
- 2 of 5, low
- Systems fit
- 2 of 5, low
- Mobile fit
- 1 of 5, very low
The scale is heuristic and contextual — it is not a benchmark or a judgement of a language’s ‘quality’.
F#
Status: MatureA functional-first .NET language with very good domain modelling and full access to the .NET ecosystem.
- Static
- .NET JIT/AOT
- GC
- Performance
- 4 of 5, high
- Productivity
- 4 of 5, high
- Safety
- 5 of 5, very high
Full profile: F#
A functional-first .NET language with very good domain modelling and full access to the .NET ecosystem.
- Philosophy
- ML-style functional programming on the industrial .NET runtime.
- Typing
- Static
- Execution
- .NET JIT/AOT
- Memory
- GC
- Concurrency
- Async/task + .NET
- Poor fit
- Systems/embedded and projects where hiring calls for mainstream C#.
Qualitative profile
- Performance
- 4 of 5, high
- Startup
- 3 of 5, medium
- Productivity
- 4 of 5, high
- Safety
- 5 of 5, very high
- Ecosystem
- 4 of 5, high
- Ease of learning
- 3 of 5, medium
- Tooling
- 4 of 5, high
- Ease of deployment
- 4 of 5, high
- AI / data fit
- 2 of 5, low
- Web fit
- 2 of 5, low
- Cloud fit
- 4 of 5, high
- Systems fit
- 1 of 5, very low
- Mobile fit
- 1 of 5, very low
The scale is heuristic and contextual — it is not a benchmark or a judgement of a language’s ‘quality’.
Julia
Status: MatureA language designed for numerical/scientific computing, with the ability to reach very high performance.
- Dynamic with specialization
- LLVM JIT
- GC
- Performance
- 5 of 5, very high
- Productivity
- 4 of 5, high
- Safety
- 3 of 5, medium
Full profile: Julia
A language designed for numerical/scientific computing, with the ability to reach very high performance.
- Philosophy
- Dynamic ergonomics without forcing the ‘two-language problem’ on numerical computing.
- Typing
- Dynamic with specialization
- Execution
- LLVM JIT
- Memory
- GC
- Concurrency
- Threads, tasks, distributed computing
- Poor fit
- Mainstream web/mobile/enterprise, when the breadth of the ecosystem matters.
Qualitative profile
- Performance
- 5 of 5, very high
- Startup
- 2 of 5, low
- Productivity
- 4 of 5, high
- Safety
- 3 of 5, medium
- Ecosystem
- 3 of 5, medium
- Ease of learning
- 4 of 5, high
- Tooling
- 3 of 5, medium
- Ease of deployment
- 2 of 5, low
- AI / data fit
- 4 of 5, high
- Web fit
- 1 of 5, very low
- Cloud fit
- 2 of 5, low
- Systems fit
- 1 of 5, very low
- Mobile fit
- 1 of 5, very low
The scale is heuristic and contextual — it is not a benchmark or a judgement of a language’s ‘quality’.
R
Status: MatureA language and environment with exceptional strength in statistics, data analysis and academic workflows.
- Dynamic
- Interpreter + native extensions
- GC
- Performance
- 2 of 5, low
- Productivity
- 5 of 5, very high
- Safety
- 3 of 5, medium
Full profile: R
A language and environment with exceptional strength in statistics, data analysis and academic workflows.
- Philosophy
- Statistical computing, exploratory analysis and a rich package ecosystem.
- Typing
- Dynamic
- Execution
- Interpreter + native extensions
- Memory
- GC
- Concurrency
- Packages / parallel backends
- Poor fit
- General-purpose backend, systems and mobile applications.
Qualitative profile
- Performance
- 2 of 5, low
- Startup
- 3 of 5, medium
- Productivity
- 5 of 5, very high
- Safety
- 3 of 5, medium
- Ecosystem
- 5 of 5, very high
- Ease of learning
- 4 of 5, high
- Tooling
- 4 of 5, high
- Ease of deployment
- 2 of 5, low
- AI / data fit
- 4 of 5, high
- Web fit
- 1 of 5, very low
- Cloud fit
- 1 of 5, very low
- Systems fit
- 1 of 5, very low
- Mobile fit
- 1 of 5, very low
The scale is heuristic and contextual — it is not a benchmark or a judgement of a language’s ‘quality’.
Dart
Status: MatureBest known as the language of Flutter, for consistent cross-platform applications.
- Static
- JIT + AOT
- GC
- Performance
- 4 of 5, high
- Productivity
- 5 of 5, very high
- Safety
- 4 of 5, high
Full profile: Dart
Best known as the language of Flutter, for consistent cross-platform applications.
- Philosophy
- Fast UI development and the option of JIT in development / AOT in production.
- Typing
- Static
- Execution
- JIT + AOT
- Memory
- GC
- Concurrency
- Isolates + async
- Poor fit
- Low-level systems, HPC and cloud infra as the default choice.
Qualitative profile
- Performance
- 4 of 5, high
- Startup
- 4 of 5, high
- Productivity
- 5 of 5, very high
- Safety
- 4 of 5, high
- Ecosystem
- 3 of 5, medium
- Ease of learning
- 5 of 5, very high
- Tooling
- 5 of 5, very high
- Ease of deployment
- 4 of 5, high
- AI / data fit
- 1 of 5, very low
- Web fit
- 3 of 5, medium
- Cloud fit
- 2 of 5, low
- Systems fit
- 1 of 5, very low
- Mobile fit
- 5 of 5, very high
The scale is heuristic and contextual — it is not a benchmark or a judgement of a language’s ‘quality’.
Lua
Status: MatureA small, easily embeddable scripting language, popular in game scripting and extensible applications.
- Dynamic
- VM/JIT depending implementation
- GC
- Performance
- 3 of 5, medium
- Productivity
- 4 of 5, high
- Safety
- 3 of 5, medium
Full profile: Lua
A small, easily embeddable scripting language, popular in game scripting and extensible applications.
- Philosophy
- A minimal core and very good embeddability.
- Typing
- Dynamic
- Execution
- VM/JIT depending implementation
- Memory
- GC
- Concurrency
- Coroutines / host-dependent
- Poor fit
- Large general-purpose systems that require broad tooling/ecosystem.
Qualitative profile
- Performance
- 3 of 5, medium
- Startup
- 5 of 5, very high
- Productivity
- 4 of 5, high
- Safety
- 3 of 5, medium
- Ecosystem
- 3 of 5, medium
- Ease of learning
- 5 of 5, very high
- Tooling
- 3 of 5, medium
- Ease of deployment
- 5 of 5, very high
- AI / data fit
- 1 of 5, very low
- Web fit
- 1 of 5, very low
- Cloud fit
- 1 of 5, very low
- Systems fit
- 1 of 5, very low
- Mobile fit
- 1 of 5, very low
The scale is heuristic and contextual — it is not a benchmark or a judgement of a language’s ‘quality’.
Mojo
Status: EmergingMojo 1.0 (2026) targets AI/HPC and heterogeneous compute, combining Python-inspired ergonomics with low-level control.
- Static-oriented
- Native / MLIR stack
- Ownership/value-oriented model
- Performance
- 5 of 5, very high
- Productivity
- 4 of 5, high
- Safety
- 4 of 5, high
Full profile: Mojo
Mojo 1.0 (2026) targets AI/HPC and heterogeneous compute, combining Python-inspired ergonomics with low-level control.
- Philosophy
- One language from high-level AI logic to performance-critical kernels on different hardware.
- Typing
- Static-oriented
- Execution
- Native / MLIR stack
- Memory
- Ownership/value-oriented model
- Concurrency
- Parallel/accelerator-oriented
- Poor fit
- Mainstream enterprise/web, until the ecosystem reaches the maturity of the existing platforms.
Qualitative profile
- Performance
- 5 of 5, very high
- Startup
- 5 of 5, very high
- Productivity
- 4 of 5, high
- Safety
- 4 of 5, high
- Ecosystem
- 2 of 5, low
- Ease of learning
- 3 of 5, medium
- Tooling
- 3 of 5, medium
- Ease of deployment
- 3 of 5, medium
- AI / data fit
- 5 of 5, very high
- Web fit
- 1 of 5, very low
- Cloud fit
- 2 of 5, low
- Systems fit
- 4 of 5, high
- Mobile fit
- 1 of 5, very low
The scale is heuristic and contextual — it is not a benchmark or a judgement of a language’s ‘quality’.
Gleam
Status: EmergingA small, strongly typed functional language aiming for ergonomics on BEAM, with the option of targeting JavaScript.
- Static
- BEAM / JavaScript target
- GC via target
- Performance
- 3 of 5, medium
- Productivity
- 4 of 5, high
- Safety
- 5 of 5, very high
Full profile: Gleam
A small, strongly typed functional language aiming for ergonomics on BEAM, with the option of targeting JavaScript.
- Philosophy
- Approachable FP, good error messages and safe types without elaborate complexity.
- Typing
- Static
- Execution
- BEAM / JavaScript target
- Memory
- GC via target
- Concurrency
- BEAM processes / target model
- Poor fit
- Systems/HPC/embedded.
Qualitative profile
- Performance
- 3 of 5, medium
- Startup
- 2 of 5, low
- Productivity
- 4 of 5, high
- Safety
- 5 of 5, very high
- Ecosystem
- 2 of 5, low
- Ease of learning
- 4 of 5, high
- Tooling
- 4 of 5, high
- Ease of deployment
- 3 of 5, medium
- AI / data fit
- 1 of 5, very low
- Web fit
- 3 of 5, medium
- Cloud fit
- 3 of 5, medium
- Systems fit
- 1 of 5, very low
- Mobile fit
- 1 of 5, very low
The scale is heuristic and contextual — it is not a benchmark or a judgement of a language’s ‘quality’.
Odin
Status: EmergingA systems language with an emphasis on simplicity, data-oriented design and game/graphics workloads.
- Static
- Native AOT
- Manual
- Performance
- 5 of 5, very high
- Productivity
- 3 of 5, medium
- Safety
- 2 of 5, low
Full profile: Odin
A systems language with an emphasis on simplicity, data-oriented design and game/graphics workloads.
- Philosophy
- Simple native programming without an elaborate abstraction layer.
- Typing
- Static
- Execution
- Native AOT
- Memory
- Manual
- Concurrency
- Low-level / libraries
- Poor fit
- Enterprise/web with a requirement for a broad ecosystem and stability.
Qualitative profile
- Performance
- 5 of 5, very high
- Startup
- 5 of 5, very high
- Productivity
- 3 of 5, medium
- Safety
- 2 of 5, low
- Ecosystem
- 1 of 5, very low
- Ease of learning
- 3 of 5, medium
- Tooling
- 2 of 5, low
- Ease of deployment
- 4 of 5, high
- AI / data fit
- 1 of 5, very low
- Web fit
- 1 of 5, very low
- Cloud fit
- 1 of 5, very low
- Systems fit
- 4 of 5, high
- Mobile fit
- 1 of 5, very low
The scale is heuristic and contextual — it is not a benchmark or a judgement of a language’s ‘quality’.
Roc
Status: ExperimentalAn experimental functional language built on the concept of application + platform; still a high production risk.
- Static
- Native-oriented platform model
- Managed by platform/runtime design
- Performance
- 3 of 5, medium
- Productivity
- 3 of 5, medium
- Safety
- 5 of 5, very high
Full profile: Roc
An experimental functional language built on the concept of application + platform; still a high production risk.
- Philosophy
- Simple functional programming and the separation of application logic from platform capabilities.
- Typing
- Static
- Execution
- Native-oriented platform model
- Memory
- Managed by platform/runtime design
- Concurrency
- Platform-defined
- Poor fit
- Key products that require a stable ecosystem, hiring and long-term support.
Qualitative profile
- Performance
- 3 of 5, medium
- Startup
- 4 of 5, high
- Productivity
- 3 of 5, medium
- Safety
- 5 of 5, very high
- Ecosystem
- 1 of 5, very low
- Ease of learning
- 3 of 5, medium
- Tooling
- 2 of 5, low
- Ease of deployment
- 2 of 5, low
- AI / data fit
- 1 of 5, very low
- Web fit
- 1 of 5, very low
- Cloud fit
- 1 of 5, very low
- Systems fit
- 1 of 5, very low
- Mobile fit
- 1 of 5, very low
The scale is heuristic and contextual — it is not a benchmark or a judgement of a language’s ‘quality’.
Carbon
Status: ExperimentalAn experimental C++ successor project with an emphasis on interoperability; officially still not ready for production use.
- Static
- Native / LLVM-oriented
- Evolving; safer direction
- Performance
- 5 of 5, very high
- Productivity
- 2 of 5, low
- Safety
- 3 of 5, medium
Full profile: Carbon
An experimental C++ successor project with an emphasis on interoperability; officially still not ready for production use.
- Philosophy
- An evolutionary path for organisations with a large C++ codebase, without the need for a ‘clean break’.
- Typing
- Static
- Execution
- Native / LLVM-oriented
- Memory
- Evolving; safer direction
- Concurrency
- Experimental
- Poor fit
- Production that requires a stable language and toolchain.
Qualitative profile
- Performance
- 5 of 5, very high
- Startup
- 5 of 5, very high
- Productivity
- 2 of 5, low
- Safety
- 3 of 5, medium
- Ecosystem
- 1 of 5, very low
- Ease of learning
- 2 of 5, low
- Tooling
- 1 of 5, very low
- Ease of deployment
- 1 of 5, very low
- AI / data fit
- 1 of 5, very low
- Web fit
- 1 of 5, very low
- Cloud fit
- 1 of 5, very low
- Systems fit
- 2 of 5, low
- Mobile fit
- 1 of 5, very low
The scale is heuristic and contextual — it is not a benchmark or a judgement of a language’s ‘quality’.
V
Status: ExperimentalAn ambitious, compact general-purpose language; still much smaller adoption and ecosystem than Go/Rust/Zig.
- Static
- Native / transpilation toolchain
- Managed/manual mix depending mode
- Performance
- 4 of 5, high
- Productivity
- 4 of 5, high
- Safety
- 3 of 5, medium
Full profile: V
An ambitious, compact general-purpose language; still much smaller adoption and ecosystem than Go/Rust/Zig.
- Philosophy
- Simplicity, fast compilation and a small language.
- Typing
- Static
- Execution
- Native / transpilation toolchain
- Memory
- Managed/manual mix depending mode
- Concurrency
- Threads / channels style
- Poor fit
- Strategic enterprise systems with no tolerance for the risk of a young ecosystem.
Qualitative profile
- Performance
- 4 of 5, high
- Startup
- 5 of 5, very high
- Productivity
- 4 of 5, high
- Safety
- 3 of 5, medium
- Ecosystem
- 1 of 5, very low
- Ease of learning
- 5 of 5, very high
- Tooling
- 2 of 5, low
- Ease of deployment
- 3 of 5, medium
- AI / data fit
- 1 of 5, very low
- Web fit
- 1 of 5, very low
- Cloud fit
- 2 of 5, low
- Systems fit
- 2 of 5, low
- Mobile fit
- 1 of 5, very low
The scale is heuristic and contextual — it is not a benchmark or a judgement of a language’s ‘quality’.
Nothing selected
Select at least 2 to compare.
You can compare up to 4 languages. Remove one to add another.
Performance
CPU, latency, startup, memory, GC and predictability are separate axes. The heatmap below is heuristic — not a benchmark.
Evidence: Benchmark-dependent Context > a single result
| Language | Raw CPU | Startup | Memory / controlEvidence: Interpretation | PredictabilityEvidence: Interpretation | Comment |
|---|---|---|---|---|---|
| C | Manual control; the result depends on the quality of the implementation. | ||||
| C++ | A very high ceiling; complexity and UB can increase the maintenance cost. | ||||
| Rust | Native performance without GC; ownership increases predictability. | ||||
| Zig | Native and explicit control; a younger toolchain/ecosystem. | ||||
| Go | Good throughput/concurrency; GC can matter for some latency-sensitive workloads. | ||||
| Java | JIT can reach very high performance after warm-up; GC/runtime affect the profile. | ||||
| C# | JIT + Native AOT; a very strong modern runtime. | ||||
| Swift | Native and ARC; especially strong in the Apple ecosystem. | ||||
| Julia | JIT specialisation can give very high performance for numerical code. | ||||
| Python | Pure scalar Python is slow; native/GPU libraries change the real profile. | ||||
| JavaScript | V8/JIT can be fast, but dynamic semantics/GC make predictability harder. | ||||
| TypeScript | The runtime is JavaScript; performance depends on the JS engine and the generated code. |
Raw CPU and Startup are the languages’ performance and startup ratings from the explorer.
Memory / control: Heuristic carried over from the original atlas: 5 (very high) for C, C++, Rust and Zig; for every other language, 3 (medium) if its safety rating is 4 or higher, otherwise 2 (low). It is a judgement, not a measurement.
Predictability: Heuristic carried over from the original atlas: 5 (very high) for C, C++, Rust and Zig; 3 (medium) for Go, Java and C#; 2 (low) for the other languages in the table. It is a judgement, not a measurement.
Native ceiling
Evidence: Benchmark-dependentC / C++ / Rust / Zig have the highest ceiling for hand-tuned native code. The differences depend on the algorithm, compiler flags, SIMD and data layout.
JIT can be extremely fast
Evidence: Benchmark-dependentJava / C# / JavaScript benefit from advanced JITs. Warm-up and GC, however, change the latency/startup profile.
Python paradox
Evidence: Benchmark-dependentPure Python scalar code is slow, but in AI/data Python can be the control plane for highly optimised native/GPU libraries.
Developer productivity
An interactive break-even model. It is an educational tool, not a financial model.
Break-even
How it works: Break-even
Additional development cost = max(0, (Rust weeks − Python weeks) × developer cost per week). Infrastructure saving per month = Python infrastructure per month − Rust infrastructure per month. Break-even (months) = additional development cost ÷ monthly saving. With no saving (0 or less) there is no break-even and no cheaper runtime. Below 12 months the rewrite may make sense; from 12 to under 36 months it needs a stable, long horizon; from 36 months, look for a cheaper optimisation first. The model counts one developer; costs are in GBP.
Default assumptions
- Developer cost per week (£)
- £2,000
- Python: development time (weeks)
- 3 weeks
- Rust: development time (weeks)
- 8 weeks
- Python infrastructure per month (£)
- £500
- Rust infrastructure per month (£)
- £250
Results
Evidence: Interpretation- Additional development cost
- £10,000
- Infrastructure saving per month
- £250
- Break-even
- 40.0 months
- Conclusion
- First look for a cheaper optimisation than a rewrite.
Caution
Security and memory safety
A memory-safe language removes classes of memory errors, but it does not prevent SQL injection, broken authentication or a compromised dependency.
Manual memory
C · C++ · Zig
The greatest control, but the language lets you express bugs of the use-after-free, out-of-bounds or dangling-pointer class.
Ownership
Rust
The compiler verifies ownership/borrowing and a large part of memory safety without a tracing GC.
Managed memory
Java · C# · Go · Kotlin
A GC/managed runtime eliminates a large class of manual lifetime errors.
Dynamic managed
Python · JS · Ruby
Memory safe in typical application code, but dynamic errors move to runtime more often.
| Problem class | C/C++ | Safe Rust | Java/C#/Go | Python/TypeScript | Is the language enough? |
|---|---|---|---|---|---|
| Buffer overflow / invalid memory access | Risk | Strong guardrails | Strong guardrails | Strong guardrails in managed code | FFI/native code can still open up risk. |
| Use-after-free / dangling pointer | Risk | Largely blocked at compile time | Usually eliminated by the GC | Usually eliminated by the runtime | Unsafe/FFI changes the situation. |
| Data race | Possible | Safe Rust blocks some of the classes | Possible (logically) | The runtime model limits, but does not eliminate, concurrency bugs | A correct synchronisation model is needed. |
| SQL injection / XSS / SSRF | Possible | Possible | Possible | Possible | No. This is application security. |
| Supply-chain compromise | Possible | Possible | Possible | Possible | No. The package ecosystem and security processes are key. |
Verified direction
Memory safety is a strategic trend, not only a stylistic preference.
In 2025 the NSA and CISA jointly stressed the importance of adopting memory-safe languages to reduce software security risk. Evidence: Verified fact Source: NSA + CISA: Memory Safe Languages.
UI / visual apps
Appearance is a function of the framework, the renderer, the design system and the quality of the UX — not of the language’s syntax.
Note
- language
- framework
- rendering engine
- UI toolkit
- design system
- final UX
Web
HTML/CSS + TypeScript
React, Vue, Svelte and other frameworks give the greatest flexibility of web UI.
Apple
Swift + SwiftUI
Native integration with iOS/macOS and the Apple ecosystem.
Android
Kotlin + Compose
Native, modern Android UI.
Cross-platform
Dart + Flutter
A consistent renderer and a very productive mobile/desktop workflow.
Web-tech desktop
TypeScript + Electron or Rust + Tauri + web UI
Sharing frontend skills.
Native / industrial
C++ + Qt, C#/.NET
Mature desktop and cross-platform toolkits.
What are you building?
Choose a use case to see a sensible starting point, the alternatives and the condition that could change the decision.
Automation
- Recommended startRecommendation: Default
- Python
- Good alternatives
- PowerShell, Bash, Go
- Consider if…Recommendation: Specialised
- Go/Rust, when you need a single binary tool or high performance.
- Usually avoid
- C++ for simple scripts with no low-level requirements.
- Main trade-off
- Speed of development vs distribution/footprint.
Why? Python has a very broad automation ecosystem and a low barrier to entry.
Data analysis
- Recommended startRecommendation: Default
- Python + SQL
- Good alternatives
- R, Julia
- Consider if…Recommendation: Specialised
- R for statistics; Julia for intensive numerical computation.
- Usually avoid
- Go as the main notebook workflow.
- Main trade-off
- Analytics ecosystem vs raw performance.
Why? Python/SQL cover most of the practical data stack.
Data science
- Recommended startRecommendation: Default
- Python
- Good alternatives
- R, Julia
- Consider if…Recommendation: Specialised
- Julia, when scientific computing dominates; R in a statistical workflow.
- Usually avoid
- C++ as the main exploration interface.
- Main trade-off
- Productivity and libraries vs low-level control.
Why? The largest ML/data ecosystem and integration with notebooks.
Machine learning
- Recommended startRecommendation: Default
- Python
- Good alternatives
- Julia, C++ for kernels
- Consider if…Recommendation: Specialised
- Rust/C++/Mojo for performance-critical components.
- Usually avoid
- Go as the main training ecosystem.
- Main trade-off
- Framework ecosystem vs performance of the compute layer.
Why? PyTorch/JAX and a vast range of tools are designed around Python.
AI engineering
- Recommended startRecommendation: Default
- Python + TypeScript
- Good alternatives
- C#, Go
- Consider if…Recommendation: Specialised
- Rust/Mojo for performance layers; C# in a Microsoft stack.
- Usually avoid
- A single language for the whole system when there is no need for it.
- Main trade-off
- AI ecosystem vs product/web/infra concerns.
Why? Python dominates model/data, TypeScript product/web and integrations.
LLM application
- Recommended startRecommendation: Default
- Python or TypeScript
- Good alternatives
- C#, Go
- Consider if…Recommendation: Specialised
- Go/C# for services with strong operational requirements.
- Usually avoid
- C/C++ as the main application layer.
- Main trade-off
- Speed of integration vs typing/operations.
Why? Most SDKs, examples and agent frameworks are in Python/TS.
AI agent
- Recommended startRecommendation: Default
- Python or TypeScript
- Good alternatives
- C#, Go
- Consider if…Recommendation: Specialised
- Strongly typed services around the agent, when the workflow becomes business-critical.
- Usually avoid
- A low-level language without an ecosystem of LLM tools.
- Main trade-off
- Experimentation vs deterministic guardrails.
Why? Mature libraries and easy integration with APIs/tool calling.
ETL / data pipeline
- Recommended startRecommendation: Default
- SQL + Python
- Good alternatives
- Java, Scala, Go
- Consider if…Recommendation: Specialised
- Scala/Java for Spark-heavy work; Go for streaming services.
- Usually avoid
- C++ without an exceptional justification.
- Main trade-off
- Data ecosystem vs throughput and operations.
Why? SQL + Python are the most common layer for transformation and orchestration.
REST API
- Recommended startRecommendation: Default
- TypeScript / Python / Go / C# / Java
- Good alternatives
- Kotlin, Rust
- Consider if…Recommendation: Specialised
- Rust with very high latency/memory requirements.
- Usually avoid
- C++ as the default CRUD API.
- Main trade-off
- Productivity vs runtime efficiency.
Why? In this use case the ecosystem and the team’s skills usually outweigh microbenchmarks.
High-performance API
- Recommended startRecommendation: Default
- Go / Rust / Java / C#
- Good alternatives
- C++
- Consider if…Recommendation: Specialised
- Rust/C++ if the cost of GC/latency is a problem confirmed by a profile.
- Usually avoid
- A rewrite based only on a hello-world benchmark.
- Main trade-off
- Throughput/latency vs development complexity.
Why? These runtimes have strong concurrency models and mature servers.
Microservices
- Recommended startRecommendation: Default
- Go / Java / C# / Kotlin
- Good alternatives
- Rust, TypeScript
- Consider if…Recommendation: Specialised
- Elixir for specific realtime/fault-tolerant workloads.
- Usually avoid
- Polyglot chaos without platform governance.
- Main trade-off
- Standardisation vs fitting the language to the workload.
Why? Operations, observability, deployment and hiring matter most.
Distributed systems
- Recommended startRecommendation: Default
- Go / Java / Elixir / Erlang
- Good alternatives
- C#, Rust
- Consider if…Recommendation: Specialised
- Rust for a performance-critical dataplane.
- Usually avoid
- Python in the hot path without measurements and without scaling the layer.
- Main trade-off
- Concurrency/fault tolerance vs simplicity of implementation.
Why? Runtime models and the distributed-system ecosystem matter more than syntax.
SaaS / startup MVP
- Recommended startRecommendation: Default
- TypeScript or Python
- Good alternatives
- Ruby, PHP, C#
- Consider if…Recommendation: Specialised
- Go/Java/C# when operations and scale start to dominate.
- Usually avoid
- Rust/C++ purely because of hype.
- Main trade-off
- Time-to-market vs infrastructure optimisation.
Why? At an early stage the cost of the team usually outweighs the cost of CPU.
Enterprise backend
- Recommended startRecommendation: Default
- Java or C#
- Good alternatives
- Kotlin, Go
- Consider if…Recommendation: Specialised
- Kotlin for JVM modernisation; Go for simple platform services.
- Usually avoid
- Experimental languages without support and a hiring pool.
- Main trade-off
- Longevity/ecosystem vs speed of innovation.
Why? Enterprise rewards stability, tooling, integrations and the availability of developers.
Fintech / business systems
- Recommended startRecommendation: Default
- Java / C#
- Good alternatives
- Kotlin, Go, F#
- Consider if…Recommendation: Specialised
- Rust/C++ in specialised low-latency components.
- Usually avoid
- A young stack without mature auditing/tooling.
- Main trade-off
- Reliability/compliance vs performance.
Why? Mature runtimes and strong tooling are key.
HFT / ultra-low latency
- Recommended startRecommendation: Default
- C++
- Good alternatives
- Rust, very finely tuned Java
- Consider if…Recommendation: Specialised
- Rust, when memory safety carries a lot of weight and the ecosystem fits.
- Usually avoid
- Python/JS in the hot path.
- Main trade-off
- Nanoseconds and predictability vs complexity.
Why? Control of memory, cache, allocations and runtime latency matters.
Cybersecurity tooling
- Recommended startRecommendation: Default
- Python + Rust/Go
- Good alternatives
- C/C++ depending on the layer
- Consider if…Recommendation: Specialised
- C for exploit research and the very low level.
- Usually avoid
- A dogmatic single language.
- Main trade-off
- Fast automation vs safety/performance of the tool.
Why? Python orchestrates very well; Rust/Go produce fast standalone utilities.
OSINT tooling
- Recommended startRecommendation: Default
- Python
- Good alternatives
- TypeScript, Go
- Consider if…Recommendation: Specialised
- Go for crawlers and tools distributed as a binary.
- Usually avoid
- C++ without a low-level reason.
- Main trade-off
- Integrations/API vs throughput.
Why? HTTP, parsing, automation and data integrations dominate.
Embedded / firmware
- Recommended startRecommendation: Default
- C / C++
- Good alternatives
- Rust, Zig
- Consider if…Recommendation: Specialised
- Rust, when memory safety and the toolchain for the target are mature.
- Usually avoid
- A managed runtime without platform support.
- Main trade-off
- Control/footprint vs safety and ergonomics.
Why? Direct access to hardware and a predictable runtime.
Robotics
- Recommended startRecommendation: Default
- C++ + Python
- Good alternatives
- Rust
- Consider if…Recommendation: Specialised
- Rust for new performance/safety-sensitive components.
- Usually avoid
- JavaScript as the main realtime control layer.
- Main trade-off
- ROS ecosystem/algorithms vs safety.
Why? C++ covers realtime/performance, Python prototyping and ML.
Android
- Recommended startRecommendation: Default
- Kotlin
- Good alternatives
- Flutter/Dart, React Native/TypeScript
- Consider if…Recommendation: Specialised
- C++ only for native/performance libraries.
- Usually avoid
- Objective-C/Swift as the main Android stack.
- Main trade-off
- Native vs cross-platform.
Why? Kotlin is the modern platform choice for Android.
iOS / macOS
- Recommended startRecommendation: Default
- Swift
- Good alternatives
- Flutter/Dart, React Native
- Consider if…Recommendation: Specialised
- Objective-C only for legacy interop.
- Usually avoid
- Java as the default native UI stack.
- Main trade-off
- Native integration vs cross-platform.
Why? Swift/SwiftUI are the most naturally integrated with Apple platforms.
Frontend web
- Recommended startRecommendation: Default
- TypeScript
- Good alternatives
- JavaScript
- Consider if…Recommendation: Specialised
- Wasm/Rust for specialised compute modules.
- Usually avoid
- Python as the main browser code.
- Main trade-off
- Guardrails vs simplicity of a prototype.
Why? TypeScript gives static feedback with full access to the web ecosystem.
CLI
- Recommended startRecommendation: Default
- Go or Rust
- Good alternatives
- Python
- Consider if…Recommendation: Specialised
- Python, when the user already has the runtime and speed of writing matters.
- Usually avoid
- The JVM for an ultra-small tool, if cold start/footprint are critical.
- Main trade-off
- Single binary vs development speed.
Why? Go/Rust give easy distribution and fast startup.
Games
- Recommended startRecommendation: Default
- C# (Unity) / C++ (Unreal)
- Good alternatives
- Lua/GDScript, Rust in selected engines
- Consider if…Recommendation: Specialised
- Rust for your own engines/components.
- Usually avoid
- Python in an AAA core engine.
- Main trade-off
- Engine ecosystem vs language.
Why? In game development the engine usually determines the language more than an abstract ranking does.
Database / storage engine
- Recommended startRecommendation: Default
- C++ or Rust
- Good alternatives
- C
- Consider if…Recommendation: Specialised
- Go for higher service layers, not the hot storage engine.
- Usually avoid
- Python in the core engine.
- Main trade-off
- Memory/layout control vs safety.
Why? Cache locality, allocations, I/O and predictability are critical.
HPC / scientific kernels
- Recommended startRecommendation: Default
- C++ / Fortran / Julia
- Good alternatives
- Rust, Mojo, CUDA ecosystem
- Consider if…Recommendation: Specialised
- Mojo as an emerging option for heterogeneous AI compute.
- Usually avoid
- JavaScript for numerical kernels.
- Main trade-off
- Peak performance vs ecosystem and portability.
Why? Vectorisation, GPU and locality dominate.
Serverless
- Recommended startRecommendation: Default
- TypeScript / Python / Go
- Good alternatives
- C# AOT, Java with a suitable runtime
- Consider if…Recommendation: Specialised
- Go/AOT if cold start is a measurable problem.
- Usually avoid
- Optimising the runtime before measuring real cold starts.
- Main trade-off
- Cold start vs developer velocity.
Why? The deployment model and the provider matter more than a language ranking.
Cloud infrastructure / DevOps
- Recommended startRecommendation: Default
- Go + Python
- Good alternatives
- Rust, Bash/PowerShell
- Consider if…Recommendation: Specialised
- Rust for security/performance-sensitive agents.
- Usually avoid
- C++ for typical operator tools.
- Main trade-off
- Standalone binaries vs scripting flexibility.
Why? Go dominates many cloud-native tools; Python speeds up automation.
Which language should I choose? — decision helper
How it works: Which language should I choose? — decision helper
A language is a candidate when one of its use-case tags matches the domain (AI / Data also matches Scientific; Web / SaaS also matches Backend), when it meets the runtime preference (‘Prefer native’: the execution model contains ‘Native’; ‘Managed/GC acceptable’: the memory model contains ‘GC’ or ‘Reference’) and, with ‘Only mature/growing’, when its status is not emerging or experimental. Each candidate scores its rating for the chosen priority × 10 + its ecosystem rating × 3 + its tooling rating × 2 (the original weights 1, 0.3 and 0.2, scaled by 10). The four highest scores are shown; equal scores keep the order of the language list.
| Domain | Matches the use-case tags |
|---|---|
| AI / Data | AI/Data, Scientific |
| Web / SaaS | Web, Backend |
| Cloud / Backend | Cloud |
| Systems | Systems |
| Mobile | Mobile |
| Enterprise | Enterprise |
| Scientific / HPC | Scientific |
Kept from the original on purpose:
- ‘Only mature/growing’ excludes only emerging and experimental languages, so Objective-C, Ruby (Legacy / declining) can still appear.
- ‘Managed/GC acceptable’ needs ‘GC’ or ‘Reference’ in the memory model, so it leaves out the languages with automatic reference counting (ARC): Swift, Objective-C.
- ‘Prefer native’ needs ‘Native’ with a capital N in the execution model, so it leaves out Python, R.
Result for the default choicesDomain: AI / Data · Priority: time-to-market · Runtime: no preference · Risk: Only mature/growing
Without JavaScript, this shows the result for the default choices. The decision matrix gives a starting point for each of the 29 use cases. Go to the decision matrix
Strong candidates
Evidence: InterpretationPythonScore 75
Why: Matches the domain through ‘AI/Data’, ‘Scientific’. Productivity 5 · very high × 10 = 50 (the priority) + ecosystem 5 · very high × 3 = 15 + tooling 5 · very high × 2 = 10 = 75.
RScore 73
Why: Matches the domain through ‘AI/Data’, ‘Scientific’. Productivity 5 · very high × 10 = 50 (the priority) + ecosystem 5 · very high × 3 = 15 + tooling 4 · high × 2 = 8 = 73.
JuliaScore 55
Why: Matches the domain through ‘Scientific’, ‘AI/Data’. Productivity 4 · high × 10 = 40 (the priority) + ecosystem 3 · medium × 3 = 9 + tooling 3 · medium × 2 = 6 = 55.
OCamlScore 52
Why: Matches the domain through ‘Scientific’. Productivity 4 · high × 10 = 40 (the priority) + ecosystem 2 · low × 3 = 6 + tooling 3 · medium × 2 = 6 = 52.
Why: a strong fit for the domain AI / Data with the priority time-to-market. Treat this as a shortlist for further validation of the ecosystem, team skills and deployment. The algorithm is deliberately simple and does not replace an architecture review.
Decision matrix
This is a starting matrix, not an automatic choice of architecture. Evidence: Interpretation
29 use cases
No use cases match these filters.
| Use case | Start | Alternatives | Consider if… | Usually avoid | Main trade-off |
|---|---|---|---|---|---|
| Automation | Python | PowerShell, Bash, Go | Go/Rust, when you need a single binary tool or high performance. | C++ for simple scripts with no low-level requirements. | Speed of development vs distribution/footprint. |
| Data analysis | Python + SQL | R, Julia | R for statistics; Julia for intensive numerical computation. | Go as the main notebook workflow. | Analytics ecosystem vs raw performance. |
| Data science | Python | R, Julia | Julia, when scientific computing dominates; R in a statistical workflow. | C++ as the main exploration interface. | Productivity and libraries vs low-level control. |
| Machine learning | Python | Julia, C++ for kernels | Rust/C++/Mojo for performance-critical components. | Go as the main training ecosystem. | Framework ecosystem vs performance of the compute layer. |
| AI engineering | Python + TypeScript | C#, Go | Rust/Mojo for performance layers; C# in a Microsoft stack. | A single language for the whole system when there is no need for it. | AI ecosystem vs product/web/infra concerns. |
| LLM application | Python or TypeScript | C#, Go | Go/C# for services with strong operational requirements. | C/C++ as the main application layer. | Speed of integration vs typing/operations. |
| AI agent | Python or TypeScript | C#, Go | Strongly typed services around the agent, when the workflow becomes business-critical. | A low-level language without an ecosystem of LLM tools. | Experimentation vs deterministic guardrails. |
| ETL / data pipeline | SQL + Python | Java, Scala, Go | Scala/Java for Spark-heavy work; Go for streaming services. | C++ without an exceptional justification. | Data ecosystem vs throughput and operations. |
| REST API | TypeScript / Python / Go / C# / Java | Kotlin, Rust | Rust with very high latency/memory requirements. | C++ as the default CRUD API. | Productivity vs runtime efficiency. |
| High-performance API | Go / Rust / Java / C# | C++ | Rust/C++ if the cost of GC/latency is a problem confirmed by a profile. | A rewrite based only on a hello-world benchmark. | Throughput/latency vs development complexity. |
| Microservices | Go / Java / C# / Kotlin | Rust, TypeScript | Elixir for specific realtime/fault-tolerant workloads. | Polyglot chaos without platform governance. | Standardisation vs fitting the language to the workload. |
| Distributed systems | Go / Java / Elixir / Erlang | C#, Rust | Rust for a performance-critical dataplane. | Python in the hot path without measurements and without scaling the layer. | Concurrency/fault tolerance vs simplicity of implementation. |
| SaaS / startup MVP | TypeScript or Python | Ruby, PHP, C# | Go/Java/C# when operations and scale start to dominate. | Rust/C++ purely because of hype. | Time-to-market vs infrastructure optimisation. |
| Enterprise backend | Java or C# | Kotlin, Go | Kotlin for JVM modernisation; Go for simple platform services. | Experimental languages without support and a hiring pool. | Longevity/ecosystem vs speed of innovation. |
| Fintech / business systems | Java / C# | Kotlin, Go, F# | Rust/C++ in specialised low-latency components. | A young stack without mature auditing/tooling. | Reliability/compliance vs performance. |
| HFT / ultra-low latency | C++ | Rust, very finely tuned Java | Rust, when memory safety carries a lot of weight and the ecosystem fits. | Python/JS in the hot path. | Nanoseconds and predictability vs complexity. |
| Cybersecurity tooling | Python + Rust/Go | C/C++ depending on the layer | C for exploit research and the very low level. | A dogmatic single language. | Fast automation vs safety/performance of the tool. |
| OSINT tooling | Python | TypeScript, Go | Go for crawlers and tools distributed as a binary. | C++ without a low-level reason. | Integrations/API vs throughput. |
| Embedded / firmware | C / C++ | Rust, Zig | Rust, when memory safety and the toolchain for the target are mature. | A managed runtime without platform support. | Control/footprint vs safety and ergonomics. |
| Robotics | C++ + Python | Rust | Rust for new performance/safety-sensitive components. | JavaScript as the main realtime control layer. | ROS ecosystem/algorithms vs safety. |
| Android | Kotlin | Flutter/Dart, React Native/TypeScript | C++ only for native/performance libraries. | Objective-C/Swift as the main Android stack. | Native vs cross-platform. |
| iOS / macOS | Swift | Flutter/Dart, React Native | Objective-C only for legacy interop. | Java as the default native UI stack. | Native integration vs cross-platform. |
| Frontend web | TypeScript | JavaScript | Wasm/Rust for specialised compute modules. | Python as the main browser code. | Guardrails vs simplicity of a prototype. |
| CLI | Go or Rust | Python | Python, when the user already has the runtime and speed of writing matters. | The JVM for an ultra-small tool, if cold start/footprint are critical. | Single binary vs development speed. |
| Games | C# (Unity) / C++ (Unreal) | Lua/GDScript, Rust in selected engines | Rust for your own engines/components. | Python in an AAA core engine. | Engine ecosystem vs language. |
| Database / storage engine | C++ or Rust | C | Go for higher service layers, not the hot storage engine. | Python in the core engine. | Memory/layout control vs safety. |
| HPC / scientific kernels | C++ / Fortran / Julia | Rust, Mojo, CUDA ecosystem | Mojo as an emerging option for heterogeneous AI compute. | JavaScript for numerical kernels. | Peak performance vs ecosystem and portability. |
| Serverless | TypeScript / Python / Go | C# AOT, Java with a suitable runtime | Go/AOT if cold start is a measurable problem. | Optimising the runtime before measuring real cold starts. | Cold start vs developer velocity. |
| Cloud infrastructure / DevOps | Go + Python | Rust, Bash/PowerShell | Rust for security/performance-sensitive agents. | C++ for typical operator tools. | Standalone binaries vs scripting flexibility. |
Polyglot architecture
A good polyglot stack separates languages by layer. A bad one creates a separate ecosystem for every service.
- Frontend
- TypeScript
- Backend services
- Go / Java / C#
- AI layer
- Python
- Performance-critical
- Rust / C++
- Data
- SQL
- Automation / Infra
- Go / Python / Bash / Terraform
Preferred
The organisation’s default stack. The best support, templates and observability.
Supported
Allowed when the workload justifies the choice.
Experimental
Controlled use, explicit owner, exit plan.
Deprecated
No new systems; a migration plan for existing components.
Common mistakes
Problem → example → better approach.
Hype-driven development
Better approach: Hype-driven development
Start from constraints and measurable requirements.
Resume-driven development
Better approach: Resume-driven development
Separate an R&D sandbox from critical production decisions.
Premature optimisation
Better approach: Premature optimisation
Measure → profile → identify bottleneck → optimise.
Benchmark obsession
Better approach: Benchmark obsession
Benchmark a representative workload with DB/network/cache.
Ecosystem blindness
Better approach: Ecosystem blindness
Work out build-vs-buy and the maintenance of your own libraries.
Hiring blindness
Better approach: Hiring blindness
Take onboarding, the job market and the bus factor into account.
Deployment blindness
Better approach: Deployment blindness
Assess the whole SDLC, not only the coding experience.
Scaling myths
Better approach: Scaling myths
First the DB, I/O, caching, state, queues and topology.
One language for everything
Better approach: One language for everything
Use a limited polyglot stack with clear boundaries.
Polyglot chaos
Better approach: Polyglot chaos
Preferred/Supported/Experimental/Deprecated technology lifecycle.
Rewrite before profiling
Better approach: Rewrite before profiling
Isolate hot paths and migrate only when measurements justify the cost.
Ignoring longevity
Better approach: Ignoring longevity
Check the project’s ownership, release cadence, compatibility and exit path.
Emerging languages
As of 2026: Rust and Go are no longer experiments; Mojo 1.0 changed the project’s status; Carbon is still officially experimental.
| Language | Status | Maturity | Adoption | Risk | Interpretation |
|---|---|---|---|---|---|
| Rust | Production mature / growing | High | High | Low–medium | A mainstream-adjacent systems language with a mature Cargo/crates ecosystem. |
| Go | Production mature / growing | High | High | Low | No longer emerging, but it remains strategically growing in cloud/tooling. |
| Zig | Emerging | Medium | Medium | Medium–high | Strong systems/C interop; still pre-1.0.Evidence: Verified fact |
| Mojo | Emerging — 1.0Evidence: Verified fact | Growing | Growing | Medium–high | 1.0 since August 2026; interesting for AI/HPC, the ecosystem is still young. |
| Gleam | Emerging nicheEvidence: Interpretation | Medium | Growing | Medium | Strong types + BEAM/JS; a small ecosystem, but good ergonomics. |
| Odin | Emerging nicheEvidence: Interpretation | Low–medium | Low | High | Systems/games/data-oriented; small adoption. |
| Roc | Experimental | AlphaEvidence: Emerging / uncertain | Low | Very high | An interesting app+platform model; not for critical production. |
| Carbon | ExperimentalEvidence: Verified fact | Early | Low | Very high | A C++ successor project; the repo says it plainly: not ready for use. |
| V | Experimental / pre-1.0Evidence: Verified fact | Low–medium | Low | High | An ambitious general-purpose challenger, a small ecosystem. |
| Vale / Valen | Archived / successor experimentEvidence: Verified fact | Vale archived | Low | Very high | Vale archived; Valen continues some of its ideas. |
Evidence: InterpretationMaturity, adoption and risk levels are interpretation. A chip in a row labels only the claim beside it.
Production mature
- Rust
- Go
Growing / emerging
- Mojo 1.0
- Zig
- Gleam
Experimental
- Odin
- Roc
- Carbon
- V
Archived / successor
- Vale → Valen
Vale is archived; Valen continues some of its ideas.
Emerging trends
The most durable trends concern safety and security, machine-checkable constraints and heterogeneous compute. Evidence: Interpretation
- Durable
Memory safety
Security pressure + the high cost of memory corruption; the direction is visible in Rust and in the recommendations of security agencies.
- Durable
Stronger static typing
Large codebases, refactoring and AI-generated code increase the value of machine-checkable constraints.
- Durable
Structured concurrency
It brings order to the lifecycle of tasks and to cancellation; visible in the Kotlin/Swift/Java ecosystems.
- Growing
Native AOT
Smaller cold starts and footprint for runtimes traditionally associated with JIT.
- Growing
WebAssembly + WASI
Portable sandboxed components, plugins, edge and server workloads.
- Strategic
Heterogeneous CPU/GPU/NPU compute
AI is moving software towards many classes of accelerator; important for the Mojo/C++/CUDA/MLIR ecosystems.
- Strategic
AI-assisted programming
It changes the cost of producing code; it still requires verification and good tooling.
- Growing
Compiler-driven verification
Strong types, linters and tests create an automatic feedback loop for people and agents.
- Durable, but controlled
Polyglot systems
Fitting the language to the layer makes sense, but it requires governance to avoid polyglot chaos.
AI and coding agents
This is the interpretive part. Hypothesis: with agents, the value of languages and toolchains that give fast, unambiguous machine feedback grows.
Evidence: Interpretation Evidence: Emerging / uncertain
- AI agentgenerates a change
- Compiler + testsverify
- Structured errorsfeedback to the agent
The steps repeat from the first one.
Strong types
More errors can be detected before the program runs. Types become formal context for refactoring and code generation.
Deterministic tooling
A formatter, linter, package lock, reproducible build and fast compiler limit ambiguity.
Machine-readable feedback
Precise diagnostics shorten the agent → code → verify → fix loop.
| Language | Agent-friendly strengths | Risk / limitation |
|---|---|---|
| Rust | Strong types, borrow checker, Cargo, rustfmt, Clippy, precise diagnostics | A harder ownership model; the agent must understand lifetimes/unsafe boundaries |
| Go | Small syntax, fast compiler, gofmt, uniform tooling | A less expressive type system than Rust/TS/C# |
| TypeScript | Static checker, huge corpus/ecosystem, LSP, fast TS7 toolchain | Types disappear at runtime; JS semantics still have edge cases |
| C# / Java / Kotlin | Mature IDEs, types, refactoring, test frameworks, build tooling | Large enterprise repos can have complex framework conventions |
| Python | Huge corpus, simple syntax, fast execution loop, AI ecosystem | More runtime errors; it is worth adding pyright/mypy, Ruff, pytest, Pydantic |
| C++ | Huge corpus and compilers/static analysers | UB, macros, templates, ownership conventions, build/ABI complexity |
Future 2026–2035
Legacy has enormous inertia. ‘Declining’ does not mean ‘disappearing’. Evidence: Interpretation
Ecosystem foundations
Python · TypeScript/JavaScript · Java · C# · C · C++ · SQL
A vast amount of existing infrastructure, libraries, talent pool and dependencies.
Strategically growing
Rust · Go · TypeScript · Kotlin
Safety, cloud, typed web and the modernisation of platforms.
Specialist
Julia · R · Elixir/Erlang · Swift · Dart · Haskell/OCaml/F#
Strong domains, but they do not need to win the whole market.
Relative decline
Objective-C · Ruby · some PHP use cases
This does not mean ‘they will disappear’; a large production base can keep a language going for decades.
Watch
Mojo · Zig · Gleam · Odin · Roc · Carbon · Valen
Different levels of maturity — from Mojo 1.0 to the experimental Carbon.
The most important variable
AI-generated code + verification
A possible shift of value from ‘easy to write’ towards ‘easy to verify automatically’.
Case studies
Don’t treat them as universal recipes. Every migration was a response to a specific workload and the organisation’s context.
Dropbox
Python → GoEvidence: Industry observation- Problem
- Performance-critical backends and concurrency
- Result
- Large parts of the infrastructure moved to Go; the company described ~200k lines of Go.
- Lesson
- Python was great for fast iteration; scale changed the economics of the choice.
Discord
Go → RustEvidence: Benchmark-dependent- Problem
- Periodic latency spikes in Read States, linked to GC with a large cache
- Result
- Rust removed the observed spikes and, in this workload, improved latency, CPU and memory.
- Lesson
- This is not proof that Rust is always > Go; it is proof of the importance of the profile of a specific workload.
Slack
JavaScript → TypeScriptEvidence: Industry observation- Problem
- Maintaining a large desktop codebase, and bugs found only at runtime
- Result
- Gradual type checking and better IDE/refactoring integration.
- Lesson
- Static types can improve maintainability without changing the runtime semantics of JS.
Duolingo / Android
Java → KotlinEvidence: Industry observation- Problem
- A growing Android codebase and boilerplate
- Result
- After the migration, the Android case study reported on average ~30% fewer lines per converted file.
- Lesson
- Interoperability allows an incremental migration instead of a big-bang rewrite.
Cloudflare
NGINX/C ecosystem → Rust/PingoraEvidence: Industry observation- Problem
- Limitations of the proxy architecture at Cloudflare’s scale
- Result
- Its own proxy stack in Rust gave more control and better efficiency in their environment.
- Lesson
- Hyperscale can justify an investment that would not pay off for a small SaaS.
TypeScript toolchain
TypeScript implementation → GoEvidence: Benchmark-dependent- Problem
- Scaling compiler/tooling performance
- Result
- TypeScript 7 is a native port to Go; Microsoft reports typically 8–12× faster full builds.
- Lesson
- Language ≠ language implementation; the runtime/toolchain can change performance without changing semantics.
Learning roadmap
You don’t need to learn 15 languages. It is better to know a few programming models really well.
- 01PythonLearn deeply. Programming, automation, AI/data, API; also learn types, pytest and packaging.
- 02SQLLearn deeply. The relational data model, joins, windows, query plans, transactions and indexes.
- 03TypeScriptLearn well. Frontend/full-stack, structural typing, async/event loop and the large JS ecosystem.
- 04GoLearn well. Concurrency, networking, simple services, single-binary deployment, cloud-native thinking.
- 05RustLearn enough → then deeper. Ownership, borrowing, lifetimes, memory model, zero-cost abstractions and systems thinking.
- 06C# or Java/KotlinLearn one ecosystem well. Managed runtime, enterprise architecture, DI, observability, large codebases.
- OptionalC fundamentalsLearn enough to understand. Pointers, stack/heap, memory layout, ABI, syscalls — a great foundation for Rust/systems.
Cheat sheet
Quick starting rules; develop them through profiling and the project’s constraints.
AI / Data
- StartRecommendation: Default
- Python + SQL
- ConsiderRecommendation: Specialised
- Julia/R for specialist science; Rust/C++/Mojo for hot paths.
Web
- StartRecommendation: Default
- TypeScript
- ConsiderRecommendation: Specialised
- Python/Go/C#/Java as the backend, depending on the organisation.
Cloud service
- StartRecommendation: Default
- Go
- ConsiderRecommendation: Specialised
- Java/C# for enterprise; Rust when latency/memory/safety dominate.
SaaS MVP
- StartRecommendation: Default
- TypeScript or Python
- ConsiderRecommendation: Specialised
- Go/Java/C# when operations and scale start to dominate.
Systems
- StartRecommendation: Default
- Rust/C/C++
- ConsiderRecommendation: Specialised
- Zig, if you accept a younger ecosystem and need explicit control.
Mobile
- StartRecommendation: Default
- Kotlin Android / Swift iOS
- ConsiderRecommendation: Specialised
- Flutter/Dart or React Native for cross-platform.
HFT
- StartRecommendation: Default
- C++
- ConsiderRecommendation: Specialised
- Rust; sometimes very finely tuned Java.
OSINT / Security
- StartRecommendation: Default
- Python
- ConsiderRecommendation: Specialised
- Go/Rust for fast standalone tools and performance-sensitive components.
Scientific / HPC
- StartRecommendation: Default
- Python + native ecosystem or Julia/C++/Fortran
- Watch
- Mojo for heterogeneous compute.
Principle
- problem
- constraints
- ecosystem
- performance
- safety
- team
- deployment
- language choice
Glossary
A searchable dictionary of key concepts.
19 terms
A
- ABIApplication Binary Interface
- Binary conventions that define, among other things, function calls and data layout between components.
- Example C/C++ interoperability
- AOTAhead-of-Time compilation
- Compilation to target code before the program runs.
- Example C, Rust, Go, Swift
- ARCAutomatic Reference Counting
- Automatic memory management based on the number of references.
- Example Swift
B
- Borrow checkerBorrow analysis
- The part of the Rust compiler that verifies the rules of references and lifetimes.
- Example Rust
- BytecodeIntermediate code
- A representation between source code and machine code, executed by a VM/JIT.
- Example Java/JVM
C
- Concurrency
- The ability of a system to handle many tasks that take place in overlapping time.
- Example Go goroutines, Erlang processes
D
- Data race
- Unsynchronised, simultaneous access to the same memory when at least one of the accesses writes.
- Example C/C++; safe Rust code limits this class of problems
F
- FFIForeign Function Interface
- A mechanism for calling code written in another language/runtime.
- Example Python↔C, Rust↔C
G
- GCGarbage Collector
- A mechanism that automatically finds and frees memory that is no longer used.
- Example Java, Go, C#, JavaScript
J
- JITJust-in-Time compilation
- The runtime compiles and optimises code while it runs, often based on hot paths.
- Example JVM, .NET, V8, Julia
M
- Memory safety
- Protection against classes of bugs such as use-after-free, invalid access or dangling pointers.
- Example Rust, managed languages
O
- OwnershipOwnership of values
- A model that defines who owns data and the rules for moving/borrowing it.
- Example Rust
P
- Parallelism
- Actually performing many computations at the same time, e.g. on many cores.
- Example C++ threads, Julia
R
- RAIIResource Acquisition Is Initialization
- The lifetime of a resource is tied to the lifetime of an object.
- Example C++, Rust-like patterns
S
- Structured concurrency
- A model that ties the lifetime of tasks to the scope that created them.
- Example Kotlin coroutines, Swift
V
- VMVirtual Machine
- A runtime layer that executes bytecode or an intermediate representation of the program.
- Example JVM, BEAM
W
- WASIWebAssembly System Interface
- A set of system interfaces for Wasm outside the browser itself.
- Example Wasm runtimes
- WasmWebAssembly
- A portable binary instruction format designed for sandboxed execution.
- Example Rust, C++, Go
Z
- Zero-cost abstractionAbstraction with no runtime cost
- The idea that a high-level abstraction should add no cost beyond the equivalent low-level code.
- Example C++, Rust
No terms match.
Sources and methodology
Primary documentation, engineering blogs and industry research are preferred. Popularity rankings measure different phenomena and are not interchangeable.
Note
Evidence: Verified fact Evidence: Industry observation Evidence: Benchmark-dependent Evidence: Interpretation Evidence: Emerging / uncertain
GitHub contributor counts, Stack Overflow ‘admired’, the JetBrains survey and TIOBE do not measure the same thing. This atlas does not use any single index as proof of a language’s quality.
Official documentation
- Rust Book — Understanding Ownership
Ownership makes memory-safety guarantees possible without a GC.
- Go 1.27 release
Go 1.27: generic methods, runtime/library changes and experimental SIMD.
Official / engineering
- TypeScript 7.0
A native port of the toolchain to Go; Microsoft reports typically 8–12× faster full builds. The port is verified; the speed-up is benchmark-dependent.
Official / emerging language
- Mojo 1.0
Mojo 1.0 was released on 11 August 2026; a more stable foundation and production use by Modular.
- Carbon language repository
Carbon is officially described as experimental and not ready for use.
- Vale project
Vale is archived; its ideas are continued in Valen.
Security
- NSA + CISA: Memory Safe Languages
A joint recommendation on the importance of memory-safe languages. The NSA page refused automated checks on the access date; CISA’s page for the same joint guide confirms the recommendation.
Survey / ecosystem
- GitHub Octoverse 2025
TypeScript #1 by GitHub’s contributor metric in 2025; Python dominates AI-tagged projects.
Survey
- Stack Overflow Developer Survey 2025
Admired: Rust 72%, Gleam 70%, Elixir 66%, Zig 64% — what respondents declare, not market share.
- JetBrains Developer Ecosystem 2025
TypeScript, Rust and Go have a high perceived growth potential in the JetBrains survey.
Engineering case study
- Dropbox — Go libraries
Dropbox described migrating performance-critical backends from Python to Go; about 200k lines of Go. The article dates from 2014.
- Discord — Go to Rust
Read States: GC latency spikes in Go; Rust improved latency/CPU/memory in this specific workload.
- Slack — TypeScript at Slack
A gradual migration of a large JS codebase to TS, and the benefits of static analysis/tooling.
- Duolingo — Java to Kotlin
Android migration from Java to Kotlin; the Android case study reports on average ~30% fewer lines after conversion.
- Cloudflare — Pingora
Rust/Pingora as Cloudflare’s own proxy infrastructure; a case study in scale and control over the runtime.
Methodology
Conversion. This edition was converted from a single-file interactive atlas written in Polish. The prose was translated into British English without summarising; names, numbers and versions are unchanged, including time-sensitive ones such as Go 1.27, TypeScript 7.0 and Mojo 1.0. The atlas’s built-in data and its repeated cards and tables became datasets with named fields, and automated tests check every count against the original. Two sections moved: ‘Language vs runtime vs framework’ now follows the taxonomy, because the sections on differences and performance rely on its layers, and ‘Polyglot architecture’ now comes before ‘Common mistakes’, two of which refer to it. Links into the original atlas still resolve.
Links. Every source link was checked on 3 Oct 2026. Fourteen of the fifteen open; the NSA page refused automated checks, and the recommendation it describes was confirmed on CISA’s page for the same joint guide.
Evidence. The original atlas defines the five labels above. This edition attaches them only where the atlas’s own wording makes the type of claim clear: the ratings, the calculator, the decision helper and matrix, the trends, the future scenarios and the section on coding agents are interpretation; the performance table and notes are benchmark-dependent; the case studies are industry observations, except the Discord and TypeScript toolchain results, which are benchmark-dependent. The statuses of Zig, Mojo, Carbon, V and Vale were checked on the projects’ official pages on 3 Oct 2026, and Roc’s on its repository: its maturity, ‘Alpha’, is not the project’s own wording, so it is labelled emerging / uncertain. Rust, Go, Gleam and Odin were not checked; their rows carry no verified label, and the maturity, adoption and risk levels are interpretation. The atlas mentions TIOBE without citing it, so no link is added.
Heuristics. The ‘Memory / control’ and ‘Predictability’ columns of the performance table were computed by a fixed rule in the original atlas’s code; this edition stores the values and states the rule under the table. The decision helper applies the original rules unchanged: among the languages that pass the domain, runtime and risk filters, it ranks by the priority rating + 0.3 × ecosystem + 0.2 × tooling and shows the top four. The break-even calculator uses the original formula: the extra development cost, (Rust weeks − Python weeks) × the weekly developer cost, divided by the monthly infrastructure saving.
Programming Languages 2026 — Interactive Atlas. Decision-support reference. The qualitative ratings are an educational heuristic, not a benchmark or a universal architectural recommendation.
- 2026-10 — first published on Nexate, translated and restructured from the original handbook. The original was a self-contained, offline-first single HTML file in Polish.
- 2026-10 — deliberate changes from the original: the explorer search matches the languages’ text only, not the names of their data fields; links to a language open its profile when the page loads; the use-case switcher, explorer filters and comparison are kept in the page address; dialogs return the focus when they close; messages replace pop-up alerts; external links open in the same tab; there is no theme switch, as the site has one dark theme.