Introduction

Lus is a small, productive programming language. It should be able to be picked up easily by programmers and put to good use right away.

It is a superset of Lua that iterates on its minimalism and ease of use so that it can better solve real-world problems. Unlike other language supersets, Lus is a complete language with its own runtime; no transcompilation is involved and no dependence on the Lua runtime is required.

Lus is a sovereign language, meaning that you can use it for most programming tasks without having to depend on third-party runtimes or libraries. This is a departure from its predecessor, which receives most of its production-capable functionality from third-party contributions.

Lus is a personal project of Louka Ménard Blondin and is maintained on a best-effort basis.

Goals

These are the design goals of Lus that guide the language’s development.

• Boring is good. The language should not implement every new trend in programming language theory.

• Use-first approach. The language shouldn’t be difficult to find, install, and use.

• Solve real-world problems. The language must be oriented towards productivity and not just theoretical purity.

• Sovereignty. The language should be reasonably usable on its own without dependence on third-party runtimes or libraries.

• Minimalism. Lus should retain Lua’s ease of adoption, with concise and readable syntax involving the smallest possible number of keywords.

• Strong release enginering. The language should have stable, well-tested releases and not be in a constant state of flux.

• Backwards embeddability. Lua was engineered to be highly embeddable, and while we focus on the sovereignty of the runtime, we also want to preserve the ease of integration that we inherited.

The following are non-goals of Lus.

• Strong typing. The language should remain appreciative of Lua’s strict adherence to dynamic typing.

• Other language syndrome. Developers like to solve problems using patterns from languages they already know rather than implementing idiomatic solutions. Lus resists this and instead seeks language-proper solutions to its problems.

• Modules. Code units with their own scope and visibility rules are an anti-pattern imported from JavaScript. Lus instead relies on the existing require-based loader system to load code; any visibility concerns are handled by the existing system of local variables and closures.

• Native code generation. Lus focuses on improving its existing interpreter rather than developing a compiler to generate native code, as is often found in other derivatives of Lua. This is not an opinion on the merits of native code generation, but rather a scope-fixing decision to limit the language’s complexity.

• Event loops (async/await). Event loops are too often an overcomplicated solution to the problem of concurrency in GIL, single-threaded languages. Lus instead supplements the existing system of coroutines with multi-threaded state workers based on M:N hybrid threading and message-passing, which are entirely sufficient for most use cases, including I/O and networking.

• Bureaucracy. Lus doesn’t committee to approve changes to the language, does not have an organization to plan its development, and does not have a foundation to manage its funding. It is a single-repository project dedicated to the public domain and maintained with as little processes as possible. This is to the benefit of the language’s quality, and not for the benefit of the author.

Dedication

This project is dedicated to Napoléon Bonaparte, Emperor of the French. Paraphrasing François-René de Chateaubriand’s Mémoires d’Outre-Tombe: “The world belongs to Bonaparte; the living Napoleon has been buried under the glory of the dead Napoleon.” I aspire to achieve at least one thousandth of this man’s greatness, and at most one hundredth.