That's an interesting comparison, because under the hood Cython and LuaJIT FFI could hardly be more different.
Cython is an optimizing Python (+ extensions) -> C compiler.
LuaJIT FFI is a library for Lua. It doesn't change the language at all (there are none of Cython's optional annotations), there is no build-time tool or need to run a C compiler.
But I can see how they could serve some of the same use cases.
"LuaJIT FFI is a library for Lua. It doesn't change the language at all ... "
This is literally true, of course, but in my ~5 yrs using it now I can say that writing LuaJIT+FFI-data-type code is, for me, both aesthetically and mechanically different from writing plain Lua code. The post captures it quite well:
This is basically the inverse of the old promise that languages like Python came
with: that you would write your whole application in Python, optimise the “hot
spots” with C, and voila! C speed, Python convenience, and money in the bank.
This was always much nicer in theory than practice. In practice, your data
structures have a huge influence on both the efficiency of your code, and how
annoying it is to write.
I often write my LuaJIT programs from the ground up designed around C data types and C-style memory allocation discipline. Bu I can always ditch that in areas where I know I don't care (e.g., configuration loading etc where 10 lines of C become a 1-liner in Lua).
In both cases a tool is being adapted for something it wasn't intended for: to write C-style code—specifically, code that works with memory the way C does—in a high-level scripting language.
This way of combining high and low levels within the same program seems qualitatively unlike, say, C++, traditional FFIs, and other answers to this problem. It's fascinating to see it emerge from more than one existing technology.
I guess I'm not sure which tool you meant was adapted; Cython (and Pyrex) certainly adapt Python to work more directly with memory, but I would say the style of code in the article is an intended use case of them.
(I also might have undersold the connection between the two, Cython is arguably just a friendly fork (I guess mostly they wanted to move faster))
I just meant that the OP is adapting Python (via Cython) similarly to how FFI-driven LuaJIT adapts Lua. The resulting programming style is different enough from classic Python or Lua that it approaches being a different language—something like an embedded C DSL.
