![\"Andrey's](\"https:\/\/www.newsbeep.com\/uk\/wp-content\/uploads\/2026\/07\/KwzoJr2LJhe2emF7HaPt3uROpVt1-5e83qx9.jpeg\"\/)
<\/p>\nDisclaimer: This article reflects my own opinions. I have a vested interest in the topic: I maintain the open-source Swift\/MLX language-models project and wrote a book in which all of the code is in Swift. Please read this article with that conflict of interest in mind. To help balance that perspective, every numerical claim is backed by a primary source, and Section 8 is devoted to the strongest counterarguments.<\/p>\n
\u201cPython is not designed to be fast, and it is not designed to be safe.\u201d\u00a0\u2014\u00a0Jeremy Howard,\u00a0co-founder of fast.ai\u00a0[37]<\/p>\n
This article is about the strangest trade-off in modern engineering:\u00a0the industry that computes faster than anything in human history conducts those computations in one of the slowest languages in the history of programming.\u00a0And about what happens once we stop treating that as a law of nature.<\/p>\n
1. Introduction: the oddity everyone got used to<\/p>\n
Let us begin with a scene that plays out every day in thousands of companies.<\/p>\n
A data centre.\u00a0Racks of accelerators,\u00a0each performing hundreds of trillions of operations per second.\u00a0Electrical power on the scale of a small city:\u00a0in 2024 the world\u2019s data centres consumed about 415 TWh,\u00a0and by 2030 the International Energy Agency expects roughly 945 TWh\u00a0\u2014\u00a0more than all of Japan consumes today,\u00a0with AI as the main driver of that growth\u00a0[48].\u00a0The engineers running all of this are,\u00a0quite possibly,\u00a0the highest-paid programmers on the planet.<\/p>\n
Now let us peek at their code.\u00a0It is written in a language that placed 26th out of 27 in the classic study of programming-language energy efficiency\u00a0[14].\u00a0A language that,\u00a0until October 2025,\u00a0was fundamentally incapable of executing bytecode on two threads at once\u00a0[20].\u00a0A language whose own creator candidly described it as\u00a0\u201cglue\u201d\u00a0for other people\u2019s fast components\u00a0[1].<\/p>\n
\u26a0\ufe0f\u00a0A common misconception.\u00a0\u201cIf all of AI is written in Python,\u00a0then Python must be technically the best fit for AI.\u201d\u00a0It is not\u00a0\u2014\u00a0and we will show why.\u00a0Python fits AI\u00a0historically\u00a0and\u00a0socially:\u00a0it had a ready-made scientific ecosystem and a low barrier to entry.\u00a0Technically,\u00a0the whole industry is built like a matryoshka doll:\u00a0Python on the outside,\u00a0C++\u00a0and CUDA within.\u00a0The question this article asks is what we pay for that doll\u00a0\u2014\u00a0and what happens if we open it.<\/p>\n
Let us agree on honesty right away\u00a0\u2014\u00a0it matters more than anything else.\u00a0We will\u00a0not\u00a0claim that Python is bad:\u00a0it is an outstanding language whose victory was earned.\u00a0We will\u00a0not\u00a0propose\u00a0\u201crewriting everything in Swift by Friday\u201d:\u00a0that is not how the world works,\u00a0and such attempts have already failed\u00a0\u2014\u00a0we will dissect exactly how.<\/p>\n
We will argue three things,\u00a0each of which rests on verifiable numbers:<\/p>\n
Python\u2019s dominance is an entrenched monopoly of habit, not a law of nature.\u00a0The king reigns deservedly, but the crown rests on network effects, not physics.
\nThe \u201cPython tax\u201d is real, measurable, and grows with the scale of the industry.\u00a0It is paid in microseconds of dispatch, gigawatts of electricity, and doubled engineering labour.
\nOn AI\u2019s new territories \u2014 local, mobile, energy-efficient \u2014 the choice is already being made,\u00a0and not in Python\u2019s favour. Swift is one of the most underrated candidates for the language that closes the gap.<\/p>\n
2. How Python became king (and why it deserved it)<\/p>\n
Let us give the king his due\u00a0\u2014\u00a0without that,\u00a0calling him overrated would be a cheap shot.<\/p>\n
Python\u2019s victory in machine learning was not an accident.\u00a0It was\u00a0planned\u00a0\u2014\u00a0by the language\u2019s creator himself.\u00a0Back in January 1998,\u00a0in a position paper titled\u00a0\u201cGlue It All Together With Python,\u201d\u00a0Guido van Rossum described the development model we now know as NumPy and PyTorch:\u00a0let C\/C++\u00a0programmers write the efficient computational components,\u00a0and let scientists\u00a0\u201cglue\u201d\u00a0them together with Python scripts\u00a0[1].\u00a0This was not a post-hoc excuse for slowness\u00a0\u2014\u00a0it was a strategy,\u00a0and it worked brilliantly.<\/p>\n
By the time the deep-learning boom struck,\u00a0Python had spent a decade and a half growing a scientific stack:\u00a0Numeric\u00a0\u2014\u00a01995,\u00a0SciPy and IPython\u00a0\u2014\u00a02001,\u00a0NumPy\u00a0\u2014\u00a02005\u20132006,\u00a0pandas\u00a0\u2014\u00a02008,\u00a0scikit-learn\u00a0\u2014\u00a0first release in 2010\u00a0[2].\u00a0When Google open-sourced TensorFlow in 2015 and Facebook released PyTorch in 2016,\u00a0the choice of frontend language was obvious:\u00a0the scientists already lived in Python.\u00a0From there the network effect closed on itself:\u00a0NumPy ended up in the software stack behind the discovery of gravitational waves and the first image of a black hole\u00a0[3],\u00a0every textbook and every course was written in Python,\u00a0and every new engineer learned it first.<\/p>\n
The numbers of dominance are impressive:<\/p>\n
Metric<\/p>\n
Value<\/p>\n
Source<\/p>\n
#1 language on GitHub in 2024 (overtaking JavaScript after its ~10-year run)<\/p>\n
Python; the driver \u2014 the generative-AI boom<\/p>\n
Octoverse 2024 [4]<\/p>\n
All-time record in ~24 years of the TIOBE index<\/p>\n
26.98% (July 2025) \u2014 above Java\u2019s 2001 record<\/p>\n
TIOBE \/ InfoWorld [6]<\/p>\n
Implementations of new research papers (Papers with Code, Q4 2022)<\/p>\n
~70% in PyTorch vs 4% in TensorFlow<\/p>\n
AssemblyAI [8]<\/p>\n
New AI repositories on GitHub (2025)<\/p>\n
Python: 582,196 (+50.7% YoY) \u2014 vs ~88K for JavaScript<\/p>\n
Octoverse 2025 [5]<\/p>\n
Largest yearly gain in the Stack Overflow Survey 2025<\/p>\n
Python: +7 pp \u2014 \u201cthe go-to language for AI and data science\u201d<\/p>\n
SO Survey 2025 [7]<\/p>\n
Arguing against this is pointless\u00a0\u2014\u00a0and we won\u2019t.\u00a0We merely note two cracks in the marble.\u00a0First:\u00a0the peak,\u00a0it seems,\u00a0has passed\u00a0\u2014\u00a0from the record 26.98%\u00a0in July 2025,\u00a0the TIOBE index slid to\u00a0~19%\u00a0by mid-2026\u00a0(Python is still\u00a0#1,\u00a0but the lead is melting) [6],\u00a0and in Octoverse 2025 TypeScript took first place by contributor count\u00a0[5].\u00a0The second crack is more interesting\u00a0\u2014\u00a0the next section is devoted to it.<\/p>\n
\ud83d\udcdc\u00a0A bit of history: \u201cthe second-best language for everything.\u201d\u00a0The Python community has long circulated a self-deprecating formula attributed to Van Lindberg:\u00a0\u201cPython is the second-best language for everything.\u201d\u00a0It is a compliment:\u00a0universality beats specialisation,\u00a0because the cost of switching between niches is zero.\u00a0But the compliment has a flip side that is voiced far less often:\u00a0if for\u00a0every\u00a0task there exists a better language,\u00a0then as the price of the task grows\u00a0\u2014\u00a0in money,\u00a0watts,\u00a0and milliseconds\u00a0\u2014\u00a0sooner or later a moment arrives when\u00a0\u201csecond-best\u201d\u00a0stops being good enough.\u00a0The AI industry,\u00a0as we are about to see,\u00a0has reached that moment.<\/p>\n
3. The king\u2019s secret: Python in AI isn\u2019t Python<\/p>\n
Brace yourself\u00a0\u2014\u00a0this is going to be disappointingly simple.<\/p>\n
Open the repository of PyTorch\u00a0\u2014\u00a0the primary tool of modern AI\u00a0\u2014\u00a0and look at the official language statistics.\u00a0Python is only\u00a064%\u00a0of the codebase.\u00a0The rest is C++\u00a0(28.4%),\u00a0CUDA\u00a0(2.6%),\u00a0C,\u00a0Objective-C++,\u00a0Metal,\u00a0assembly\u00a0[9].\u00a0The entire performant core of eager mode\u00a0\u2014\u00a0the ATen tensor library,\u00a0the CUDA kernels\u00a0\u2014\u00a0is written in C++.\u00a0NumPy tells the same story:\u00a061%\u00a0Python,\u00a033%\u00a0C.\u00a0In other words,\u00a0the\u00a0\u201cPython libraries for machine learning\u201d\u00a0are libraries\u00a0written in C++,\u00a0with Python as the polite receptionist at the front desk.<\/p>\n
\ud83e\uddea\u00a0Try it yourself (right now):\u00a0open\u00a0github.com\/pytorch\/pytorch\u00a0and click the coloured language bar under the file list.\u00a0Then do the same with\u00a0ollama\/ollama\u00a0(Go)\u00a0and\u00a0ggml-org\/llama.cpp\u00a0(C\/C++).\u00a0Three of the most popular tools of the AI era\u00a0\u2014\u00a0and in none of them is the performant part written in Python.\u00a0This takes two minutes and replaces ten paragraphs of our assurances.<\/p>\n
This arrangement of the world has a name\u00a0\u2014\u00a0the\u00a0two-language problem.\u00a0It was canonically formulated by the creators of Julia:\u00a0first in their 2012 manifesto\u00a0(\u201cWe want the speed of C with the dynamism of Ruby\u201d\u00a0[10]),\u00a0then in their programmatic SIAM Review paper,\u00a0where among the\u00a0\u201claws of nature\u201d\u00a0they refused to accept was this one:\u00a0\u201cOne must prototype in one language and then rewrite in another language for speed or deployment\u201d\u00a0[11].<\/p>\n
Here is what that\u00a0\u201claw\u201d\u00a0looks like in 2026:<\/p>\n
A researcher writes a model in Python.
\nThe speed comes from C++\/CUDA kernels written by other people in another language.
\nFor production, the model is converted into a third environment \u2014 a C++ runtime, GGUF, Core ML.
\nWhen something is slow at the seams (and it regularly is \u2014 see Section 5), only an engineer fluent in\u00a0both\u00a0worlds can fix it.<\/p>\n
\ud83d\udcd0\u00a0Analogy.\u00a0Python in AI is the conductor of an orchestra.\u00a0The conductor plays no instrument,\u00a0and that is fine:\u00a0his job is the baton;\u00a0the orchestra\u00a0(C++\u00a0and CUDA)\u00a0does the playing.\u00a0The analogy is accurate in another way that is mentioned less often:\u00a0if the conductor waves the baton ten times slower than the orchestra can play,\u00a0the orchestra starts\u00a0waiting for the baton.\u00a0Very expensive musicians sit and stare at the conductor.\u00a0Below we will show this is not a metaphor but a profiler trace:\u00a0unoptimised LLM engines were spending up to half their time on the\u00a0\u201cbaton waving\u201d\u00a0[30].<\/p>\n
It is important to understand:\u00a0this construction is neither a conspiracy nor stupidity.\u00a0It is a rational trade-off of its era.\u00a0But it has a price,\u00a0and the price can be measured.<\/p>\n
4. The price of habit: measuring the tax
\n4.1. What the interpreter costs<\/p>\n
The most-cited measurement is the study by Pereira et al.,\u00a0\u201cEnergy Efficiency across Programming Languages\u201d\u00a0(SLE 2017):\u00a027 languages,\u00a010 tasks from the Computer Language Benchmarks Game,\u00a0with energy,\u00a0time,\u00a0and memory measured\u00a0[14].\u00a0Normalising everything to C\u00a0(1.00),\u00a0the authors produced a table worth hanging on the wall of anyone who utters the words\u00a0\u201cAI energy crisis\u201d:<\/p>\n
Language<\/p>\n
Energy (\u00d7C)<\/p>\n
Time (\u00d7C)<\/p>\n
C<\/p>\n
1.00<\/p>\n
1.00<\/p>\n
Rust<\/p>\n
1.03<\/p>\n
1.04<\/p>\n
C++<\/p>\n
1.34<\/p>\n
1.56<\/p>\n
Java<\/p>\n
1.98<\/p>\n
1.89<\/p>\n
Swift<\/p>\n
2.79<\/p>\n
4.20<\/p>\n
Go<\/p>\n
3.23<\/p>\n
2.83<\/p>\n
JavaScript<\/p>\n
4.45<\/p>\n
6.52<\/p>\n
PHP<\/p>\n
29.30<\/p>\n
\u2014<\/p>\n
Ruby<\/p>\n
69.91<\/p>\n
\u2014<\/p>\n
Python<\/p>\n
75.88<\/p>\n
71.90<\/p>\n
Python ranks 26th out of 27 on energy\u00a0(thanks to Perl for bringing up the rear).\u00a0Across the study,\u00a0compiled languages spent on average 120 J per task,\u00a0interpreted ones\u00a0\u2014\u00a02,365 J:\u00a0a gap of roughly 20\u00d7\u00a0[14].\u00a0The extended journal version of 2021 confirmed the findings\u00a0[15].<\/p>\n
The gap between Python and Swift\u00a0\u2014\u00a0the subject of this article\u00a0\u2014\u00a0is\u00a0~27\u00d7 on energy and ~17\u00d7 on time.<\/p>\n
<\/p>\n
Fig. 1. Normalised energy consumption of programming languages (C = 1.00), logarithmic scale. Data: Pereira et al., SLE\u201917, Table 4 [14].<\/p>\n
\u26a0\ufe0f\u00a0Two honest caveats (as always).\u00a0First,\u00a0the measurements are from 2017:\u00a0Swift was version 3.x back then,\u00a0and Python has sped up since\u00a0(more on that below\u00a0\u2014\u00a0spoiler:\u00a0not by 70\u00d7).\u00a0Second,\u00a0a recent paper by van Kempen et al.\u00a0(ASE 2025)\u00a0found methodological flaws in Pereira et al.\u00a0and showed that a language\u2019s energy consumption is almost entirely explained by its execution time\u00a0\u2014\u00a0\u201cenergy-efficient\u201d\u00a0languages do not exist separately from\u00a0\u201cfast\u201d\u00a0ones\u00a0[16].\u00a0Note that this correction\u00a0does not rescue\u00a0Python.\u00a0It merely collapses two of its failures into one\u00a0\u2014\u00a0time.\u00a0On current Benchmarks Game measurements,\u00a0the best Python program solves n-body in\u00a0~6 minutes versus 2.10 s for C and 5.45 s for Swift\u00a0(~170\u00d7\u00a0and\u00a0~66\u00d7);\u00a0on spectral-norm\u00a0\u2014\u00a090.4 s versus 0.40 s for C and 1.45 s for Swift\u00a0(~226\u00d7\u00a0and\u00a0~62\u00d7) [17, 18].\u00a0Yes,\u00a0the fastest C versions there use hand-written SIMD intrinsics\u00a0\u2014\u00a0but the Swift versions get by without assembly-level magic.<\/p>\n
![\"Andrey's](\"https:\/\/www.newsbeep.com\/uk\/wp-content\/uploads\/2026\/07\/KwzoJr2LJhe2emF7HaPt3uROpVt1-bg93q6y.jpeg\"\/)
<\/p>\n
Fig. 2. Wall time of the best programs on the n-body and spectral-norm tasks (Computer Language Benchmarks Game, mid-2026), logarithmic scale [17, 18].<\/p>\n
4.2. The GIL: three decades of solitude (population: one thread)<\/p>\n
The second line item of the tax is parallelism.\u00a0The\u00a0GIL\u00a0(Global Interpreter Lock),\u00a0introduced in 1992,\u00a0allows only one thread at a time to execute Python bytecode.\u00a0For over thirty years,\u00a0the language of the world\u2019s foremost parallel-computing industry could not do parallelism across CPU cores.<\/p>\n
In fairness:\u00a0the ice has begun to move.\u00a0Python 3.13\u00a0(October 2024)\u00a0introduced an experimental GIL-free build\u00a0\u2014\u00a0at the cost of\u00a0~40%\u00a0slowdown of single-threaded code\u00a0[19].\u00a0In Python 3.14\u00a0(October 2025)\u00a0it became officially supported,\u00a0with the penalty down to 5\u201310%\u00a0[20].\u00a0But per the PEP 703 plan this is only phase 2 of 3:\u00a0free-threading has still not become the\u00a0default\u00a0build,\u00a0and the world still downloads Python with the GIL.<\/p>\n
4.3. \u201cWe\u2019ll make CPython five times faster\u201d<\/p>\n
Perhaps we should just wait\u00a0\u2014\u00a0and Python will become fast on its own?\u00a0The industry ran that experiment on itself,\u00a0on Microsoft\u2019s budget.<\/p>\n
In 2021,\u00a0at Guido van Rossum\u2019s initiative,\u00a0the Faster CPython team assembled at Microsoft;\u00a0the\u00a0\u201cShannon Plan\u201d\u00a0promised roughly a 5\u00d7\u00a0speedup over four releases.\u00a0The results:\u00a0Python 3.11 delivered\u00a0+25%\u00a0on average,\u00a03.12\u00a0\u2014\u00a0~5%,\u00a0and the new tail-call interpreter in 3.14\u00a0\u2014\u00a0another 3\u20135%.\u00a0Team member Ken Jin summed it up:\u00a0Python 3.14 is\u00a0\u201croughly 20\u201340%\u00a0faster\u201d\u00a0than 3.10\u00a0\u2014\u00a0that is 1.2\u20131.4\u00d7\u00a0instead of five\u00a0[21].\u00a0And in May 2025 Microsoft laid off most of the team,\u00a0including tech lead Mark Shannon,\u00a0and the project moved to\u00a0\u201ccommunity stewardship\u201d\u00a0[21].<\/p>\n
\ud83d\udca1\u00a0Key idea of this section.\u00a0A fortyfold gap does not get closed by heroic twenty-per-cent gains.\u00a0This is no reproach to the CPython engineers\u00a0\u2014\u00a0they did brilliant work.\u00a0It is a property of the problem itself:\u00a0a dynamic interpreted language pays\u00a0by construction,\u00a0on every single operation,\u00a0for type checks,\u00a0attribute lookups,\u00a0and dispatch that a compiled language pays for once\u00a0\u2014\u00a0at compile time.\u00a0An empty function call in CPython costs\u00a0~37 ns;\u00a0in a compiled language it either costs single nanoseconds or inlines away to zero.<\/p>\n
5. \u201cBut the GPU does all the math!\u201d \u2014 when that\u2019s true, and when it isn\u2019t<\/p>\n
This is the strongest counterargument,\u00a0and it must be addressed without straw men.\u00a0It goes like this:\u00a0Python is merely the orchestrator; 99% of the time is spent in CUDA kernels, so you could write the rest in BASIC for all anyone cares.<\/p>\n
When the model is big and the batch is fat\u00a0\u2014\u00a0this is the plain truth.\u00a0Asynchronous dispatch hides Python\u2019s overhead:\u00a0while the GPU spends a minute grinding matrices,\u00a0Python has ample time to leisurely prepare the next command.\u00a0The JAX documentation describes this mechanism explicitly\u00a0\u2014\u00a0and Patrick Kidger puts the upshot neatly:\u00a0JAX uses Python as a\u00a0metalanguage\u00a0in which you write a program for the real executor\u00a0\u2014\u00a0the XLA compiler\u00a0[12, 13].<\/p>\n
The problem is that the boundary of\u00a0\u201cwhen this is true\u201d\u00a0is shrinking fast.\u00a0Here are the measurements:<\/p>\n
Launching a single CUDA kernel\u00a0costs microseconds of host time: in NVIDIA\u2019s classic example, a kernel executes in 2.9 \u00b5s, but with launch and synchronisation it comes to 9.6 \u00b5s \u2014 the overhead exceeds the useful work [24]. GPUs have become ~15\u00d7 faster at compute in six years [22] \u2014 while CPUs and Python stayed put. The gap widens with every hardware generation.
\nPyTorch eager on small tensors\u00a0manages only ~280 thousand operations per second \u2014 roughly a hundred times fewer than the same loop in plain Python without tensors: nearly everything is eaten by framework dispatch [25].
\nData.\u00a0An analysis of millions of ML jobs in Google\u2019s infrastructure (VLDB 2021): 30% of all compute time goes to the input pipeline \u2014 reading, decoding, augmentations \u2014 and 20% of jobs spend more than a third of their time on it [26]. The FFCV project showed that with a standard Python data loader, the \u201cidealised\u201d training time is almost 30\u00d7 smaller than the time needed merely to process the images [27].
\nLLM serving.\u00a0The very composition of the engines is telling: in the original vLLM paper, the authors describe the system as \u201c8.5K lines of Python and 2K lines of C++\/CUDA,\u201d with the 2\u20134\u00d7 throughput win delivered precisely by custom CUDA kernels and memory management [28]. The SGLang authors write that an unoptimised inference engine can spend\u00a0up to half its time\u00a0on CPU overhead \u2014 batch scheduling, allocations, prefix matching [30]. The vLLM team, rewriting the architecture for V1, stated the goal outright \u2014 near-zero CPU overhead: a Llama-8B generation step on an H100 takes ~5 ms, and the Python subsystems simply cannot keep up with the GPU; the result \u2014 up to 1.7\u00d7 higher throughput [29].<\/p>\n
But the most eloquent admission came from the creators of PyTorch themselves.\u00a0The PyTorch 2.0 announcement opens with the words\u00a0\u201cFrom day one, we knew the performance limits of eager execution\u201d\u00a0\u2014\u00a0and explains that substantial parts of PyTorch had to be moved into C++,\u00a0taking it further from\u00a0\u201chackability\u201d\u00a0[22].\u00a0The answer was\u00a0torch.compile:\u00a0intercepting Python bytecode and compiling it to Triton and C++\u00a0\u2014\u00a0a geomean speedup of 2.27\u00d7\u00a0on inference and 1.41\u00d7\u00a0on training on an A100 across 180+\u00a0real-world models\u00a0(ASPLOS 2024) [23].<\/p>\n
\ud83d\udca1\u00a0Key idea of this section.\u00a0Notice the pattern:\u00a0every time the \u201cPython stack\u201d gets faster, the speedup consists of removing Python from somewhere.\u00a0From the math kernels\u00a0(C++\/CUDA),\u00a0from data loading\u00a0(tf.data,\u00a0DALI,\u00a0FFCV),\u00a0from the serving scheduler\u00a0(vLLM V1,\u00a0SGLang),\u00a0from the very execution of the model\u00a0(torch.compile turns your Python into not-Python).\u00a0The syntax stays\u00a0\u2014\u00a0the execution semantics leave.\u00a0The king reigns,\u00a0but no longer governs.<\/p>\n
6. The industry is already voting with its feet<\/p>\n
Now let us look not at benchmarks but at behaviour\u00a0\u2014\u00a0at what the industry\u00a0actually uses\u00a0when performance goes from\u00a0\u201cnice to have\u201d\u00a0to\u00a0\u201cmandatory.\u201d<\/p>\n
llama.cpp.\u00a0In March 2023,\u00a0Georgi Gerganov published an LLM inference engine in pure C\/C++\u00a0\u2014\u00a0with no Python in the runtime at all.\u00a0By July 2026 it had 119K GitHub stars and the status of the foundation of the entire local-AI ecosystem:\u00a0it powers Ollama\u00a0(175K stars\u00a0\u2014\u00a0more than PyTorch itself;\u00a0Ollama is written in Go),\u00a0LM Studio,\u00a0and dozens of other tools,\u00a0while the GGUF format became the industry standard\u00a0\u2014\u00a0the Hugging Face Hub alone hosts about 45K GGUF checkpoints\u00a0[31, 32].\u00a0In February 2026,\u00a0Hugging Face\u00a0\u2014\u00a0the heart of the Python ML ecosystem\u00a0\u2014\u00a0brought Gerganov\u2019s team onboard,\u00a0calling llama.cpp\u00a0\u201cthe fundamental building block for local inference\u201d\u00a0[31].<\/p>\n
Rust inside the Python world.\u00a0That same Hugging Face is systematically rewriting its own infrastructure in Rust:\u00a0the\u00a0tokenizers\u00a0library\u00a0(a gigabyte of text in under 20 seconds\u00a0[33]),\u00a0the\u00a0safetensors\u00a0format,\u00a0the\u00a0candle\u00a0framework.\u00a0The Python user never sees any of this\u00a0\u2014\u00a0and that is precisely the point:\u00a0to keep Python fast,\u00a0its internals are made non-Python.<\/p>\n
Apple MLX.\u00a0Apple built its ML framework for Apple Silicon with a C++\u00a0core and APIs in four languages,\u00a0with Swift as a first-class citizen.\u00a0The wording of Apple\u2019s engineers in the MLX Swift announcement deserves a quotation:\u00a0Swift\u00a0\u201ccombines the ease of use and high-level syntax of a language like Python with the speed of a compiled language like C++\u201d\u00a0[43].<\/p>\n
Edge.\u00a0ExecuTorch 1.0\u00a0\u2014\u00a0PyTorch\u2019s runtime for devices\u00a0\u2014\u00a0is a\u00a0\u201clightweight C++\u00a0runtime\u201d\u00a0with a 50 KB base footprint,\u00a0serving,\u00a0by the project\u2019s account,\u00a0billions of Meta users\u00a0[34].\u00a0Python does not live on a microcontroller\u00a0\u2014\u00a0and never has.<\/p>\n
Mojo.\u00a0Chris Lattner\u00a0\u2014\u00a0the creator of LLVM and Swift\u00a0\u2014\u00a0considers the problem real enough to build an entire language around it:\u00a0Python syntax atop an MLIR-grade compiler,\u00a0with demonstrations of a Mandelbrot speedup of up to 68,847\u00d7\u00a0over CPython\u00a0(after typing,\u00a0vectorisation,\u00a0and parallelisation across 88 cores\u00a0\u2014\u00a0a sporting result,\u00a0but a telling one) [35].\u00a0By May 2026 Mojo reached its 1.0 beta;\u00a0the compiler remains closed for now\u00a0[36].<\/p>\n
In fairness: Swift is neither alone in this movement nor first.\u00a0The alternatives hold real trump cards.\u00a0Rust\u00a0is the champion of Pereira\u2019s table among languages with safety guarantees\u00a0(1.03\u00d7\u00a0versus C\u00a0[14]):\u00a0memory without a garbage collector and without segfaults\u00a0\u2014\u00a0exactly what infrastructure needs;\u00a0it is no accident that Hugging Face builds tokenizers,\u00a0safetensors,\u00a0and candle on it,\u00a0while the Burn framework proves that a complete ML stack in Rust is possible.\u00a0JAX\u00a0is the most elegant realisation of the\u00a0\u201cPython as metalanguage\u201d\u00a0idea:\u00a0the composition of jit\/grad\/vmap atop the XLA compiler gives research code brevity and speed at once\u00a0[13].\u00a0Mojo\u00a0strikes at the very heart of the problem\u00a0\u2014\u00a0a compiled language for Pythonistas with no retraining\u00a0\u2014\u00a0and behind it stands a man who has already built industrial compiler ecosystems twice\u00a0[35].<\/p>\n
So why does this article bet on Swift?\u00a0Because of a combination the others do not yet have.\u00a0Rust is brilliant,\u00a0but the borrow checker and the learning curve are the opposite of\u00a0\u201creads like pseudocode\u201d;\u00a0JAX remains a Python frontend,\u00a0with all the deployment consequences;\u00a0Mojo is still a beta with a closed compiler\u00a0[36].\u00a0Swift alone,\u00a0today,\u00a0combines a mature industrial toolchain,\u00a0almost-Python syntax,\u00a0compiled-language speed,\u00a0and the systemic on-device niche with an entire platform behind it.\u00a0For the article\u2019s main thesis,\u00a0though,\u00a0this rivalry is secondary:\u00a0a win for any of the four is a defeat for the two-language problem.<\/p>\n
\ud83d\udcd0\u00a0Analogy.\u00a0Picture a city with one official language,\u00a0where all the\u00a0engine rooms\u00a0\u2014\u00a0the power plants,\u00a0the waterworks,\u00a0the metro\u00a0\u2014\u00a0de facto speak another.\u00a0That is exactly what the AI stack looks like in 2026:\u00a0Python upstairs;\u00a0C++,\u00a0CUDA,\u00a0Rust,\u00a0Go,\u00a0and Swift in the engine room.\u00a0The debate over\u00a0\u201cwhether AI needs a compiled language\u201d\u00a0has been settled by practice:\u00a0it is already there.\u00a0The open question reads differently\u00a0\u2014\u00a0must a\u00a0human\u00a0write in two languages,\u00a0or can one language walk the whole way from the idea to the engine room?<\/p>\n
7. The Swift case: the speed of C, with almost-Python syntax<\/p>\n
And so we arrive at the second half of the thesis.\u00a0Why Swift,\u00a0specifically?\u00a0Let us go point by point\u00a0\u2014\u00a0with numbers,\u00a0and where there are no numbers,\u00a0we will say so honestly.<\/p>\n
7.1. Speed and energy<\/p>\n
In Pereira\u2019s table,\u00a0Swift stands at 2.79\u00d7\u00a0on energy and 4.20\u00d7\u00a0on time versus C\u00a0[14];\u00a0recall that Python stands at 75.88\u00d7\u00a0and 71.90\u00d7.\u00a0On the current numeric tasks of the Benchmarks Game,\u00a0the best Swift programs run close to C\u00a0(n-body:\u00a05.45 s versus 2.10 s;\u00a0on fannkuch-redux\u00a0\u2014\u00a0near parity),\u00a0sagging on string-heavy tasks\u00a0[17, 18].\u00a0Swift compiles through LLVM to machine code;\u00a0there is no interpreter here and no JIT warm-up.<\/p>\n
Memory is managed via\u00a0ARC\u00a0(automatic reference counting)\u00a0\u2014\u00a0reference counting resolved at compile time instead of a tracing garbage collector.\u00a0This is not only about speed but about\u00a0predictability:\u00a0there are no GC pauses.\u00a0How much that matters in production,\u00a0Apple demonstrated on its own Password Monitoring service,\u00a0rewritten from Java to server-side Swift:\u00a0+40%\u00a0throughput,\u00a0sub-millisecond latency for 99.9%\u00a0of requests at billions of requests per day,\u00a0per-instance memory down from\u00a0tens of gigabytes\u00a0to\u00a0hundreds of megabytes,\u00a0freeing about half of the Kubernetes capacity\u00a0[42].<\/p>\n
And where Python suffered under the GIL,\u00a0Swift 6 went in the opposite direction:\u00a0a strict-concurrency mode in which\u00a0data races are diagnosed at compile time\u00a0as errors\u00a0[44].\u00a0Consider the contrast:\u00a0one language spent three decades serialising threads behind a global lock;\u00a0the other statically proves your concurrent code correct before the first run.<\/p>\n
7.2. Syntax: spot the difference<\/p>\n
\u201cCompiled means verbose and scary\u201d?\u00a0Here is the attention mechanism\u00a0\u2014\u00a0the heart of the transformer\u00a0\u2014\u00a0in both languages:<\/p>\n
# Python (NumPy style)
\ndef attention(q, k, v):
\n scores = q @ k.T \/ math.sqrt(k.shape[-1])
\n return softmax(scores) @ v<\/p>\n
\/\/ Swift (MLX)
\nfunc attention(_ q: MLXArray, _ k: MLXArray, _ v: MLXArray) -> MLXArray {
\n let scores = q.matmul(k.T) \/ sqrt(Float(k.dim(-1)))
\n return softmax(scores, axis: -1).matmul(v)
\n}<\/p>\n
The difference is a typed signature.\u00a0But that is not a tax\u00a0\u2014\u00a0it is a gift:\u00a0the compiler now\u00a0knows\u00a0these are tensors and will not let you accidentally pass a token index where a probability was expected.\u00a0Types are comments that never go stale and are checked by a machine.<\/p>\n
\ud83e\uddea\u00a0Try it yourself.\u00a0If you have a Mac,\u00a0the Swift compiler is already installed,\u00a0out of the box.\u00a0Save a couple of lines into\u00a0hello.swift,\u00a0run\u00a0swift hello.swift\u00a0\u2014\u00a0and you are already writing in a compiled language with the REPL-like ease of a script.\u00a0Ready-made,\u00a0line-by-line-annotated implementations of language models in Swift\u00a0\u2014\u00a0from n-grams to a mini-GPT on MLX\u00a0\u2014\u00a0live in the open repository\u00a0github.com\/asaptf\/swift-language-models:\u00a0clone and run.<\/p>\n
7.3. The lesson of Swift for TensorFlow: obituary or prologue?<\/p>\n
Here the most inconvenient fact for our thesis must be spoken,\u00a0and we will volunteer it ourselves:\u00a0Google already tried to make Swift the language of machine learning\u00a0\u2014\u00a0and failed.<\/p>\n
\ud83d\udcdc\u00a0A bit of history.\u00a0The\u00a0Swift for TensorFlow\u00a0project was announced in March 2018;\u00a0it was led by Chris Lattner,\u00a0the creator of Swift and LLVM.\u00a0The idea was radical:\u00a0build\u00a0differentiable programming\u00a0\u2014\u00a0automatic gradient computation\u00a0\u2014\u00a0directly into the compiler of a general-purpose language\u00a0[38].\u00a0Jeremy Howard of fast.ai called it\u00a0\u201cthe first serious effort I\u2019ve seen to incorporate differentiable programming deep in to the heart of a widely used language that is designed from the ground up for performance,\u201d\u00a0and moved part of his famous course onto Swift\u00a0[37].\u00a0Lattner left Google in January 2020;\u00a0in February 2021 the project was put into archive mode\u00a0[39].\u00a0The cause of death was not the technology but the ecosystem gap:\u00a0not even Google could rewrite the NumPy universe from scratch.<\/p>\n
So\u00a0\u2014\u00a0obituary or prologue?\u00a0Three circumstances argue for the latter.<\/p>\n
First,\u00a0the legacy of S4TF did not die:\u00a0automatic-differentiation support remained in the mainline Swift compiler as an experimental feature,\u00a0and industry keeps developing it.\u00a0PassiveLogic builds autonomous building-control systems on differentiable Swift and publishes measurements:\u00a0a physical heat-transfer simulation on a CPU\u00a0\u2014\u00a0~0.03 ms per forward+backward cycle versus 8.16 ms for PyTorch\u00a0(238\u00d7)\u00a0and 11.0 ms for TensorFlow\u00a0(322\u00d7) [40];\u00a0in 2024 the same company claimed an energy-efficiency record for autodiff\u00a0\u2014\u00a034 J\/GOps against tens of thousands for the big frameworks\u00a0[41].\u00a0The honesty caveat:\u00a0this is a CPU-class workload with small,\u00a0irregular computations\u00a0\u2014\u00a0that is,\u00a0precisely the territory where Python dispatch is murderous\u00a0\u2014\u00a0and the measurements are the company\u2019s own.<\/p>\n
Second,\u00a0the context has changed.\u00a0In 2018,\u00a0Swift in ML was a stranger with no hardware and no niche.\u00a0In 2026 it has both:\u00a0the entire Apple Silicon line with unified memory,\u00a0MLX with a full-fledged Swift API\u00a0[43],\u00a0swift-transformers\u00a01.0 from Hugging Face\u00a0[47],\u00a0and the\u00a0Foundation Models framework\u00a0\u2014\u00a0the system Swift API to the on-device LLM introduced at WWDC 2025,\u00a0where the\u00a0@Generable\u00a0macro guarantees structurally correct model output straight into Swift types via constrained decoding\u00a0[45].\u00a0Note what is\u00a0absent\u00a0here:\u00a0a Python layer.\u00a0A 3-billion-parameter model,\u00a0quantised to 2 bits,\u00a0runs in your pocket\u00a0\u2014\u00a0and Swift talks to it directly.<\/p>\n
Third,\u00a0Swift has stopped being\u00a0\u201cApple-only\u201d:\u00a0official Linux and Windows support,\u00a0an Android workgroup\u00a0(2025),\u00a0Embedded Swift for microcontrollers,\u00a0deep C++\u00a0interop\u00a0[44].<\/p>\n
\ud83d\udca1\u00a0Key idea of this section.\u00a0S4TF failed by storming the Python fortress head-on\u00a0\u2014\u00a0on the territory of server-side training,\u00a0where Python\u2019s ecosystem advantage is absolute.\u00a0The new game is being played on a different board:\u00a0on-device,\u00a0edge,\u00a0local inference\u00a0\u2014\u00a0territories where Python has\u00a0no\u00a0army,\u00a0because its runtime simply does not exist there.\u00a0It is exactly there that a compiled language with Python-grade readability is not an\u00a0\u201calternative\u201d\u00a0but the shortest path.<\/p>\n
8. Honest counterarguments (and what they actually prove)<\/p>\n
Scientific integrity demands that the prosecution be heard\u00a0\u2014\u00a0that is,\u00a0Python\u2019s defence.\u00a0Here are the four strongest arguments and our replies.<\/p>\n
\u201cThe ecosystem decides, and Python has it.\u201d\u00a0True.\u00a0582 thousand new AI repositories in a year\u00a0[5],\u00a0every textbook,\u00a0every job posting.\u00a0Our reply:\u00a0we are not proposing a battle for server-side training\u00a0\u2014\u00a0Python will hold it for a long time,\u00a0and that is fine.\u00a0The thesis is different:\u00a0the\u00a0new\u00a0niches\u00a0(see Section 9)\u00a0are free of that network effect,\u00a0and there the language choice is open again.\u00a0And inside the citadel itself the performant code is no longer Pythonic\u00a0\u2014\u00a0the only remaining dispute is about which language the storefront is written in.<\/p>\n
\u201cJulia already tried \u2014 and where is it now?\u201d\u00a0The lesson of Julia is real:\u00a0a language\u2019s speed does not beat ecosystem quality\u00a0(Kidger describes leaving Julia after months of fighting incorrect gradients\u00a0[12]).\u00a0But note what exactly that lesson proves:\u00a0technically fast languages exist in abundance;\u00a0the deficit is in engineering maturity and a sponsor.\u00a0Swift\u2019s sponsor is a company with a multi-trillion capitalisation for which on-device AI is existentially necessary,\u00a0plus a living industrial toolchain and millions of developers.\u00a0That is not a guarantee\u00a0\u2014\u00a0but it is a difference.<\/p>\n
\u201cPython is speeding up too: free-threading, JIT, torch.compile.\u201d\u00a0It is\u00a0\u2014\u00a0and we honestly cited the numbers:\u00a0+20\u201340%\u00a0over five releases\u00a0[21],\u00a0free-threading with a 5\u201310%\u00a0penalty\u00a0[20],\u00a0torch.compile at 2.27\u00d7\u00a0[23].\u00a0But read the structure of these victories closely:\u00a0free-threading fixes something compiled languages never had;\u00a0torch.compile speeds Python up by\u00a0ceasing to execute it.\u00a0This is brilliant engineering that reinforces our thesis:\u00a0the future of Python performance lies in Python not being executed.<\/p>\n
\u201cThe overhead is pennies next to the GPU.\u201d\u00a0Already dissected in Section 5 with numbers;\u00a0let us add the economics of scale.\u00a0ChatGPT handles 2.5+\u00a0billion requests per day\u00a0[55];\u00a0by Sam Altman\u2019s estimate,\u00a0the average query costs 0.34 Wh\u00a0[54] (methodology undisclosed\u00a0\u2014\u00a0keep your scepticism).\u00a0Multiplying the two gives\u00a0~0.31 TWh per year just for the answers of a single product.\u00a0At such volumes,\u00a0even 5\u201310%\u00a0of software overhead is 15\u201331 GWh annually\u00a0\u2014\u00a0the yearly consumption of a small town.\u00a0The pennies stopped being pennies when the meter started spinning in the billions.<\/p>\n
\u26a0\ufe0f\u00a0A caveat you did not expect from this article.\u00a0AI\u2019s energy efficiency per task is\u00a0improving\u00a0\u2014\u00a0at a pace the IEA calls unprecedented in the history of energy\u00a0[49].\u00a0And one should be sober about loud AI-energy numbers in general:\u00a0the famous training-carbon estimate from Strubell et al.\u00a0[52]\u00a0was later corrected downward by Google engineers by a factor of 18\u201388\u00a0[53]\u00a0\u2014\u00a0a lesson in caution we try to absorb.\u00a0Our argument is not that AI will wreck the power grid and only Swift can save it.\u00a0It is humbler and firmer:\u00a0when inference is up to 90%\u00a0of the cost of an ML workload\u00a0(AWS\u00a0[50])\u00a0and\u00a0~3\/5 of its energy\u00a0(Google\u00a0[51]),\u00a0software overhead stops being a matter of taste and becomes a budget line.\u00a0An engineering culture that tunes kernels down to microseconds yet shrugs at a 70\u00d7\u00a0gap in its orchestration language simply has not yet converted its habits into megawatts.<\/p>\n
9. New horizons: what opens up beyond Python<\/p>\n
Everything said so far would be mere grumbling at a successful language,\u00a0were it not for the main point:\u00a0the most interesting territories of the coming years lie where Python physically cannot reach.<\/p>\n
Horizon 1: AI in your pocket.\u00a0Apple Intelligence\u2019s\u00a0~3-billion-parameter model generates 30 tokens per second right on an iPhone\u00a0\u2014\u00a0offline,\u00a0private,\u00a0free\u00a0[46];\u00a0the third generation\u00a0(June 2026)\u00a0added a sparse 20-billion-parameter model\u00a0[56].\u00a0There is no CPython here and there never will be:\u00a0the budgets of battery,\u00a0memory,\u00a0and latency leave room only for a compiled stack.\u00a0This entire world is programmed from Swift\u00a0\u2014\u00a0including guaranteed-typed LLM output via\u00a0@Generable\u00a0[45].<\/p>\n
Horizon 2: local and server-side inference.\u00a0The llama.cpp\/GGUF ecosystem has already proven that an inference engine does not need Python\u00a0[31].\u00a0Server-side Swift,\u00a0with ARC and no GC pauses,\u00a0is a ready-made candidate for the API layer of the same problem class Apple closed with Password Monitoring\u00a0[42].\u00a0More and more often the bottleneck is not the matrix on the GPU but the orchestration around it:\u00a0agentic loops,\u00a0tool calls,\u00a0millions of small decisions on the CPU.\u00a0That is exactly the territory where an interpreter loses to a compiler by a crushing score.<\/p>\n
Horizon 3: the end of the two-language problem.\u00a0The deepest shift is methodological.\u00a0Today\u2019s path\u00a0\u2014\u00a0\u201cprototype in Python\u00a0\u2192\u00a0rewrite in C++\u00a0\u2192\u00a0convert for the device\u201d\u00a0\u2014\u00a0is doubled labour and walls between teams.\u00a0A language with the readability of a prototype and the speed of production lets\u00a0one person\u00a0walk the path from idea to device\u00a0\u2014\u00a0as Julia dreamed in 2012\u00a0[10],\u00a0as S4TF attempted in 2018\u00a0[38],\u00a0and as the Swift stack\u00a0\u2014\u00a0MLX,\u00a0differentiable Swift,\u00a0Foundation Models\u00a0\u2014\u00a0makes possible today,\u00a0for the first time,\u00a0in its natural niche.\u00a0The ability to read and\u00a0write\u00a0the whole stack top to bottom is not just speed.\u00a0It is understanding instead of incantations.<\/p>\n
\ud83d\udcd0\u00a0One last analogy.\u00a0The Python ecosystem resembles imperial units\u00a0\u2014\u00a0feet and pounds:\u00a0historically earned,\u00a0grown into the infrastructure,\u00a0backed by the habit of hundreds of millions of people.\u00a0One can live with them\u00a0(America does).\u00a0But every new calculation requires conversion coefficients,\u00a0every junction of systems is a source of error,\u00a0and every so often a Mars probe shatters against it.\u00a0Nobody will abolish feet by decree\u00a0\u2014\u00a0but every new bridge is quietly designed by engineers in metres.<\/p>\n
10. What we\u2019ve learned<\/p>\n
Python won deservedly\u00a0\u2014 through the \u201cglue\u201d strategy [1], the head start of its scientific ecosystem, and network effects. Arguing with this is pointless; understanding it is mandatory.
\nPython in AI is the storefront, not the engine:\u00a036% of PyTorch\u2019s codebase is compiled languages [9], and every successful \u201cPython-stack accelerator\u201d works by removing Python from execution \u2014 from tf.data to torch.compile [22, 23, 26].
\nThe tax is real and measured:\u00a0~70\u00d7 on time and energy in language benchmarks [14, 17], up to half of an inference engine\u2019s time on CPU overhead [30], 30% of Google\u2019s ML-fleet compute time on input pipelines [26]. At the scale of billions of requests per day, percentages turn into gigawatt-hours [54, 55].
\nThe industry is already voting with its feet:\u00a0llama.cpp and GGUF [31, 32], Rust inside Hugging Face [33], MLX [43], ExecuTorch [34], Mojo [35] \u2014 wherever performance is mandatory, compiled languages are already at the helm.
\nSwift is a rare combination:\u00a0speed within a small factor of C (not a couple of orders of magnitude) [14], syntax honestly comparable to Python, ARC and compile-time race checking [44], production evidence [42], and the industry\u2019s only systemic integration with an on-device LLM [45]. The lessons of S4TF [39] and Julia [12] are taken on board: not a storming of the citadel, but new territories.
\nThe main horizon is one language from idea to device.\u00a0The two-language problem [11] is not a law of nature but a historical compromise. Compromises get revisited.<\/p>\n
The king is not dead,\u00a0and nobody is planning to depose him.\u00a0But a crown is not an argument in an engineering dispute.\u00a0Next time you choose a tool for a model that must live on a device,\u00a0inside an agentic loop,\u00a0or within an electricity budget\u00a0\u2014\u00a0just do the math.\u00a0The numbers in this article are at your service.<\/p>\n
Better yet \u2014 check for yourself. Nothing teaches like an experiment.<\/p>\n
References<\/p>\n
van Rossum G. \u201cGlue It All Together With Python.\u201d Position paper, OMG-DARPA-MCC Workshop, 1998.\u00a0https:\/\/www.python.org\/doc\/essays\/omg-darpa-mcc-position\/<\/a>
\nVirtanen P. et al. \u201cSciPy 1.0: fundamental algorithms for scientific computing in Python.\u201d Nature Methods 17, 261\u2013272, 2020.\u00a0https:\/\/arxiv.org\/abs\/1907.10121<\/a>
\nHarris C. R. et al. \u201cArray programming with NumPy.\u201d Nature 585, 357\u2013362, 2020.\u00a0https:\/\/arxiv.org\/abs\/2006.10256<\/a>
\nGitHub Octoverse 2024: \u201cAI leads Python to top language.\u201d\u00a0https:\/\/github.blog\/news-insights\/octoverse\/octoverse-2024\/<\/a>
\nGitHub Octoverse 2025: \u201cAI leads TypeScript to #1.\u201d\u00a0https:\/\/github.blog\/news-insights\/octoverse\/octoverse-a-new-developer-joins-github-every-second-as-ai-leads-typescript-to-1\/<\/a>
\nInfoWorld. \u201cPython is slipping in popularity \u2014 Tiobe,\u201d February 2026.\u00a0https:\/\/www.infoworld.com\/article\/4129615\/python-is-slipping-in-popularity-tiobe.html<\/a>
\nStack Overflow Developer Survey 2025: Technology.\u00a0https:\/\/survey.stackoverflow.co\/2025\/technology<\/a>
\nAssemblyAI. \u201cPyTorch vs TensorFlow in 2023\u201d (Papers with Code data, Q4 2022).\u00a0https:\/\/www.assemblyai.com\/blog\/pytorch-vs-tensorflow-in-2023<\/a>
\nGitHub API: language breakdown of pytorch\/pytorch (retrieved July 3, 2026).\u00a0https:\/\/api.github.com\/repos\/pytorch\/pytorch\/languages<\/a>
\nBezanson J., Karpinski S., Shah V., Edelman A. \u201cWhy We Created Julia,\u201d 2012.\u00a0https:\/\/julialang.org\/blog\/2012\/02\/why-we-created-julia\/<\/a>
\nBezanson J. et al. \u201cJulia: A Fresh Approach to Numerical Computing.\u201d SIAM Review 59(1), 65\u201398, 2017.\u00a0https:\/\/julialang.org\/assets\/research\/julia-fresh-approach-BEKS.pdf<\/a>
\nKidger P. \u201cJAX vs Julia (vs PyTorch).\u201d\u00a0https:\/\/kidger.site\/thoughts\/jax-vs-julia\/<\/a>
\nJAX documentation: \u201cAsynchronous dispatch.\u201d\u00a0https:\/\/docs.jax.dev\/en\/latest\/async_dispatch.html<\/a>
\nPereira R. et al. \u201cEnergy Efficiency across Programming Languages: How Do Energy, Time, and Memory Relate?\u201d SLE\u201917, 2017.\u00a0https:\/\/greenlab.di.uminho.pt\/wp-content\/uploads\/2017\/10\/sleFinal.pdf<\/a>
\nPereira R. et al. \u201cRanking programming languages by energy efficiency.\u201d Science of Computer Programming 205, 2021.\u00a0https:\/\/www.sciencedirect.com\/science\/article\/pii\/S0167642321000022<\/a>
\nvan Kempen N. et al. \u201cIt\u2019s Not Easy Being Green: On the Energy Efficiency of Programming Languages.\u201d ASE\u201925, 2024.\u00a0https:\/\/arxiv.org\/abs\/2410.05460<\/a>
\nThe Computer Language Benchmarks Game: n-body.\u00a0https:\/\/benchmarksgame-team.pages.debian.net\/benchmarksgame\/performance\/nbody.html<\/a>
\nThe Computer Language Benchmarks Game: spectral-norm.\u00a0https:\/\/benchmarksgame-team.pages.debian.net\/benchmarksgame\/performance\/spectralnorm.html<\/a>
\n\u201cWhat\u2019s New in Python 3.13\u201d (free-threaded CPython).\u00a0https:\/\/docs.python.org\/3\/whatsnew\/3.13.html<\/a>
\n\u201cWhat\u2019s New in Python 3.14\u201d (PEP 779: official support of free-threaded Python).\u00a0https:\/\/docs.python.org\/3\/whatsnew\/3.14.html<\/a>
\nJin K. \u201cCommunity Stewardship of Faster CPython.\u201d discuss.python.org, May 2025.\u00a0https:\/\/discuss.python.org\/t\/community-stewardship-of-faster-cpython\/92153<\/a>
\nPyTorch. \u201cGet Started: PyTorch 2.x\u201d (the PyTorch 2.0 \/ torch.compile announcement).\u00a0https:\/\/pytorch.org\/get-started\/pytorch-2.0\/<\/a>
\nAnsel J. et al. \u201cPyTorch 2: Faster Machine Learning Through Dynamic Python Bytecode Transformation and Graph Compilation.\u201d ASPLOS\u201924, 2024.\u00a0https:\/\/docs.pytorch.org\/assets\/pytorch2-2.pdf<\/a>
\nGray A. \u201cGetting Started with CUDA Graphs.\u201d NVIDIA Technical Blog, 2019.\u00a0https:\/\/developer.nvidia.com\/blog\/cuda-graphs\/<\/a>
\nHe H. \u201cMaking Deep Learning Go Brrrr From First Principles.\u201d\u00a0https:\/\/horace.io\/brrr_intro.html<\/a>
\nMurray D. et al. \u201ctf.data: A Machine Learning Data Processing Framework.\u201d PVLDB 14(12), 2945\u20132958, 2021.\u00a0https:\/\/vldb.org\/pvldb\/vol14\/p2945-klimovic.pdf<\/a>
\nLeclerc G. et al. \u201cFFCV: Accelerating Training by Removing Data Bottlenecks.\u201d CVPR 2023.\u00a0https:\/\/arxiv.org\/abs\/2306.12517<\/a>
\nKwon W. et al. \u201cEfficient Memory Management for Large Language Model Serving with PagedAttention.\u201d SOSP 2023.\u00a0https:\/\/arxiv.org\/abs\/2309.06180<\/a>
\nvLLM Blog. \u201cvLLM V1: A Major Upgrade to vLLM\u2019s Core Architecture,\u201d 2025.\u00a0https:\/\/blog.vllm.ai\/2025\/01\/27\/v1-alpha-release\/<\/a>
\nLMSYS Org. \u201cSGLang v0.4: Zero-Overhead Batch Scheduler,\u201d 2024.\u00a0https:\/\/lmsys.org\/blog\/2024-12-04-sglang-v0-4\/<\/a>
\nHugging Face Blog. \u201cGGML and llama.cpp join HF to ensure the long-term progress of Local AI,\u201d 2026.\u00a0https:\/\/huggingface.co\/blog\/ggml-joins-hf<\/a>
\nHugging Face Hub documentation: GGUF.\u00a0https:\/\/huggingface.co\/docs\/hub\/gguf<\/a>
\nhuggingface\/tokenizers (Rust).\u00a0https:\/\/github.com\/huggingface\/tokenizers<\/a>
\nPyTorch Blog. \u201cIntroducing ExecuTorch 1.0: Powering the next generation of edge AI,\u201d 2025.\u00a0https:\/\/pytorch.org\/blog\/introducing-executorch-1-0\/<\/a>
\n\u201cMojo (programming language)\u201d \u2014 Wikipedia (documents Modular\u2019s \u201cA journey to 68,000x speedup over Python\u201d series, 2023).\u00a0https:\/\/en.wikipedia.org\/wiki\/Mojo_(programming_language)<\/a>
\nModular Blog. \u201cModular 26.3: Mojo 1.0 Beta,\u201d May 2026.\u00a0https:\/\/www.modular.com\/blog\/modular-26-3-mojo-1-0-beta-max-video-gen-and-more<\/a>
\nHoward J. \u201cfast.ai \u2014 Embracing Swift for Deep Learning,\u201d 2019.\u00a0https:\/\/www.fast.ai\/posts\/2019-03-06-fastai-swift.html<\/a>
\nSaeta B. et al. \u201cSwift for TensorFlow: A portable, flexible platform for deep learning,\u201d 2021.\u00a0https:\/\/arxiv.org\/abs\/2102.13243<\/a>
\ntensorflow\/swift \u2014 the official archive of the Swift for TensorFlow project.\u00a0https:\/\/github.com\/tensorflow\/swift<\/a>
\nLarson B. \u201cBenchmarking Differentiable Swift.\u201d PassiveLogic, 2024.\u00a0https:\/\/medium.com\/passivelogic\/benchmarking-differentiable-swift-270da84f4fe4<\/a>
\nGlobeNewswire. \u201cPassiveLogic Advances Swift AI Compiler to Deliver Superior Energy Efficiency\u2026,\u201d 2024.\u00a0https:\/\/www.globenewswire.com\/news-release\/2024\/08\/20\/2933037\/0\/en\/PassiveLogic-Advances-Swift-AI-Compiler-to-Deliver-Superior-Energy-Efficiency-Over-Industry-Giants-TensorFlow-and-PyTorch.html<\/a>
\nSwift.org Blog. \u201cSwift at Apple: Migrating the Password Monitoring service from Java,\u201d 2025.\u00a0https:\/\/www.swift.org\/blog\/swift-at-apple-migrating-the-password-monitoring-service-from-java\/<\/a>
\nSwift.org Blog. \u201cOn-device ML research with MLX and Swift,\u201d 2024.\u00a0https:\/\/www.swift.org\/blog\/mlx-swift\/<\/a>
\nSwift.org Blog. \u201cAnnouncing Swift 6,\u201d 2024.\u00a0https:\/\/www.swift.org\/blog\/announcing-swift-6\/<\/a>
\nApple WWDC25, session 286: \u201cMeet the Foundation Models framework.\u201d\u00a0https:\/\/developer.apple.com\/videos\/play\/wwdc2025\/286\/<\/a>
\nApple ML Research. \u201cIntroducing Apple\u2019s On-Device and Server Foundation Models,\u201d 2024.\u00a0https:\/\/machinelearning.apple.com\/research\/introducing-apple-foundation-models<\/a>
\nHugging Face Blog. \u201cSwift Transformers Reaches 1.0,\u201d 2025.\u00a0https:\/\/huggingface.co\/blog\/swift-transformers<\/a>
\nIEA. \u201cEnergy and AI.\u201d World Energy Outlook Special Report, April 2025.\u00a0https:\/\/www.iea.org\/reports\/energy-and-ai\/executive-summary<\/a>
\nIEA. \u201cData centre electricity use surged in 2025\u2026,\u201d April 2026.\u00a0https:\/\/www.iea.org\/news\/data-centre-electricity-use-surged-in-2025-even-with-tightening-bottlenecks-driving-a-scramble-for-solutions<\/a>
\nBarr J. \u201cAmazon EC2 Update \u2014 Inf1 Instances with AWS Inferentia Chips\u2026\u201d AWS News Blog, 2019.\u00a0https:\/\/aws.amazon.com\/blogs\/aws\/amazon-ec2-update-inf1-instances-with-aws-inferentia-chips-for-high-performance-cost-effective-inferencing\/<\/a>
\nPatterson D. et al. \u201cThe Carbon Footprint of Machine Learning Training Will Plateau, Then Shrink.\u201d IEEE Computer 55(7), 2022.\u00a0https:\/\/arxiv.org\/abs\/2204.05149<\/a>
\nStrubell E., Ganesh A., McCallum A. \u201cEnergy and Policy Considerations for Deep Learning in NLP.\u201d ACL 2019.\u00a0https:\/\/arxiv.org\/abs\/1906.02243<\/a>
\nPatterson D. et al. \u201cCarbon Emissions and Large Neural Network Training,\u201d 2021.\u00a0https:\/\/arxiv.org\/abs\/2104.10350<\/a>
\nAltman S. \u201cThe Gentle Singularity,\u201d June 2025.\u00a0https:\/\/blog.samaltman.com\/the-gentle-singularity<\/a>
\nTechCrunch. \u201cChatGPT users send 2.5 billion prompts a day,\u201d July 2025.\u00a0https:\/\/techcrunch.com\/2025\/07\/21\/chatgpt-users-send-2-5-billion-prompts-a-day\/<\/a>
\nApple ML Research. \u201cIntroducing the Third Generation of Apple\u2019s Foundation Models,\u201d June 2026.\u00a0https:\/\/machinelearning.apple.com\/research\/introducing-third-generation-of-apple-foundation-models<\/a><\/p>\n","protected":false},"excerpt":{"rendered":"Disclaimer: This article reflects my own opinions. I have a vested interest in the topic: I maintain the…\n","protected":false},"author":2,"featured_media":690863,"comment_status":"","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[20],"tags":[554,733,4308,86,56,54,55],"class_list":["post-690862","post","type-post","status-publish","format-standard","has-post-thumbnail","category-artificial-intelligence","tag-ai","tag-artificial-intelligence","tag-artificialintelligence","tag-technology","tag-uk","tag-united-kingdom","tag-unitedkingdom"],"_links":{"self":[{"href":"https:\/\/www.newsbeep.com\/uk\/wp-json\/wp\/v2\/posts\/690862","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.newsbeep.com\/uk\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.newsbeep.com\/uk\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.newsbeep.com\/uk\/wp-json\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/www.newsbeep.com\/uk\/wp-json\/wp\/v2\/comments?post=690862"}],"version-history":[{"count":0,"href":"https:\/\/www.newsbeep.com\/uk\/wp-json\/wp\/v2\/posts\/690862\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.newsbeep.com\/uk\/wp-json\/wp\/v2\/media\/690863"}],"wp:attachment":[{"href":"https:\/\/www.newsbeep.com\/uk\/wp-json\/wp\/v2\/media?parent=690862"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.newsbeep.com\/uk\/wp-json\/wp\/v2\/categories?post=690862"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.newsbeep.com\/uk\/wp-json\/wp\/v2\/tags?post=690862"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}