Ok, the title of this post may seem provocative, kinda clickbaity but here is the thing, 19 years ago (2007) Jeff Atwood wrote his famous blog post where he declared that "Any application that can be written in JavaScript, will eventually be written in JavaScript.", coined the now-famous Atwood's Law. It was a a blog post based on an even older one from Tim Berners-Lee on the Principles of Design and his axiom/rule of least power.
It was a prophetic observation about accessibility. JavaScript wasn't the fastest or the most elegant language, but it was the most available. It ran everywhere the web ran. Accessibility won. We saw JavaScript everywhere, on the web, on the server with Node, on IoT devices, on Desktop with Electon, on Mobile with React Native, on Enterprise automation with Google Apps Script, even on Machine Learning applications with Tensorflow.js... even on places where the core is not written in JS like blockchain and NoSQL DBs, Javascript became the defacto choice as interface.
For years, we defaulted to interpreted languages for greenfield projects because developer time was expensive, and compute was cheap. We optimized for "writing speed," not "running speed.". In 2026, that math has broken.
Also for years we had numerous debates about which language is "the best" (a pointless debate IMO), in 2026 devs write 90% of the code using natural language, through an LLM.
Today I believe we are seeing the emergence of a new corollary, driven by two entirely different forces, Economy & AI. So here I am to declare a new law: Everything that can be written in a system language, eventually will be written in a system language by an LLM.
I am not here to declare the death of Java, Ruby, JS etc etc, there are numerous articles the last 2 decades declaring their death and these languages are still here. However the accessibility of languages like Rust/Go has increased drammatically.
There are studies with benchmarks that saw for example that Python can be over 70x less energy-efficient than Rust. In a serverless world (AWS Lambda, Google Cloud Run), where you pay for every millisecond of execution and every gigabyte of memory, that inefficiency is a direct tax on your margins. For a new startup or a greenfield microservice, choosing a memory-hungry interpreted language is a decision to voluntarily pay a "runtime tax" forever.You can pack 10x the throughput onto the same hardware using Go or Rust compared to typical Python/Ruby app.
If you are building from scratch today, why would you choose a foundation that costs 10x more to run?
The counter-argument has always been the learning curve.
"Rust is too hard," they said. "Go is too verbose," they complained. "I can hire a Python/Java/JS engineer in a few days, a Rust senior takes six months to find." This was true. The borrow checker was a formidable gatekeeper, but this is where LLMs change the game. The "barrier to entry" argument is evaporating because AI agents are exceptionally good at being systems programmers, arguably better than they are at being dynamic language programmers. Why? Constraint is context.
When an LLM writes Python, it can hallucinate a variable or a method, and the code will look fine until it crashes at runtime. When an LLM writes Rust, the compiler acts as a ruthless adversarial network. It forces the model to be correct before the code ever runs.
We will see (or are seeing?) a trend where "Vibe Coding" is actually safer in strict languages.
The "difficulty" of writing Rust was mostly about managing memory and fighting the compiler. Now, the AI fights the compiler for you. The cognitive load of syntax is offloaded to the agent, leaving the human to focus on the architecture and the intent.
I am not suggesting we pause everything to rewrite our apps to Rust/Go. The "Rewrite Trap" is real, and destroying working software to chase a trend is usually a bad business decision. However, for greenfield projects, the calculus has shifted.
We are entering an era where the Brain of the application (the orchestration of models, the decision-making) might remain in Python due to its rich AI ecosystem, but the Muscle, the API servers, the data ingestion pipelines, the sidecars, will inevitably move to Go and Rust. The friction of adopting these languages has collapsed, while the cost of not adopting them (in AWS bills and carbon footprint) is rising.
It is simple math.