hpy VS janet

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

Absolutely everything in CPython is a PyObject, and that can’t be changed without breaking the C API. A PyObject contains (among other things) a type pointer, a reference count, and a data field; none of these things can be changed without (again) breaking the C API.

There have definitely been attempts to modernize; the HPy project (https://hpyproject.org/), for instance, moves towards a handle-oriented API that keeps implementation details private and thus enables certain optimizations.

Seems like a perfect use-case for Janet. (https://janet-lang.org/) A fast minimal VM like Lua, but even more extensible than Lua by being a "Lisp" with macro and C extension capabilities. Not a true Lisp, it's very pragmatic and performance-oriented. But it keeps the good stuff.

You might be looking for: https://janet-lang.org/

It comes with a build tool `jpm` which installs dependencies globally by default, but you can have it be installed in your project folder as well.

I like Clojure, but I never had any good opportunities to use it other than for a few small hobby projects. It is unfortunate that it is so huge with tons of dependencies and no simpler native implementation. I started looking at various LISPs and Schemes to find something lighter to use instead and ended up settling for Janet that I think is Clojure-like enough to be comfortable to use, but in a small native binary with no dependencies and can be embedded in other native programs. I am sure for big, real, projects that Clojure makes more sense, but for my hobby projects and scripts I do not think I will install it again. I am still happy for the things I learned from learning Clojure. It was a real eye-opener for an old OO-programmer.

https://janet-lang.org/

One might also check out Janet for quick scripting tasks.

https://janet-lang.org

Thanks!

I thought about another multiplatform, homoiconic, highly compact language: https://janet-lang.org/ (takes 803 kb on my machine).

It has no types though.

Racket is great, and if you like it you might find Rash interesting:

https://rash-lang.org/

Janet and Gerbil Scheme are also worth a look:

https://janet-lang.org/

https://cons.io/

Point here is that, for instance Janet language does not have cons / pair type but tuple (and so is lispoid, not lisp), but clearly this is sufficient for macros & hence seamless language construction: all you need is to be a lispoid although being a lisp gives another useful feature.