At some point if it's a heavy process that has to run often, I would probably have rewritten it in Rust or something else, but in this case that script only needed to run a few times, and it needed to be correct, hence the heavy tests before running it for real
I think of PyPy more as making the dev feedback loop faster, rather than something I'd run in prod
"Ask HN: Is anyone using PyPy for real work?" (2023, 181 comments) can give you an idea: https://news.ycombinator.com/item?id=36940871. You notice a pattern in the comments. People use PyPy for the unglamorous task of speeding up some existing Python code instead of rewriting it. It isn't surprising they don't blog much about it.
> and why don't more people use it?
As other comments have already said, the incompatible binary extensions.
For some cases, e.g. large scale string processing, it may bring substantial benefits. For e.g. numerical stuff with numpy usually not, and for that there are a lot faster options (e.g. numba).
In the end Python is really slow, and even with PyPy it's usually slow to really slow. For other than numerical stuff it's better to usually go with e.g. Node.
If you have a long running process with a lot of pure python code, you can get a lot of perf boost.
Be aware memory consumptuon will go up significantly.
I’ve also heard that python is bad because it doesn’t support static typing, but it does. Most people only know about a tiny fraction of all the options out there.
it's surprisingly convenient to do
but that isn't the design path python choose (in general, PyPy did choose that path)
The other thing I’ll say for pypy is that by demonstrating that a Python interpreter written in Python can be faster than Python, it’s pushed CPython to improve performance as well. Not that CPython developers wouldn’t pursue performance gains on their own, but pypy offers a specific target, and we’ve all benefited from the comparison.