[ahomescu1]

I used RPython on my own interpreter project a few years ago (stopped working on it around 2013). It's a very interesting approach to writing interpreters/JIT compilers, and produces very fast code, but developing RPython code was very painful for a few reasons (back then, maybe they got fixed in the mean time):

1) Huge compilation times, and compilation is non-incremental. Making even a small change to the source code causes it to be fully re-compiled, which on our project took 15-20 minutes (I can only imagine how painful this is on PyPy, which took me around 2 hours to build the time I tried it). I think the root cause of this is the static analysis and type inference, which needs to run again on the entire source code, and proved to be really slow on a huge code base. This was painful for development, so much time wasted on waiting on the compiler.

2) My experience with error messages was not as positive as the OP's. Sometimes, I'd make a type error in the code and get a cryptic error message, and have to guess by myself what caused it. Perhaps things have improved since then (I see some new details in the errors in the article that weren't there when I used RPython).

[hyperpape]

I worked on it in 2015, and it seems like 30 seconds is the minimum compilation time for something trivial. That, combined with the error messages, made me give up after just a few days.

I would have much preferred type inference with robust error messages, or frankly, even Java style verbosity to what I got out of RPython. It's a shame, because it's obviously a very impressive system.

[andrewchambers]

The best way to work with it is to write tests which can run in interpreted mode.

[ahomescu1]

If you mean run RPython code as regular Python code, that doesn't always catch typing problems. For example, returning a None where an int is expected works fine in Python, not so in RPython.