LuaJIT 3.0 proposed syntax extensions
LuaJIT 3.0 is proposing significant syntax extensions, aiming to enhance developer experience with features like a ternary operator and C-style logical operators. This move sparks lively debate on Hacker News, questioning LuaJIT's identity, its compatibility with standard Lua, and the philosophy of language design regarding simplicity versus conformity. The community grapples with whether these changes are improvements or a step towards an unnecessarily complex "new language."
The Lowdown
LuaJIT 3.0 is poised for a significant evolution with proposed syntax extensions, detailed in an umbrella issue on GitHub. The primary goal is to enhance developer quality-of-life by adopting proven syntactic constructs while carefully avoiding complexity and maintaining compatibility.
- The project explicitly aims to integrate syntax extensions that:
- Improve the developer experience.
- Are already established in other languages or Lua dialects.
- Do not introduce syntactic ambiguities.
- Preserve backward compatibility.
- Facilitate tool development (formatters, LSPs).
- The maintainer emphasizes a commitment to avoid the syntactic complexity found in languages like Perl, Ruby, C++, or Rust.
- Feedback is encouraged on design and semantics, with a request for constructive discussion, steering clear of subjective "bike-shedding" over minor symbol choices.
- Future plans include consolidating documentation for the entire language, with new extensions clearly marked by their introduction version.
- This initiative consolidates and replaces previous discussions on specific syntax features.
This strategic overhaul signals a renewed and ambitious development trajectory for LuaJIT, moving beyond mere maintenance to actively shape its future language features.
The Gossip
Diverging Paths: LuaJIT's Identity Crisis?
Many commentators express concern that the proposed syntax changes will cause LuaJIT to fork significantly from standard Lua, questioning whether it should even retain the "Lua" name. They worry about compatibility issues and a departure from Lua's minimalist philosophy, suggesting the project is creating a new, distinct language rather than an optimized Lua runtime.
Ternary Temptation: Clarity vs. Complexity
The introduction of a C-style ternary operator (x ? y : z) is a hot topic. Proponents argue it's a clearer, safer alternative to Lua's 'and/or' idiom for conditional assignments, improving readability. Critics, however, warn of potential nesting complexities, reduced readability, and argue that 'if-then-else' expressions or even if-as-expression are superior alternatives, suggesting the ternary operator promotes "code golfing" over clarity.
Symbolic Shift: Aesthetics & Conformance
The debate extends to replacing keyword operators like 'and' with symbolic '&&' and introducing other C-style symbols for bitwise operations. Some see this as unnecessary "surface-level" change that makes Lua "no longer look like Lua," hindering learnability and adding "more than one way to do it." Others argue for conformity with widely used languages (like C/JS) for developer familiarity or even for AI model training bases, despite some admitting C's symbolic operators can be "inscrutable."
LuaJIT's Reawakening: Surprising Development
A recurring sentiment is surprise and excitement about LuaJIT's renewed active development, as many perceived it to be in a long-term maintenance-only state. Commenters express hope for continued innovation and ponder the implications for other projects relying on LuaJIT, though some note the challenges these changes might pose for existing Rust bindings or platform compatibility (e.g., iOS, Wasm due to self-modifying code restrictions).
Language Design Dogma: Simplicity vs. Ergonomics
Underlying many specific syntax debates is a broader philosophical discussion about language design principles. The core Lua values of simplicity and purity are weighed against the desire for "quality-of-life" features and modern ergonomics found in other languages. This includes discussions on the necessity of "then" keywords, the ideal way to handle conditional logic, and whether adding more syntactic sugar is beneficial or detrimental to a language's long-term health and learning curve.