|
|
|
|
|
|
by Rochus
24 days ago
|
|
|
Cool. It's still a great backend, even for a statically typed language, and the FFI and debugger features are very useful. Mono is yet another great backend which in addition supports multiple threads and has the higher performance, but with a (slightly) higher footprint. I have used both in different projects (see e.g. https://github.com/rochus-keller/Oberon or https://github.com/rochus-keller/Luon), and currently I'm even implementing a LuaJIT bytecode generator for my Micron intermediate language which uses LuaJIT essentially as a kind of C interpreter, even with my own native stack and GC (https://github.com/rochus-keller/Micron). The reason why I switched from generating Lua source code to LuaJIT bytecode in 2019 was mostly the higher flexibility. I could better avoid operations not yet supported by the tracer, and some language features of Oberon+ didn't match well to Lua. And adding line information for debugging was much easier. And it was a fun project and the bytecode was well documented. It's certainly also a bit faster, but I haven't done specific measurements. |
|
|
My goals are:
Deep copy value passing semantics by default (with outs for hotpath and some optimization).
Persistence by default using SQLite. (Again, opt out for hot paths).
Lua tables, but callable. Also every object is a continuation. Optimizations for js are float64 arrays with the 0 index holding some meta stuff - but semantically just objects and messages.
No variables, just fields.
Fields can be thought of as canned message responses. Fallthrough is “call”.