it seems like the <i>raison d'être</i> is performance rather than static correctness checking; i wonder how it compares to luajit? often my crude tests find luajit performance comparable to c compiled by gcc with optimization, but sometimes about half as fast, and presumably on a large enough program with a flat enough profile its performance would converge to slightly worse than simple bytecode interpretation. i'm never sure how much i can rely on luajit's performance, and static compilation would presumably ameliorate that problem. also, static typing would give me compile errors instead of unexplained slowdowns when i do something that frustrates the optimizer<p>the readme says, 'Compared to LuaJIT, Pallene aims to offer more predictable run-time performance.'<p>but seriously luajit is astounding. in <a href="https://gitlab.com/kragen/bubbleos/blob/master/yeso/mand.lua" rel="nofollow">https://gitlab.com/kragen/bubbleos/blob/master/yeso/mand.lua</a> there is semantically a function pointer invocation per pixel (<i>pixfunc</i>), but luajit's trace compilation apparently hoists that entirely out of the inner loop of drawing the fractal. conventional compilation of statically typed languages, even ocaml, can't do anything like that; you need something like c++ templates to specialize the inner loop for each possible fractal being drawn