Jump to content

A “Python” That Compiles: The Rust Language Claiming 220× Speed

From JOHNWICK

A bold claim landed in the Rust world: a Python-like language that compiles, boasting eye-popping speedups.
That headline grabs attention. It also misses what you and I really need: something we can ship right now that makes real Python feel fast. This piece gives you that path.
Short, direct, human.
No fluff.
Just a way to turn slow loops into code that feels instant while keeping your Python.


The claim vs the work you must ship A “220×” number looks dramatic. It usually comes from micro-cases where interpreter overhead dominates. Great for a post. Harder in a real codebase with logging, IO, latency budgets, and guardrails. Here is the reality that helps your users today:

  • Keep most of your code in Python.
  • Move a hot, self-contained loop to Rust.
  • Call it from Python like a normal function.
  • Enjoy native speed across threads without fighting the GIL.

If you love experiments, watch the new Python-like language built around Rust and an LLVM pipeline. It is exciting and early. I celebrate the ambition. For production work, the practical upgrade lives at the seam between Python and Rust.


Three roads to “Python that feels compiled” 1) Rust inside Python (PyO3) Python (CPython) 

    |
    |  call
    v

+------------+ LLVM + threads (GIL stays out here) | Rust fn |-------------------------------------+ +------------+ | 

    ^                                             |
    +-------------------- returns ----------------+

You keep your codebase. You replace only the loop that hurts. This is the path teams use when they need a result this week. 2) Python compiled to native (Codon-style compilers) your_script.py --> compiler --> native binary 

     (supported subset)        (LLVM)   (no CPython runtime)

When your code fits a supported subset, you skip the interpreter and land near C/C++-class performance. 3) Python-like language that compiles (Otter-style idea) Python-like code --> new compiler --> LLVM --> native binary 

                                    (Rust FFI, experimental)

The idea is fresh and fun. Treat it as an investment, not a deadline fixer.


The upgrade you can publish tonight One focused Rust module, called from Python, can lift your core path by orders of magnitude. Below is a compact, production-ready example. It parallelizes across CPU cores and stays ergonomic to call from Python. Rust (src/lib.rs) use pyo3::prelude::*; use pyo3::exceptions::PyValueError; use rayon::prelude::*;

  1. [pyfunction]

fn dot(a: Vec<f64>, b: Vec<f64>) -> PyResult<f64> { 

   if a.len() != b.len() {
       return Err(PyValueError::new_err("lengths differ"));
   }
   Ok(a.par_iter().zip(b.par_iter())
        .map(|(x, y)| x * y)
        .sum::<f64>())

}

  1. [pyfunction]

fn sum_squares(xs: Vec<f64>) -> PyResult<f64> { 

   Ok(xs.par_iter().map(|v| v * v).sum())

}

  1. [pymodule]

fn turbo(_py: Python, m: &PyModule) -> PyResult<()> { 

   m.add_function(wrap_pyfunction!(dot, m)?)?;
   m.add_function(wrap_pyfunction!(sum_squares, m)?)?;
   Ok(())

} How to think about it:

  • The boundary is clean: lists in, number out.
  • The loop moves to native code and uses threads safely.
  • Python still orchestrates everything around it.

Build with a standard Python-Rust bridge tool, then import turbo in Python and call turbo.dot(a, b) or turbo.sum_squares(xs) exactly like any built-in routine. You will feel the difference.


Want comments and saves? Invite proof from readers People trust code they can run. Give them something simple they can paste, then ask for results in the comments. Keep the voice friendly. Baseline in Python: def py_sum_squares(xs): 

   s = 0.0
   for v in xs:
       s += v * v
   return s

Now call your Rust function turbo.sum_squares(xs) on the same data.
Ask readers to share their CPU, Python version, and both timings.
Offer to help the first wave of replies by porting one of their loops.
That conversation builds momentum and follows.


A clear comparison in plain words PyO3 path
Best when you can isolate a hot loop. Minimal risk. Big wins on compute-heavy code. You keep your Python, gain native speed in the parts that matter. Compiler path
Great when your code fits the supported subset and you want a single fast binary. You avoid interpreter costs entirely. Experimental path
Promising for the future. Fun to explore. Not where you hang a hard deadline today.


The quiet reason this works Interpreters are excellent at flexibility. They are not designed to chew through branch-heavy math or large maps and reductions at full CPU width. The moment you push that work into a compiled function, you stop paying per-operation overhead and start paying for actual math. Add safe parallelism and you harvest dormant cores that your original loop could not use freely. The best part is psychological. When a feature that used to feel heavy becomes smooth, users lean in. They click. They finish flows. They come back. That feeling is not vanity. It is craft.


A small story from the trenches I once had a scoring path that everyone avoided. It was correct and slow, which is the worst mix. I moved one routine into Rust behind a slim Python call. Same inputs. Same outputs. Same tests. Different feeling. Reviewers stopped skipping it. A teammate who always complained about waiting stopped bringing it up. That is the signal I trust: when complaints vanish without a meeting. You can get that win in your codebase. Not after a rewrite. Right now.


When not to use this approach If your app is IO-bound, network-bound, or spends most of its time waiting on remote services, a compiled loop will not rescue you. Fix batching. Fix indexes. Fix protocol chatter. This article is about CPU-bound pain: math, parsing, transforms, compression, cryptographic work, and heavy iteration over large in-memory data.


One more sketch for your mental model Where the time goes when Python loops vs compiled loops Python loop: 

 [interpret][bounds][dispatch][type checks][do math][repeat...] x N

Compiled loop: 

 [do math][do math][do math][SIMD][threads][repeat faster] x N

In the second case, you stop paying the tax at every step. The work turns into raw CPU progress.


Closing words to the reader If you run the snippet, drop your before-and-after in the comments with your CPU and Python version. If your slowest loop does not fit this approach, leave a brief description. I will try to help you rethink it in the thread. Speed is not a trophy. It is a kindness to the person on the other side of the screen.

Retrieved from "https://johnwick.cc/index.php?title=A_“Python”_That_Compiles:_The_Rust_Language_Claiming_220×_Speed&oldid=106"