It seems to me the outstanding feature of Lua's design history is its designers' determination to make the core ever simpler and more general. That takes vision and courage over a long period of time. What emerged is truly interesting and inspiring (much more so than cobbled languages that grow only by accretion of features) and is likely to grow in importance.
Yes, that is very much how I feel about it. They boil every concept down into its purest essence, and always avoid having two abstractions when one will do. Other languages grow when they need new features, Lua refines.
But in a blog entry I'd like to address several of Lua's core abstractions and how they are cleaner and more general than competing languages. For example, the Lua thread data structure encapsulates all necessary state for a thread, but is general enough that it actually allows for multiple thread execution models. By default only coroutines are provided (which use the thread data structure). But you can implement lua_lock()/lua_unlock() to have a Python-like model with preemptive threads and a GIL. Or you can use lua_sethook() to implement a "green thread" model where multiple pre-emptive Lua threads run inside a single OS thread.
Three options for threading models (probably more if you dig in), one core abstraction and implementation. Remarkable!
I wonder what examples one could dream up where manipulating that thread data structure in an application-specific way would be a win. i.e. some kind of domain-specific threading model.
Manipulating the thread data structure directly would violate the encapsulation of Lua and prevent you from being portable to eg. LuaJIT. But there are still lots of opportunities for building custom threading models; see:
