ruby-implementations VS hpy

Fascinating, does the project aspire to become compatible with MRI Ruby? Also how many active Ruby implementations do we have so far?

Edit: Found this, https://github.com/codicoscepticos/ruby-implementations?tab=...

I see the point to make a parallel with HipHop, but here YJIT is directly integrated in CRuby, the main implementation of the language, and it’s just a matter of command line flag whether you enable or disable it — at least from what I remember that I red.

From what I remember, HipHop was distributed in a different toolchain than the vanilla PHP interpreter. Ruby also have other interpreters available by the way: https://github.com/codicoscepticos/ruby-implementations

> numpy (and swig) predates Unladen Swallow

Sure, but that’s not what I said. Numpy is surprisingly old, but (at least according to my own impressions at the time) in 2010 supporting it was in no way table stakes for an “alternative” implementation of Python. Hell, Jython was still occasionally taken seriously then, and Microsoft still pretended they cared about IronPython.

> I would suggest the C API is just as much a part of Python as the standard library

As things stand, yes, no question.

The problem is, it was never designed that way. In particular, it cannot (or at least not designed to) support any other memory management strategy but CPython’s, thus efforts like HPy[1]. For example, while the language docs admonish you not to depend on __del__ running at any particular moment, if we consider the Python/C API a part of the language, then the language has to behave as though it uses eager reference counting and occasionally runs a cycle collector. And that’s the easy case—think about how deeply the GIL is rooted there.

That is good design for something that’s part of the language, as it effectively is. It was never intended to be and never received commensurate amounts of care. It just turned out that way—and ain’t that a sad thing to admit.

[1] http://hpyproject.org/

There is a merge request up to add autogen rust bindings to hpy

https://github.com/hpyproject/hpy/pull/457

Are you referencing https://github.com/hpyproject/hpy?

I do hope it takes off.

The HPy project [0] seems like a promising way out of this.

[0] https://hpyproject.org/

socketify.py breaks the record for Python no other Python WebFramework/Server as able to reach 6.2 mi requests per second before in TechEmPower Benchmarks, this puts Python at the same level of performance that Golang, Rust and C++ for web development, in fact Golang got 5.2 mi req/s in this same round. Almost every server or web framework tries to use JIT to boost the performance, but only socketify.py deliveries this level of performance, and even without JIT socketify.py is twice as fast any other web framework/server in active development, and still can be much more optimized using HPy (https://hpyproject.org/). Python will get even faster and faster in future!

I think Propose a better messaging for Python is the option and a lot of languages will learn it from Rust, because rust erros are the best described errors I see in my life lol. Cargo is amazing and I think we will need a better poetry/pip for sure, HPy project will modernize extensions and packages 📦 too https://hpyproject.org/

It also show that PyPy3 will not magically boost your performance, you need to integrate in a manner that PyPy3 can optimize and delivery CPU performance, with a more complex example maybe it can help more. But why socketify is so much faster using PyPy3? The answer is CFFI, socketify did not use Cython for integration and cannot delivery the full performance on Python3, this will be solved with HPy.

HPy integration to better support CPython, PyPy and GraalPython