The honest answer to “which programming language should I use for AI?” is Python, and you probably already knew that. What most roundups will not tell you is that the other languages on this page are not runners-up. They are answers to different questions – questions about where your model runs, how fast it has to respond, and what already exists in your codebase.

So this is not a list of fifteen contenders for one crown. It is a list of eight languages that earn a place in AI work, ranked by how often the answer is genuinely them, with a section at the end for the seven that we cut and why.


A note on the statistics we removed

This article previously opened with two numbers: that the “2026 AI Developer Survey by JetBrains” found 78% of AI practitioners use multiple languages, and that the “2026 Kaggle ML & DS Survey” showed 87% of machine learning practitioners use Python as their primary language.

Neither document exists.

JetBrains does not publish an “AI Developer Survey.” Its research publication is the State of Developer Ecosystem, and the 2026 edition opened for responses in May 2026 and has not published results. Kaggle’s Machine Learning & Data Science Survey is real, but the 2022 edition was the sixth and last one. There has been no 2023 survey, let alone a 2026 one. Kaggle users have been asking on the forums where it went for years.

We are telling you this rather than quietly deleting it, because a fabricated statistic in an article about programming languages is a signal about the whole article. If the opening number was invented, the version numbers probably were too. Every figure below is linked to the thing it came from. Where we could not verify something, we say so instead of rounding it into a claim.


How we ranked these

One question decided the order: if you are starting this kind of AI work today, is this language the actual choice, or is it the choice you make because of something else you already committed to?

That distinction matters. A language can be excellent and still be a bad recommendation, because nobody arrives at it freely. Scala is a fine language. Nobody picks it to do AI. They pick it because their data already lives in Spark. That is a real situation, and it is also a reason Scala is not in a top eight.

We also checked, at source, whether the frameworks each language depends on are alive. Two of the fifteen entries in the previous version of this article leaned on projects that have been archived for years.

Each entry below was checked against four things:

  • Is anyone choosing it? Usage data from the Stack Overflow 2025 survey and the TIOBE index for July 2026, not vibes.
  • Are its frameworks alive? Verified against each project’s own release history, not a search summary.
  • What does it actually do in an AI stack? Train, serve, integrate, or accelerate – these are different jobs.
  • What is it bad at? Every entry names a real weakness. An entry with no drawback is an advertisement.

1. Python

Everything else on this list is a special case. This is the default.

Python’s position in AI is not really about Python. The language is slow, its concurrency story is awkward, and its packaging has been a running joke for fifteen years. It won because it became the interface layer to fast code written in other languages, and then the entire research community standardised on that interface. When a new model architecture appears, the reference implementation is in PyTorch. When a paper ships weights, they load in Python. That gravity compounds every year.

The TIOBE index for July 2026 puts Python at 18.94%, first place, roughly 8 points clear of C in second. The 2025 Stack Overflow Developer Survey has 57.9% of all respondents using it, behind JavaScript’s 66% only because so much of the industry touches a browser. Note that the 2026 Stack Overflow survey opened in June 2026 and has not reported yet, so anyone quoting 2026 survey figures at you is quoting something unpublished.

What you actually get: PyTorch, which shipped 2.13.0 on 8 July 2026 and has been releasing roughly monthly. TensorFlow, on 2.21.0 since March 2026, on a much slower cadence but still maintained. Keras 3, at 3.15.0 in June 2026, now a multi-backend layer rather than a TensorFlow appendage. Then scikit-learn, JAX, Hugging Face Transformers, and the LLM tooling layer that did not exist five years ago.

A caution worth more than any of that: if you see a roundup citing “PyTorch 3.0,” stop reading it. There is no PyTorch 3.0. It is a version number that AI-written articles invent because 3.0 sounds like where a mature project ought to be by now. The real line is 2.x and has been for years.

What it is bad at: anything where the Python interpreter is in the hot path. Serving a model is fine, because the work happens in C++ underneath. Writing a tight loop over individual records is not. The GIL still shapes how you design services, and while the free-threaded builds are progressing, turning the GIL off is not yet advice you can give a production team casually.

Choose it if: you are training, fine-tuning, evaluating, or researching anything. Or if you have no strong reason to pick something else, which covers most people.


2. C++

Python is the interface. This is the thing behind it.

PyTorch’s core is C++. TensorFlow’s core is C++. llama.cpp put local LLM inference on ordinary laptops and is, as the name says, C++. ONNX Runtime, TensorRT, and most of what the word “inference engine” refers to are C++ projects with bindings hanging off them. When people say Python dominates AI, what they mean is that Python dominates the part of AI that humans type.

This matters practically, not only as trivia. The moment you need to make inference faster, embed a model into a device or a game engine, or debug why a tensor operation is slow, you leave Python and land here. Stack Overflow’s 2025 survey has C++ at 23.5% usage, and TIOBE places C++ third at 9.12% in July 2026.

What it is bad at: everything about the developer experience. Build systems, dependency management, compile times, and the sheer volume of ways to write code that is technically valid and quietly catastrophic. Nobody prototypes a model in C++, and you should not be the first to try.

Choose it if: you are shipping inference into a constrained environment, working on a framework or runtime itself, or the profiler keeps pointing at a place Python cannot follow.


3. CUDA C++

Strictly, this is C++ with extensions and a compiler, not a separate language. It is on this list separately because it is a separate skill, and because the job market treats it as one.

Someone writes the kernels. FlashAttention was a kernel. Every meaningful speedup in transformer training over the past few years came from somebody who understood memory hierarchies on a GPU well enough to restructure the computation around them. That work happens in CUDA, or in Triton, which is a Python-syntax layer over the same ideas and a reasonable place to start.

The honest framing is that this is a small, well-paid, deeply specialised corner. Most AI engineers will never write a kernel. The ones who can are unusually valuable precisely because most cannot, and because the abstraction leaks constantly – performance work at this level does not stay hidden behind an API.

What it is bad at: portability. CUDA is NVIDIA hardware. AMD’s ROCm and Apple’s Metal exist and have improved, but writing once and running everywhere is still not the reality here.

Choose it if: you are doing performance engineering on training or inference, or you want a specialisation with very little competition.


4. JavaScript and TypeScript

Ask where AI models are trained and the answer is Python. Ask where users actually meet them and the answer is a browser.

The AI application layer has largely become a TypeScript layer. The Vercel AI SDK, LangChain.js, and the official OpenAI and Anthropic SDKs are all first-class in TypeScript, and for a product that calls a hosted model, streams tokens into a UI, and manages conversation state, there is no argument for adding Python to the stack. You are writing a web application that happens to talk to a model.

Then there is in-browser inference, which stopped being a demo. Transformers.js runs real models client-side via WebAssembly and WebGPU. ONNX Runtime Web does the same. For a small classifier, an embedding model, or speech recognition, running on the user’s device means no inference bill, no round trip, and no data leaving the machine. That last one closes more enterprise deals than the other two combined.

JavaScript leads Stack Overflow’s 2025 usage table at 66%, with TypeScript at 43.6% and climbing every year.

What it is bad at: training. TensorFlow.js technically permits it and you should treat that as a curiosity rather than a plan. Browser memory limits also bite hard – “runs in the browser” means small models, and the gap between what fits and what you actually wanted to run is wide.

Choose it if: you are building the product rather than the model. Which, numerically, is most people working in AI right now.


5. Rust

Rust is the one language on this list whose AI story got materially better rather than merely louder.

The evidence is in the tools people use without thinking about them. Hugging Face’s tokenizers library is Rust, and if you have ever called AutoTokenizer from Python you have run Rust. Their Candle framework is a serious minimal-footprint inference option. Polars, now a genuine competitor to Pandas for dataframe work, is Rust. So is uv, which quietly became how a lot of teams manage Python environments. The pattern is consistent: Rust is eating the infrastructure around Python rather than competing with Python.

In July 2026 Rust entered the TIOBE top 10 for the first time, at 1.34%. Read that number carefully in both directions. Top 10 is a real milestone. 1.34% is also a reminder of how far behind the incumbents it remains, and Stack Overflow’s 14.8% usage says the same thing.

What it is bad at: being the language you write a model in. The training ecosystem is thin and will stay thin, because the research community has no reason to move. The learning curve is real and lands hardest on exactly the people most AI teams hire, who tend to come from Python and statistics rather than systems programming.

Choose it if: you are building inference services, data pipelines, or the tooling underneath a model, and you want C++ performance without C++ memory bugs.


6. Java

Java is on this list for an unglamorous reason: an enormous amount of the world’s business logic is written in it, and that is where models have to be applied.

Fraud scoring, recommendation, document classification, risk models. The model gets trained in Python by a data science team and then has to run inside a system that a bank has been maintaining since 2009. Rewriting that system is not on the table. So you export to ONNX and serve it from Java, or you use Deep Java Library, or Spring AI for the LLM-calling side. Stack Overflow has Java at 29.4% usage in 2025 and TIOBE at 8.03% in July 2026, and neither number is going anywhere.

This is a deployment-and-integration answer, not a research answer, and articles that present Java as an AI development language in its own right are being generous.

What it is bad at: the experimental loop. There is no Jupyter culture, the libraries lag Python’s by years, and nobody publishes a paper with a Java reference implementation.

Choose it if: the model has to live inside a JVM system that already exists. That is the whole case, and it is a good enough one.


7. Swift

One correction first, because this article got it wrong before and the same error is everywhere else.

The previous version of this page credited Swift’s AI relevance partly to “Swift for TensorFlow’s influence on the language.” Swift for TensorFlow was cancelled in February 2021 and the repository was archived in March 2022. It is not a current consideration for anyone. Some differentiable-programming work did make it into the Swift compiler, but citing a project archived four years ago as a live reason to pick a language is how these lists rot.

The real case for Swift is narrower and stronger: on-device inference on Apple hardware. Core ML, the Neural Engine, and MLX for Apple silicon give you models running locally with no server, no latency, and no user data in transit. If you are shipping an iOS app with AI in it, this is not one option among several. It is the option.

What it is bad at: existing outside Apple’s ecosystem. Swift on Linux is real and largely irrelevant to AI work. Training is not really a thing here. Stack Overflow puts Swift at 5.4% usage, which reflects a language doing one job for one platform.

Choose it if: your AI ships inside an iOS, macOS, or visionOS app. Otherwise skip it entirely.


8. R

R is last because it is shrinking, and it is here because in its remaining territory nothing has replaced it.

That territory is statistics done seriously. Biostatistics, clinical trials, epidemiology, econometrics. CRAN holds decades of peer-reviewed statistical methods with no Python equivalent, and when a regulator wants a survival analysis, the accepted path frequently runs through R. ggplot2 remains better at exploratory visualisation than anything in Python, which people find annoying to admit.

TIOBE has R ninth at 1.69% in July 2026. Stack Overflow puts it at 4.9% usage. Both suggest a language with a committed base and no growth story, which is a fair description.

What it is bad at: deep learning and production. Wrappers around Keras and Torch exist and you will be a second-class citizen using them. Deploying R into a production service is possible and rarely pleasant.

Choose it if: your work is statistical inference in a regulated or academic field. If you are building an AI product, this is not your language and no amount of R affection changes that.


Comparison at a glance

LanguageReal job in AIStandout capabilityBiggest weaknessSO 2025 usage
PythonTraining, research, everything by defaultPyTorch, Hugging Face, the entire research ecosystemSlow in the hot path; GIL57.9%
C++The engine under the frameworksllama.cpp, ONNX Runtime, TensorRTBrutal developer experience23.5%
CUDA C++GPU kernels and performance workControl over memory hierarchyNVIDIA hardware onlyNot tracked
JavaScript / TypeScriptThe product users touchVercel AI SDK; in-browser inferenceCannot realistically train66% / 43.6%
RustInference services and Python’s toolingtokenizers, Candle, Polars, uvThin training ecosystem; steep curve14.8%
JavaServing models inside existing enterprise systemsONNX Runtime, DJL, Spring AINo experimental culture29.4%
SwiftOn-device AI on Apple hardwareCore ML, Neural Engine, MLXApple ecosystem only5.4%
RSerious statistics in regulated fieldsCRAN, ggplot2, survival analysisDeep learning and deployment4.9%
Usage figures: Stack Overflow Developer Survey 2025, all respondents. The 2026 survey has not published results.

What did not make the cut

The previous version of this article ranked fifteen languages. Seven are gone. Padding a list to a round number is how you end up recommending Prolog to someone building a chatbot.

  • Julia – solves a real problem, has been about to break through for a decade
  • Go – runs AI infrastructure, is not an AI language
  • Scala – a language you inherit via Spark, not one you pick
  • Kotlin – gets Java’s answer through JVM interop
  • Mojo – still beta, still closed source
  • Prolog – nostalgia presented as advice
  • PHP – calls models, does not build them

Julia

The hardest cut, and the one that will draw complaints. Julia genuinely solves the two-language problem, its multiple dispatch is elegant, and SciML is excellent work. It has also been about to break through for roughly a decade. It does not appear in Stack Overflow’s usage table at a level worth reporting, and outside scientific computing and a few research groups the hiring market barely acknowledges it. If your work is differential equations and simulation, look at Julia seriously. If your work is AI, the ecosystem is not there and recommending it to a general audience would be doing you a disservice.

Go

Go is genuinely important to AI, and not as an AI language. Ollama is written in Go. So is much of the orchestration and serving infrastructure models run on top of. But you are not developing AI in Go, you are operating it, and the ML library ecosystem is close to nonexistent. It belongs on a list of languages for AI infrastructure engineers, which is a different article.

Scala

Scala’s AI case is Spark, and Spark’s Python API is good enough now that new teams do not reach for Scala. Stack Overflow has it at 2.6%. It is a language you inherit rather than select.

Kotlin

A better Java, and for AI purposes that means it gets Java’s answer: ONNX and DJL through JVM interop. KotlinDL has not made Kotlin a distinct AI choice. On Android you are mostly calling TensorFlow Lite or a hosted API, which any JVM language does equally well.

Mojo

Mojo is the most interesting language here and still cannot be recommended. The pitch – Python’s syntax with systems performance, built on MLIR by the people who built LLVM and Swift – is real and the benchmarks are striking. But as of July 2026 the current release is v1.0.0b2, shipped 18 June 2026. That “b” is beta. And after three years of “open source soon,” Modular’s own releases page still says Mojo “will be open source soon,” with an update promised at ModCon ’26.

Reaching 1.0 beta is real progress and this entry may need rewriting within a year. Today, betting a project on a closed-source pre-1.0 language controlled by one venture-funded company is a decision you make with your eyes open, not one an article should make for you.

Prolog

Prolog is on these lists because of what AI meant in 1985. Logic programming is a beautiful idea and expert systems were a real technology. Neither is what anyone means by AI development in 2026. Nobody is choosing Prolog for a new project, and listing it as a top-15 language for AI development is nostalgia presented as advice.

PHP

PHP was in the previous list at number 15 with “(with AI Integration)” attached, which gives the game away. Calling an API is not AI development in any language. PHP runs a large share of the web and will call plenty of models over HTTP, and that is a fine thing for it to do. It does not make it a language for building AI.


Picking one, honestly

You are new to this. Python. There is no second option and the people telling you to consider alternatives are making conversation, not giving advice. Learn Python properly, learn NumPy, then pick a framework.

You are already a web developer. Stay in TypeScript. Most AI products are applications calling hosted models, and you already know how to build applications. Add Python when you need to train something, which may be never.

Inference is too slow or too expensive. The problem is rarely the language. Check batching, quantisation, and the model size first. If the profiler still points at your code, then Rust or C++.

You are in research. Python, and enough C++ or CUDA to read what your framework is doing when it surprises you.

You work at a large company with a big JVM codebase. Train in Python, export to ONNX, serve from Java. Do not fight the platform.

You want a specialisation nobody else has. CUDA. The supply of engineers who can write a competent kernel is tiny relative to demand.

If you are still deciding what to learn first, our guide to programming languages worth learning covers the ground beyond AI, and we have collected the best websites for learning Python if that is where you are starting. Once you have the language, the AI and ML frameworks you build on top are the next decision.


Where this is heading

Two things look likely, and neither is a prediction we would bet much on.

Rust keeps taking territory underneath Python without displacing it. That has been the pattern for five years and nothing in the July 2026 TIOBE entry suggests a change in direction, only in pace.

The second is that the question shifts. As models write more code, the language you choose matters somewhat less than the ecosystem you plug into, and Python’s ecosystem is the deepest by an enormous margin. That argument cuts in Python’s favour, not against it, which is not what people expected.

What we will not do is tell you Mojo takes over by 2028, or that some language nobody has shipped yet replaces Python. Those claims cost nothing to make and are how articles like this one ended up citing surveys that were never conducted.


Frequently asked questions

Is Python still the best language for AI in 2026?

Yes, and it is not close. Python leads the TIOBE index at 18.94% in July 2026, and every major framework treats it as the primary interface. Nothing on the horizon changes this within a few years.

Will Rust replace Python for AI?

No, and that framing misreads what is happening. Rust is replacing the C++ underneath Python – tokenizers, dataframes, inference servers, package tooling. Most Rust code in an AI stack is invoked from Python. The two are complements.

Should I learn Mojo?

Not as a first or second language. Mojo is at v1.0.0b2 as of June 2026, still in beta, and still not open source despite years of promises. Learn Python. If Mojo delivers, your Python knowledge transfers, which is the point of its design.

What is the fastest programming language for AI?

The question is malformed. Python training code runs at C++ speed because the tensor operations are C++ and CUDA. The language is not the bottleneck. Where raw speed genuinely matters – custom kernels, embedded inference – the answer is C++, CUDA, or Rust.

Do I need to know C++ to work in AI?

Not to start, and most AI engineers never write it. You need it if you work on frameworks, do performance engineering, or deploy to constrained hardware. Reading it is more useful than writing it, because eventually a stack trace disappears into it.

Is JavaScript good enough for AI development?

For building AI products, yes. The TypeScript SDK ecosystem is mature and in-browser inference through Transformers.js works for smaller models. For training, no – use Python.

What version of PyTorch is current?

PyTorch 2.13.0, released 8 July 2026. If an article mentions “PyTorch 3.0,” it is fabricated – that version has never existed. TensorFlow is on 2.21.0 and Keras on 3.15.0.

Is R worth learning for machine learning?

Only if you are heading into biostatistics, clinical research, or econometrics, where CRAN and regulatory precedent make it the standard. For general machine learning or AI products, learn Python instead.

Which AI language pays best?

We will not quote a salary figure, because the reliable public data is not granular enough to separate language from role, seniority, and location, and most numbers in circulation are aggregator guesswork. Directionally, CUDA and performance-engineering skills command a premium because the supply is small.