CPython? Codon tries to follow CPython’s syntax, semantics and APIs as closely as possible, aside from a few cases where Codon differs from CPython for performance reasons (one example being Codon’s 64-bit int vs. CPython’s arbitrary- width int ). Performance-wise, speedups over CPython are usually on the order of 10-100x.

Numba? While Codon does offer a JIT decorator similar to Numba’s, Codon is in general an ahead-of-time compiler that compiles end-to-end programs to native code. It also supports compilation of a much broader set of Python constructs and libraries.

PyPy? PyPy strives to effectively be a drop-in replacement for CPython, whereas Codon differs in a few places in order to eliminate any dynamic runtime or virtual machine, and thereby attain much better performance.

Cython? Like Cython, Codon has a Python-extension build mode that compiles to Python extension modules, allowing Codon-compiled code to be imported and called from plain Python.

C++? Codon often generates the same code as an equivalent C or C++ program. Codon can sometimes generate better code than C/C++ compilers for a variety of reasons, such as better container implementations, the fact that Codon does not use object files and inlines all library code, or Codon-specific compiler optimizations that are not performed with C or C++.

Julia? Codon’s compilation process is actually much closer to C++ than to Julia. Julia is a dynamically-typed language that performs type inference as an optimization, whereas Codon type checks the entire program ahead of time. Codon also tries to circumvent the learning curve of a new language by adopting Python’s syntax and semantics.

Mojo? Mojo strives to add low-level programming support/features to the Python language, while also supporting the rest of Python by relying on CPython. By contrast, Codon aims to make Python itself more performant by using new type checking and compilation techniques, without trying to be a superset or drop-in replacement. Codon tries to minimize new syntax and language features with respect to Python.

Do you guys have any experience?

The documentation so far sounds like the sanest approach to making Python statically typed with some support for dynamic dispatch, which is what I’m most curious about. I’m not expecting the usual level of seamless dynamic dispatch from a statically typed implementation, but a little bit of duck-typing in an optimized function goes a long way. An important point is that Codon doesn’t compile NumPy yet , so it ironically isn’t as effective for a lot of numerical Python code. I suppose the math module would cover some of it, but unfortunately I’m on a Windows machine so I’ll be waiting a little to try its JIT:

Codon is yet another language pretending to be Python for attention, but the similarity is really just skin deep. The language does not have semantics which are at all compatible with Python semantics. You can’t even have a heterogeneous list, the strings are ASCII only byte arrays, functions must have only one possible return type, etc. etc.

The main reason to use Python is its ecosystem, but since this language is so incompatible with regular Python semantics, it can’t run must existing Python packages, meaning that the ecosystem needs to be rebuilt from scratch (or depend on their equivalent of PythonCall.jl).

If it can’t use Python’s ecosystem, it needs to be evaluated on its own merits as a standalone language, and from that perspective, it seems fine other than ASCII-only strings, but there’s nothing particularly interesting or exciting about it to me.

It’s just a bog-standard AOT compiled, statically typed language that happens to mostly look like Python.

I think it can be a real contender, but some users might be put off by the proprietary licence:

Business Source License 1.1
Change Date: 2028-03-01

Change License: Apache License, Version 2.0

It least the BSL reverts to open source, there to Apache I can live with.

[Note we have a Chinese proprietary Julia compiler available, not everything in Julia ecosystem is fully open source either. I can understand why pople, well companies go with proprietary, but if so, at least then BSL might be better, I would want to for Julia’s compiler, or even better open source right away… Those needing speed are probably ok to pay for faster Python, or smaller Julia binaries.]

As explained (in Julia’s FAQ if I recall), Python can’t be made fast, in general , since it has wrong semantics. But Codon changes to those correct (for speed) semantics, such as machine integers. So it and Mojo are real contenders as better Python, and better for programming than e.g. C++.

I’m not saying Julia isn’t even better, because of e.g. multiple dispatch, but it will be harder to compete with “Python” when it’s no longer considered slow.

Mason:

The main reason to use Python is its ecosystem, but since this language is so incompatible with regular Python semantics, it can’t run must existing Python packages, meaning that the ecosystem needs to be rebuilt from scratch (or depend on their equivalent of PythonCall.jl ).

If it can’t use Python’s ecosystem

It can use Python ecosystem?! I.e. you can call to Python (presumably), as with Mojo, and as with Julia with PythonCall.jl. Mojo has very different semantics from Python, but share’s the syntax (only a subset of), or adds to it. Codon shares Python’s syntax fully I think, and some of the semantics, like 1-based indexing… You say a lot of code can’t be copied and run as is, but a lot can still work that way? But none of that matters if you can just easily can CPython, as I understand you can.

[It may be competing more with Cython than Python itself, and well with C; for making extension modules for Python. And then “bog-standard AOT compiled, statically typed language is very much ok.” and often what people prefer. This has historically been a downside of Julia, AOT… but no longer, at least with a proprietary compiler, and upcoming juliac.]

Benny:

An important point is that Codon doesn’t compile NumPy yet , so it ironically isn’t as effective for a lot of numerical Python code.

Does it need to compile NumPy?!

@python

Codon programs can contain functions that will be executed by Python via pydef :

@python
def multiply(a: int, b: int) -> int:
    return a * b
print(multiply(3, 4))  # 12
This makes calling Python modules like NumPy very easy:
@python
def myrange(n: int) -> List[int]:
    from numpy import arange
    return list(arange(n))
print(myrange(5))  # [0, 1, 2, 3, 4]
              
Codon is an evolution of Seq, which was a domain specific language for bioinformatics. Since I do high performance bioinfo as a job, I have looked a bit at Codon (or more accurately, Seq) before.
I think it’s utterly pointless, and it’s a solution to the wrong problem. If you want a fast static language, you already have C, C++ and Rust. The reason scientists use Python is not because they don’t like the syntax of these languages - it’s because
They want to use Python because everyone else uses Python and they want to use existing libraries. But Codon can’t speed up existing Python packages. It can run them, sure, but so can e.g. Rust’s PyO3, or PyCall.jl (or the shell).
They want an interactive (dynamic) language because they do data science, or want fast iteration and prototyping, and staticness gets in the way of that. And Codon is not interactive.
I think the idea of Codon is that what holds bioinformaticians back from using static languages is that the syntax is too unfamiliar, so what the world needs is a new static language with syntax as close to Python as possible. But that’s just a complete misunderstanding of people’s motivation.
 Mason:
You can’t even have a heterogeneous list…functions must have only one possible return type
Apparently they’re working on that with union types and “dynamic inheritance” allowing collections of subtypes so far.
 Mason:
If it can’t use Python’s ecosystem
But Python is, and Codon features a Python package for a JIT decorator with builtin interop. That won’t be too different from Numba, only it supports AOT compilation on top of it. It won’t be the fast dynamic language, but I wouldn’t dismiss the utility of a fast static Pythonish language with builtin Python interop to Python users who don’t have the time to learn another language and its interop libraries.
 Palli:
Does it need to compile NumPy?!
No, it can use Python libraries wrapping fast compiled code, just not recompile them. Thing is, NumPy has many numerical functions that Python’s standard library does not have, and a big draw of Numba is being able to JIT compile said functions in caller functions that can’t just do NumPy’s “vectorized” array code. The issue I linked demonstrates that Codon can’t do that yet and is planning to.