The top AI programming languages, chosen for each layer of an AI stack
Python is the answer you were given, and it is only part of the answer. A real AI product runs on four layers, and each one has its own language, its own tools and its own hiring pool.
What are the top AI programming languages?#
The top AI programming languages are Python, C++ with CUDA, Rust, and TypeScript or Go, and each one owns a different layer of an AI stack.
| Layer | What it does | Main language | Tools that prove it |
|---|---|---|---|
| Research and training | builds and trains the model | Python | PyTorch, JAX, TensorFlow, Hugging Face Transformers |
| Kernels | runs the maths on the GPU | C++ with CUDA, or Triton | CUDA, Triton |
| Runtime | loads a trained model and runs it | C++ or Rust | llama.cpp, ONNX Runtime, candle |
| Serving and product | puts the model behind an app or API | TypeScript or Go | Transformers.js, onnxruntime-node, Ollama |
Source: each project's own documentation, read in October 2026.
The table rests on what each project says about itself. For example, TensorFlow's API docs say "The Python API is at present the most complete". In the same way, the llama.cpp repository describes itself as "LLM inference in C/C++", where an LLM is a large language model. Then Hugging Face says "Candle is a minimalist ML framework for Rust", ML being machine learning. Its Transformers.js docs add that the library runs models "directly in your browser, with no need for a server".
Most lists of AI languages, the artificial intelligence languages of older guides, put Python first. They are not wrong. They just stop one layer too early.
Why choose a language per layer instead of one for everything?#
Choosing one language per layer lets each team hire and build for the work in front of it, while one exported model file carries the result across every boundary.
Take a worked example: one document search feature in a web app. First, a data scientist fine-tunes a Hugging Face Transformers checkpoint in Python with PyTorch. Then the model is exported with torch.onnx to a single ONNX file. After that, ONNX Runtime loads that file. A TypeScript service calls it when a user types a query.
Four teams could touch that feature. But most companies own only one or two of the layers. In practice, the variable that decides your language is the layer your team owns. A team that only builds the product needs TypeScript and never writes a CUDA kernel. Meanwhile, a team that trains models needs Python and may never touch the web app.
2 languages to staff
- Research and training: Python
- Kernels: not staffed
- Runtime: not staffed
- Serving and product: TypeScript or Go
Hand-off: Research and training to Serving and product: one exported ONNX file.
| Layer | Language | Start from | Yours |
|---|---|---|---|
| Research and training | Python | PyTorch torch.onnxPyTorch, JAX, TensorFlow, Hugging Face Transformers | Yes |
| Kernels | C++ with CUDA, or Triton | CUDA C++ Programming GuideCUDA, Triton | No |
| Runtime | C++ or Rust | ONNX Runtime docsllama.cpp, ONNX Runtime, candle | No |
| Serving and product | TypeScript or Go | ONNX Runtime installTransformers.js, onnxruntime-node, Ollama | Yes |
That is why the argument about the one true AI language goes nowhere. Instead, the question becomes a staffing plan. The file format is the contract between teams.
Is Python the best language for AI?#
Python is the best language for AI research and training, because PyTorch, JAX and the TensorFlow Python API all treat it as their first interface.
PyTorch's documentation calls it "an optimized tensor library for deep learning using GPUs and CPUs", and you drive it from Python. The JAX docs open with "JAX is a Python library for accelerator-oriented array computation". Also, the Hugging Face Transformers library, which provides pretrained models for inference or training, is a Python package first.
GitHub's Octoverse 2025 report, published on 28 October 2025, says "Python now powers nearly half of all new AI repositories" on its platform.
Show data table
| Item | Value |
|---|---|
| Python | 582,196 |
| Jupyter Notebook | 402,643 |
| JavaScript | 88,023 |
| TypeScript | 85,746 |
| C++ | 7,800 |
Python leads new AI repositories on GitHub by a wide margin.
Python wins this layer because research is a loop of small changes. First you change a line, run a cell, look at a loss curve, and change it again. Since Python is easy to read and quick to edit, that loop stays short.
However, Python stops being the answer the moment the model has to run fast in a product. The training loop calls into compiled code, and the people who write that code use other languages.
Which language writes the GPU kernels under PyTorch?#
Below the Python API, the kernels that do the arithmetic are written in CUDA C++ or in Triton, a language and compiler that offers a Python-based way to write them.
Here a kernel is a small function that runs on many GPU cores at once. NVIDIA's CUDA C++ Programming Guide covers "the basics of programming GPUs in C++ and Python", and its appendices cover CUDA's C++ language support. Meanwhile, the Triton documentation describes "a Python-based programming environment for productively writing custom DNN compute kernels". DNN means deep neural network.
Also, PyTorch itself has a C++ API, shipped as a library called libtorch. PyTorch's C++ API page, dated 8 May 2026, says most tensor and autograd operations in the Python API are also there in C++. Autograd is the part that works out gradients during training.
In short, every Python training loop hands its heavy work to compiled code. Kernel work is its own skill with its own hiring pool. Most teams buy it in the form of PyTorch rather than write it. If you want to see what that parallel style looks like, our post on GPU parallel programming with Bend walks through it.
Where do C++ and Rust fit in an AI stack?#
C++ and Rust own the runtime layer, where llama.cpp, ONNX Runtime and candle load a trained model and run it without a Python interpreter.
In this sense, the runtime is the program that reads a finished model file and runs it on new inputs. ONNX Runtime's docs put the use case plainly: "Train in Python but deploy into a C#/C++/Java app". The llama.cpp README describes a "Plain C/C++ implementation without any dependencies". Because there is no interpreter to start, the same code builds for a Mac with Apple silicon, an Android phone or a small server.
Next to it, Rust is the newer option. Hugging Face's candle repository says candle "lets you remove Python from production workloads", and it names Python overhead and the GIL as the reason. The GIL is Python's global interpreter lock, which lets only one thread run Python code at a time. Rust gives memory safety without a garbage collector. So it suits code that must not crash under load.
Still, C++ holds most of this layer today, since llama.cpp and ONNX Runtime are both C++ at their core. Therefore Rust is a good bet for new runtime code, not a reason to rewrite one that works. For the wider case for Rust in systems code, see our post on Linux kernel work and Rust.
Which language serves a model inside a product?#
TypeScript or Go serves the model inside the product, through Transformers.js and onnxruntime-node in TypeScript or a Go server such as Ollama.
In practice, the product layer is the code a user actually touches: the web page, the API and the queue behind them. That code is usually written in TypeScript or Go already, so the model has to come to it. The ONNX Runtime install page lists onnxruntime-node for Node.js and onnxruntime-web for the browser. Then Transformers.js runs models "directly in your browser, with no need for a server". On the Go side, the Ollama repository is a Go module, and Ollama "has a REST API for running and managing models".
GitHub's Octoverse 2025 report, dated 28 October 2025, counts TypeScript adding more contributors on GitHub than Python over its measurement year.
Show data table
| Item | Value |
|---|---|
| TypeScript | 1,054,015 |
| Python | 850,579 |
| JavaScript | 427,148 |
| Java | 174,705 |
TypeScript added more contributors on GitHub than Python over the year.
That growth is not all AI work, of course. However, it shows where the product code lives, and the product layer is where most teams meet a model first. For the interface side, our post on streaming AI interfaces in Svelte shows how a TypeScript front end handles a model's answer as it arrives.
How does a model trained in Python reach a TypeScript service?#
A model trained in Python reaches a TypeScript service as an ONNX file, exported with torch.onnx and loaded by ONNX Runtime or Transformers.js.
PyTorch's ONNX page, last updated on 10 September 2025, defines the format as "an open standard format for representing machine learning models". So the hand-off is two steps: export on the Python side, load on the TypeScript side. Build it from these pages, in this order:
- PyTorch torch.onnx: the torch.onnx.export call and the dynamo=True setting that picks the newer exporter.
- ONNX Runtime docs: one runtime for a model trained in Python and run from another language.
- ONNX Runtime install: the onnxruntime-node and onnxruntime-web packages for JavaScript and TypeScript.
- Transformers.js: the pipeline call that runs ONNX models in JavaScript.
Because each page owns one step, a broken hand-off points to one page. Also, Transformers.js says it "uses ONNX Runtime to run models in the browser", so the two TypeScript routes share one engine.
What is the smallest working hand-off between Python and TypeScript?#
The smallest working hand-off is two short programs: one Python call that exports the model and one TypeScript pipeline that runs a model in that format.
First, the Python side follows the PyTorch ONNX page. It builds a tiny model, makes a sample input and writes the file.
Then the TypeScript side follows the Transformers.js page. It downloads an ONNX model for a task and runs it on a line of text.
import torch
class MyModel(torch.nn.Module):
def __init__(self):
super().__init__()
self.conv1 = torch.nn.Conv2d(1, 128, 5)
def forward(self, x):
return torch.relu(self.conv1(x))
input_tensor = torch.rand((1, 1, 128, 128), dtype=torch.float32)
model = MyModel()
torch.onnx.export(model, (input_tensor,), "my_model.onnx", input_names=["input"], dynamo=True) import { pipeline } from '@huggingface/transformers';
const pipe = await pipeline('sentiment-analysis');
const out = await pipe('I love transformers!');
console.log(out); Run the Python file with PyTorch installed, then run the TypeScript file as an ES module after npm i @huggingface/transformers. For your own exported file, ONNX Runtime's Node.js binding loads it with import * as ort from 'onnxruntime-node', as its get-started page shows. Neither program needs the other's language, and that is the point.
Which programming language is in demand for AI?#
Stack Overflow's 2025 Developer Survey puts Python at 57.9 percent of respondents, ahead of TypeScript at 43.6 percent, C++ at 23.5 percent and Rust at 14.8 percent.
That order follows the layers. Python leads because every training team needs it. TypeScript is second because every product needs a front end. Then C++ and Rust are smaller, since fewer people write runtimes than call them.
Show data table
| Item | Value |
|---|---|
| Python | 57.9 |
| TypeScript | 43.6 |
| Java | 29.4 |
| C++ | 23.5 |
| Go | 16.4 |
| Rust | 14.8 |
| R | 4.9 |
| Mojo | 0.4 |
Python leads the survey, with TypeScript second and C++ and Rust smaller.
The same Stack Overflow survey page, from July 2025, says "Python developers aspire to use Rust and Go". In other words, the people who own the training layer want to move down the stack. That is useful when you staff a runtime team, because the best hires may already know your models.
Still, keep in mind what this measures. It counts the people who answered one survey, not the whole market for jobs.
Do the language rankings agree on Python?#
TIOBE's index for September 2026 rates Python at 17.76 percent, more than double C++ at 8.67 percent, so a search-based ranking agrees with the survey on first place.
Unlike the survey, TIOBE builds its ratings from search engine results, and its index page says it "is not about the best programming language". So it is a measure of how much is written about a language, not a verdict on quality.
17.76%
Python
8.67%
C++
A search-based ranking agrees with the survey: Python first, C++ well behind.
| Option | TIOBE Index rating, percent |
|---|---|
| Python | 17.76% |
| C++ | 8.67% |
Source: TIOBE Index, September 2026
Two different measures, a survey of people and a count of search hits, both put Python first. In TIOBE's September 2026 table, C++ at 8.67% also sits well ahead of Rust at 1.34% and Go at 1.10%. Therefore the rule for what to learn is simple. Learn Python if you want to train models, and learn the language of the layer you want to work in after that.
When is a per-layer stack the wrong fit?#
A per-layer stack is the wrong fit for a small team that only calls a hosted model over HTTP, where one language for the whole product is the better choice.
So go back to the worked example and remove the bottom three layers. If you train nothing, write no kernels and run no runtime, then only the product layer is left. So write the whole product in the language you already ship, and call the model's API from there.
Where should you go next for each layer?#
Each layer has its own next read: GPU parallel programming for kernels, Rust for systems code, and streaming interfaces for the TypeScript product layer.
If you own kernels, start with GPU parallel programming with Bend. For the runtime layer, read why Rust suits systems code. If you own the product, read streaming AI interfaces in Svelte, and to pick the kind of model first, see LLM types and their enterprise uses.
Some teams also staff a layer from outside. When that is you, the routes are Python developers for training work and Node.js developers for the TypeScript service. Still, the four documentation pages in the hand-off section are enough on their own to build the whole path.