Remix.run Logo
jhatemyjob 4 days ago

I understand your frustrations since you are forced to work within a codebase that is shared with other developers with varying levels of experience. Lua was from the get-go never supposed to be a standalone language, it is more of a complimentary language and if you fail to respect that then it becomes unwieldy, quick. It is extremely easy to shoot yourself in the foot with the language and once bad design decisions creep in it is hurts a LOT. However once you get enough experience with the language you manage stay within the "happy path" (which is EXTREMELY difficult when you are on a team with salaried software engineers with different and often misaligned incentives) it is actually one of the best languages available.

One of the things I suspect your team is doing wrong is you are using the PUC Lua C API instead of the LuaJIT FFI. That is one of those things which just completely destroys the "happy path". The PUC Lua C api is effectively a deprecated feature at this point. A few years ago you could have made the argument that the PUC Lua C API is more portable than LuaJIT which is absolutely true. But q66's (from Chimera Linux fame) cffi-lua project nullifies that argument since you can now use the luajit-style FFI in PUC Lua, which works on every platform that libffi supports.

Again I understand your frustrations with the language since you are working within a fundamentally adversarial environment. Perverse incentives can easily destroy any good patterns you can establish since the language is so flexible. I implore you to explore the language outside of your day job.

mabster 4 days ago | parent [-]

We were using Luajit with our own extensions with our own binding mechanisms that included automatic translation of indices. And we had A LOT of bindings.

There was some "fun" there. Luajit C functions uses space indentation that becomes tabs every 8 spaces, i.e. mixed tabs and spaces. And his custom assembler for the assembly portions.

I personally spent a lot of time "refactoring code to generate less garbage" as we had purposeful garbage collection in our idle time.

One of the advantages with Lua was that everyone could code in it. I.e. for our games all the artists, sound engineers and producers were developing Lua which was super productive.

But the function signature one in particular - that would have saved me a lot of stress on release nights!

jhatemyjob 3 days ago | parent [-]

Oh wow you were editing the source of LuaJIT? That sounds like a nightmare. I'm pretty sure Mike Pall is the only person who understands that codebase lol.

To be honest I am trying to move away from LuaJIT, now that q66's cffi-lua project exists I don't have a reason to use LuaJIT from a dev productivity perspective. For speed, sure. But for my use-case regular Lua is fast enough and the added features in 5.4 over 5.1 are really nice. Plus having the option to easily edit the Lua source code if I want gives me a lot of comfort, since the codebase is way simpler than LuaJIT's.

I have removed LuaJIT from everything I use other than OpenResty. If I could, I would remove it from OpenResty but that is a huge undertaking

Yeah the garbage collector is one of the things in Lua I really don't like - in Lua 5.4 Roberto added the <close> thing and generational GC but I'm not sure how well these work in practice. I guess I'm lucky enough in that I have never hit the upper limit where a GC cycle totally kills performance and if that ever happens I have the option of rewriting that code in C