The article lists alternatives but doesn’t mention Cython. That’s a miss. I’ve done both. If numba works, it’s great. I found it a bear to install. Cython is more work, did what I needed - allowed me to incrementally type Python to get C code performance for general numeric code where memory allocations mattered (large arrays).
It's easy to miss, but the second bullet point about "coding in a low-level language directly" links to another of the author's articles entitled Cython, Rust, and more: choosing a language for Python extensions [1] which discusses the pros and cons of using Cython.
I've done a pretty extensive amount of development in Cython. I agree, it's very nice to be able to incrementally type Python code but I've found that using the language to its full potential requires a good understanding of C programming, especially for debugging.
Fwiw: Cython does NOT offer many of the killer features that Numba includes, such as parallel for loops, automatic vectorization, automatic GPU support and GPU parallelization, and taking advantage of MKL and other Intel goodies. To do that with Cython will be much much harder than in numba and at a significantly lower level of abstraction.
I don't think that they even compete or solve the same use case tbh. Not sure why they're being constantly compared to each other.
That's not quite true, cython supports parallel for loops either by directly calling openmp or via cython.parallel.prange etc. (which wraps openmp AFAIK) you can also get simd speed ups via directly calling simd intrinsics or compiling with simd support and relying on the compiler (which is admittedly is not as sophisticated as numbas simd support). For GPU support I would likely go and use cupy or arrayfire.
Cython does have a plugin for gdb https://cython.readthedocs.io/en/latest/src/userguide/debugg... however I have not used it. Generally I don't like writing cython code directly however and rather start with working python code and add types etc., cython -a really helps in those situations.
