[hugomg]

Pallene is indeed approaching this problem more for performance than for autocompletion. (For just autocompletion it would be more appropriate to use a typesystem that is closer to full Lua, like Typed Lua)

For us, the main motivations for the Pallene approach are performance predictability and implementation complexity.

To get maximum performance with a JIT you need to write your code in a way that ensures that the control flow always stays inside the compiled parts of the code. If you are accidentally "too dynamic" then the JIT will fall back to the general bytecode interpreter, with an order of magnitude slowdown. The Pallene type system should ensure that if your code typechecks then it can be compiled to something reasonably efficient.

The type system also lets us use a simpler ahead-of-time compiler instead of a just-in-time one. JIT compilers are notoriously tricky to implement, which in turn means that it is more difficult to evolve them together with the language, or to port them to additional platforms.

[mraleph]

When you say "JIT compilers are notoriously tricky to implement" what, I think, you actually mean is "optimizations for dynamically typed languages are notoriously tricky to implement".

If the language you need to compile is Lua - then it does matter whether you are trying to compile it just-in-time or ahead-of-time. Both would be hard to implement if you care about performance (and implementing an AOT compiler that produces fast code would probably be even harder than JIT).

Similarly if your language is like Pallene - which reminds me of Oberon-2 of all things, then you can implement both AOT and JIT with much less effort.

That does not however mean that AOT is trivial to write - as you increase the expressivity of the language and add more ways to write abstract code so does the complexity of optimizing away the cost of those abstractions (eliminating indirections and allocations, resolving polymorphic calls statically, etc)

Finally at some point, even a language like Pallene might benefit from a JIT - because of JITs' ability to see the execution and focus on actually taken execution paths, rather then looking at the program as whole and not knowing which paths would actually be taken.

[hugomg]

You hit the nail on the head. With a more "Oberon-like" language we can use textbook optimization algorithms and take advantage of existing compiler backends, like GCC and LLVM. For dynamic languages these techniques aren't enough so more sophisticated JIT compilation seems to be the only option.

[catwell]

I strongly second that. We are more and more former users of LuaJIT who either don't use LuaJIT anymore, or think it is not a good long-term solution, because of those two issues (and absence of support of recent Lua versions).

In addition to that, people working on Titan say it could become an alternative to C for people who write applications in PUC Lua + C:

- It has an FFI so it can be used to implement bindings.

- It can also be used to extract performance-sensitive code from Lua into a compiled language.

- It should support newer Lua versions, being developed by people from PUC / close to PUC. Yay, 64 bit integers and bitwise operators!

[hugomg]

Yup, this is the idea. :)

If you don't mind, I'm curious about what applications you currently use Lua for.

[jdright]

This will be very useful for platforms (mostly game consoles) where JIT are prohibited / security risk.

[catwell]

At work, I use Lua 5.3 embedded into a large-ish (a few hundred thousand LOC) cross-platform (runs on Windows, Mac, Linux, iOS, Android) C application as a way to extend it. We have bindings for a lot of the C functions and use Lua for prototyping. We keep the code in Lua in production if possible, or rewrite in C if performance issues force us to.

Personally, I use Lua for a lot of other things including Web development.