And, in some ways, PyPy. I still think it is the sanest way to implement Python.
It makes me sad that I have to write C to make any meaningful changes to Python. Same goes for ruby. Rubinius was such a nice project.
Hacking on schemes and lisps made me realize how much more fun it is when the language is implemented in the language itself. It also makes sure you have the right abstractions for solving a bunch of real problems.
It is restricted in a way that you would restrict yourself to write high speed software in most languages, and I found it is not that restrictive compared to C that you would have to use if you were to write a fast Python library.
oh for sure, but I still feel like telling people pypy is written in python is misleading. it's written in something significantly like python, but it's not python.
The fact that it's written in python is often brought up in order to explain its name. But really, it's much less interesting than the fact that it has a tracing JIT. If it were called PyJIT I'd bet it would be clearer and more obvious that it's fast. And people would prob get less hung up on the distinction between python/rpython.
Oh hi! Thanks for posting. As I wrote this I wasn't sure if it was enough of a post. Let me know if you wanted to hear about anything else that seemed missing.
Preface: I am not a compiler engineer at all, so I'm just spitballing silliness here.
Avoidance of type feedback counters and such. Get LBBV to clean out the redundant type checks (Higgs proved this well, avoiding something like >90% of them) and produce a format, perhaps a high-level bytecode or just an HIR, that can be used as an input to start a method-level JIT compilation.
So, LBBV gives the quick and easy basic block compilation and cleans up the very easy stuff but leaves enough information so that a follow-up compiler can still use it as input.
Earnestly: why are you annoyed? I tried to make it clear that you don't have to make any changes. If you want, you can try ZJIT (which should not be anything other than a one character change), but you don't have to.
Because now YJIT is deprecated and at some point in a year or two I will have to have my team go through and switch everything from YJIT to ZJIT. So it's creating random tech debt busywork that will suck up dev resources that could better be used building features.
In isolation, having to switch from YJIT to ZJIT isn't that bad, but this same type of churn happens across so much of the frameworks and technologies that my company uses that in aggregate it becomes quite an annoyance.
I assume you upgrade your Ruby VM? You also upgrade to use YJIT? And you will upgrade to ZJIT?
Not only do you get them for free, you get performance improvement for free. And YJIT is still supported and not depreciated. Not only is Ruby on Rails dont have churn anywhere near the order of magnitude of JS world. It is perhaps one of the stablest and non-moving framework and languages, to the point it is moving slowly and boring compared to even modern PHP and Python.
I dont even work on YJIT or ZJIT but I find this entitlement on OSS, even when you are getting newer upgrade and improvement for free, for all the benefits it provides while having so little downside being called "random tech debt busywork" frankly very rude.
