When asked how Chris managed to overcome the internal opposition at Apple to releasing Swift as a new programming language, Chris responded:
I don’t think there was any magic, is was more about being persistent, about being rationale, about being defensive, about hearing them, listening, and reacting, about writing docs so that it wasn’t just hallway conversations – like OK, you have this concern – let me actually write it up so that we can scale the conversation.
Chris is currently working on Mojo – a CPU+GPU programming environment that may be the successor to LLVM.
This is really interesting in that it seems an environment that can provide a unified environment to program CPUs, GPUs, DSPs, MCUs, FPGAs, etc. is the future. Getting all these things to work together is a challenge.
Yes I concur this is next front to tackle as heterogenous compute becomes norm I have given a talk on future of computing in recently concluded yocto summit where I covered this topic in small details
Lattner positions Mojo as a systems language for when “code needs to go fast,” in the same performance space as C, Zig, CUDA, and Rust, despite looking like Python syntactically.
Mojo is not “Python++” but a language whose long‑term trajectory is to feel like “Python 4” and eventually a superset of Python 3, while currently focusing on performance and tight Python interop.
Recent Mojo developments include: working collections (lists, dicts, comprehensions), much more powerful generics/traits, pip packaging so you can pip install Mojo modules, and a large open-sourced codebase (~600k LOC), including what he claims is the largest portable GPU kernel library.
Extending Python with Mojo
Lattner describes a common pattern: teams start in Python for productivity but hit performance bottlenecks (loops, concurrency, interpreter overhead).
Traditional escape hatches (rewrite hot paths in C++/Rust) create “two‑world” systems with different languages, build tools, and hiring needs.
Mojo is designed to be “the best way to extend Python”: you declare functions in .mojo files and call them directly from Python with no manual bindings; the integration works with pip packaging and lets you incrementally move slow sections into Mojo, then optimize (SIMD, threads, GPU) while keeping a unified codebase and similar syntax.
GPU programming model and heterogeneous compilation
Lattner’s guiding principle is to “work backwards from the speed of light of the silicon,” meaning the language should expose full hardware capabilities (tensor cores, SRAM hierarchies, double buffering) rather than lowest‑common‑denominator abstractions like WebGPU or generic WASM.
He criticizes systems that can technically run code on GPUs but don’t expose tensor cores, resulting in large performance losses relative to what the hardware can do.
Mojo supports “split compilation”: the same Mojo function can be compiled for CPU and GPU, allowing shared logic (e.g., math, data layouts) while keeping GPU‑only constraints explicit (no DB lookups from GPU, explicit kernel launches, explicit data movement).
He emphasizes control and predictability over “magic”: GPU kernels are treated like explicit async RPCs to another computer across PCIe, making data transfer costs and kernel boundaries visible rather than hidden behind opaque frameworks.
Under the hood, Mojo uses a Java‑like idea: parse once into a target‑independent internal representation, then specialize that representation for multiple architectures (CPU, NVIDIA PTX, AMD GPU, etc.) via “code slicing,” compiling the transitive closure of all functions reachable from a submitted compute block for each device.
Consistent numerics and low-level library design
Mojo’s standard library defines core numerics directly in Mojo (e.g., sin via a Taylor series) instead of delegating to libm or vendor‑provided GPU math; this yields bit‑identical results across CPU and GPU for common precisions like float32, and generalizes across float8/float64 and SIMD widths.
For performance‑critical operations (like exp on AMD), Mojo can use conditional compilation (#ifdef‑like constructs) to select a fast vendor instruction on specific hardware and fall back to the generic implementation elsewhere, trading exact portability for performance where desired.
Pointers and fundamental types are also defined in the library, not baked into the language, which allows Mojo to model heterogeneous pointer sizes and multiple GPU address spaces (e.g., 64‑bit global vs 32‑bit local SRAM) while still sharing generic pointer logic across CPU and GPU.
Mojo vs Rust and C++ (performance and ergonomics)
Lattner claims Mojo can be faster than Rust in specific ways, but stresses this is not a “10x faster” marketing angle; they’re in a similar performance class on CPUs, with Mojo gaining advantages from language design and how it uses LLVM.
Examples he gives:
Mojo does not use RAII‑style guaranteed end‑of‑scope destructors, enabling tail calls/tail recursion to actually work and allowing large allocations (e.g., big tensors) to be freed earlier rather than tied to scope exit.
Mojo’s ownership and argument‑passing model avoids certain redundant memcpy patterns that Rust generates and then must rely on LLVM to optimize away.
He argues Rust cannot unlock 10,000x speedups by seamlessly moving the same code onto GPUs with tight Python interop, whereas Mojo is explicitly designed to make that pipeline (Python → Mojo CPU → Mojo GPU) smooth.
On C++, he’s blunt: current GPU ecosystems are fragmented (CUDA, ROCm, Intel toolchains), C++‑centric, heavy‑weight in dependencies (gigabytes of CUDA), and difficult enough that they “gatekeep” GPU programming; Mojo’s goal is to make GPU programming accessible and Python‑native while remaining performant and portable.
Broader ambitions and references
Lattner’s ambition is that many workloads which could benefit from GPU acceleration but currently don’t (due to friction: C++, vendor lock‑in, tool complexity) will become practical with Mojo’s model and Python-centric tooling.
He points listeners to his multi‑part blog series “Democratizing AI Compute” for a deeper history and critique of OpenCL, CUDA, and why the ecosystem consolidated around NVIDIA rather than more portable C+±based models.
Feldman and Lattner briefly note that Mojo’s internal “VM” style infrastructure is tightly coupled to Mojo and moves quickly; there’s no current plan to expose it as a general target like JVM/WASM, though something like a foundation or standardization might be imaginable many years out.
