I believe, but am not certain, that the change was made to help speed up Lua. As an embedded language, and a language that runs on embedded devices, performance

I believe, but am not certain, that the change was made to help speed up Lua. As an embedded language, and a language that runs on embedded devices, performance is one of the key criteria of design that goes into the language. The compile-to-bytecode step may have seen some improvement with the change. So instead of speculating on why the change happened, I've found a few bits of information around the limits that make me feel like it often simply won't be a problem. There's some interesting discussion around the limits across various platforms here [0]. Whilst I'm not entirely clear on the motivation, even Lua running inside a browser under emcripten has a stack limit of over 4000, which is somewhat decent even for recursive functions. Whereas on Linux you seem to be able to tweak a config when building and safely have it in the region of 20,000, and quite possibly more. Even under a tight restriction, Lua seems to cope fairly well with it when recursing (the example crashed at 1758 recursions for a ulimit of 400). Whilst Python has a terrible limit of 1000 for the default recursion limit which is somewhat comparable to this aggressive test, Python also has no tail call elimination - but Lua does. I have a somewhat large Lua project (6000 lines of C, 10,000 lines of Lua) that is a recursive parser for a format that I passionately hate (think self-modifying LaTeX). With the default 5.4 limits it never hits a point where it crashes, though I had expected it to. [0] http://lua-users.org/lists/lua-l/2019-06/msg00083.html http://lua-users.org/lists/lua-l/2019-06/msg00083.html