In my niche corner of scientific computing it feels like Cython has largely been replaced by Numba and CFFI, or just Julia. Last I checked it still needed setup.py which is a bit of a deal breaker in 2025.
[build-system]
requires = ["setuptools", "cython"]
[tool.setuptools]
ext-modules = [
{name = "example", sources = ["example.pyx"]} # You can also specify all the usual options like language or include_dirs
]
That's true but I still don't see that so much because the core libraries are not as mature and often they're just thin wrappers around the C/C++/Fortran API without examples. Just as an example, I'd count this SUNDAILS library as like that:
https://docs.rs/sundials/0.3.2/sundials/
Nothing wrong with that as a starting point of course, but it's easier just to compile it as a dependency and look at the core documentation if you're familiar with C++; you'll need to be reading the C++ examples anyway to write Rust code with it.
What I mean is that (at least in my experience) people are not so commonly writing serious numeric applications in Rust as Python extensions because the numeric libraries on which you'd typically write in a compiled language are not as well developed and are in themselves often thin wrappers over C/C++ code at the moment. When you write an extension library you typically want all the 'slow' stuff to be done in a layer below the interpreted language for performance reasons.
So if you wanted to write a Python Physics library that included, say, time integration with an implicit solver like those SUNDIALS provides (and SUNDIALS is like the gold standard in this area), you have less well used options for the time integration part if you write the extension in Rust as if you do in C/C++. Or you're using the same library anyway.
SymPy has Solvers for ODEs and PDEs and other libraries do convex optimization. SymPy also has lambdify to compile from a relatively slow symbolic expression tree to faster 'vectorized' functions
>>> """Convert a SymPy expression into a function that allows for fast numeric evaluation""" [with e.g. the CPython math module, mpmath, NumPy, SciPy, CuPy, JAX, TensorFlow, PyTorch (*), SymPy, numexpr, but not yet cmath]
I’m perfectly familiar with SymPy and it’s great but it doesn’t have methods comparable in performance in stiff PDEs to CVODE, and it’s not parallelised either. CVODES offers sensitivity analysis, ARKODE offers multi rate integrators for systems where the ODE can be decomposed into slow and fast rates, etc. etc. - it’s a much more sophisticated and specialist library.
If you add Arrow RecordBatch or Table output to CVODE with arrow-cpp, e.g. Dask can zero-copy buffers to Python (pyarrow, pandas.DataFrame(dtype_backend=arrow), or narwhals) when it needs to gather / fan in at a computational barrier in a process-parallel workflow.
Is sklearn-deap useful with scikits.odes and sundials (and dask or not)?
Persons who need pyproject.toml functionality could consider contributing tests so that the free functionality might be considered adequate for their purposes.
I haven't kept track of numba in recent years. But there is a clear path to translate more and more scikit-learn to mojo, bypassing the python interpreter entirely. And then things become much more composable in a way that numba can't be.
We are heavily leaning on Julia, and to my mind Mojo is a major threat to the long term development of the Julia community. If people dissatisfied with Python+C(++)-Silos end up writing Mojo instead of Julia it will become even harder to grow the ecosystem and community.
That said, for now Julia has a number of big strengths for scientific work that don't seem to be in the focus of the Mojo devs...
Very interesting. I'm currently trading off whether to use Mojo or C++/pybind to accelerate simulations that combine matrix operations with fine-grained scalar calculations. I only recently learned that pybind + cppimport offers the integrated compile-on-import experience available in Mojo.
Mojo makes SIMD and GPU programming more ergonomic than what you would obtain from C++, I imagine this should factor into your decision process. The language is just less mature overall.
