lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]



How the risk of a Lua fork increases with the community size, given the slow release pace and even slower features introduction pace?


Lower releases pace to mature design idea combined to the flexibility not to ensure ascending compatibility allowed the language to evolve efficiently as long as there was a clear roadmap and as the release pace was matching industrial project lifetime (until 4.0).


As soon as the pace has slow down, it let other languages more prone to (too?) early address requirements spreading. Sadly this happened at a key moment when interpreted language interest was growing. This was very bad for the language because it also kept community too small to maintain rich third part libraries that are as important as the core language for the success of a language.


The mismatch with industrial pace and Lua releases also made Lua cheia initiative appearing as a signal that Lua was strongly needing to evolve. This pushed to release Lua 5 and 5.1 thus trying to come back closer to an industrial project pace and suddenly community has grown again to reach a visible state to the tiobe index. So are the requirements, even though most of them are not new but stagnating in a proprietary/open source patch area for serious users.


But Lua’s authors have written:

-          They have reached the point where they have no idea which feature needs to be introduced.

-          They worry about the core not the libraries (very worrying: how to make a full language then?)

-          They want to keep slow release pace

-          Acknowledged that Lua has a single maintainer


The last major release has already an industrial project lifetime, so that new projects may again not select Lua and one could then see interest decrease. The condition that let Lua cheia appeared are met again and the same reactions are seen: Idle, and LuaJIT. Their approach is different but addresses parts of current requirements so that the pressure might be strong on them to provide what the reference release doesn’t.


Few points need to be addressed or at least discussed soon to build a roadmap and give visibility.

These are not all core features.

- support for Unicode

- richer pattern matching

- just in time compilation

- bitwise operators (this is a core feature, not a library feature: just try to imagine using arithmetic operators as a library)

- probably 0 indexed array (Lua has resisted to much more disturbing changes…)

- efficient class model

Not addressing some may just alienate part of community which may satisfy narrow embedded core community.


So the risks are probably that:

-          Lua interest drops

-          Lua interest is maintained but may escape from original authors to more active maintainers.