I’ve used it in many games.

It’s a simple, but powerful language that uses basically two features (functions and hashmaps) to implement everything. Ex: script files are implicitly functions. Global variables are in a hashmap. Semantically it is very much JavaScript without all the surprises. Semi-technical users (artists and designers) can figure it out and go on to make surprisingly powerful features.

The binary code is small and fast. The standard library is small and most of it can be removed easily. Parsing source to bytecode is quick. Loading bytecode is very fast.

It is easy to embed. It’s easy to contain it’s memory allocations in an arena. It’s easy to restrict what it can and cannot do. It’s easy to interface with C/C++. It’s extremely portable.

I use it as a configuration and data language, mostly for building APIs for other libraries (like SDL2).

The syntax is simple and clean, like JSON but without the most commonly cited warts (no requirement to quote keys, and comments are allowed.) The VM is lightweight enough that including it in an application is practically inconsequential. I like its modular syntax as well. There are also bindings for just about every language out there, making Lua code more easily portable and embeddable.

It's not without its flaws as a language but to me, it's better suited as a config language than TOML, YAML or XML for most use cases where you don't actually need their complexity, or JSON if you're not on the web.

It's the language used in my digital signage service for the Raspberry Pi (see https://info-beamer.com & https://info-beamer.com/doc/info-beamer). The main reason to choose Lua back when I started was the there were no serious alternatives for:

* Easy embedding. Compared to Python and ruby which I looked at back then, Lua is so much simpler.

* Fairly easy to learn for users. After all, the complete syntax is one page long: https://www.lua.org/manual/5.1/manual.html#8

* Quite expressive with coroutines, tail calls, metatables, ...

* Trivially allows multiple interpreter instances within the same program.

* More than fast enough, especially once LuaJIT was released.

For KVdb [1], my managed key-value store database, I opted to integrate Lua as a scripting language instead of JavaScript because it felt super lightweight and the syntax is easy to learn in a few hours for even newbies. I'll probably end up adding JavaScript, too, since most developers know it, but there is a simplicity about Lua that I haven't seen in many other somewhat popular languages.

[1] https://kvdb.io/docs/scripting

I've built a collection of Android musical instruments [0] and Lua was big win for the project. I was previously familiar with Lua and Love2D framework and I wanted to see how far I can push it. The language is expressive and lightning fast. Very few building blocks that fit together nicely. I dig tables as first class objects, and meta-tables to turn them into complex objects or call delegation mechanism.

My favorite feature is that it's interpreted. The Android app is just a runtime. I can edit source files right on the phone and re-execute. It's awesome prototyping platform.

[0] https://github.com/jmiskovic/hexpress

BNF is amazingly short and therefore language is easy to learn [1]

VM is tiny and can communicate bi-directionally with C / C++ code very easyly, makes it the ideal candidate for embedding in a larger app as a scripting language.

[1]http://lua4z.com/doc/manual/syntax.md.html

I use it as the scripting, and implementation, language for a console-based mail-client. (Think "mutt", but with real scripting instead of the ad-hoc support that mutt has.)

I use it because it's a simple language that is quick to code in, and trivial to embed inside a C, or C++, host application.

If I were to begin the project again I'd have no qualms about a similar approach. (Writing the core in C++ with a notion of display-modes, email-parsing, etc, and the actual control in Lua. The biggest painpoints were dealing with MIME, and similar broken emails which was largely irrelevant for the lua-side.)

My OpenStreetMap tag processing pipeline: OSRM, osm2pgsql and tilemaker all allow you to write tag-mangling scripts in Lua.

I use it as a way to rapidly prototype stuff related to new C-APIs https://github.com/wiladams

Currently using it to create a tiny Postscript interpreter: https://github.com/wiladams/lj2ps

It's really big in the gaming industry. For certain engines it's the de facto standard.

Planimeter's Grid Engine is the largest pure-Lua game engine. https://www.planimeter.org/grid-sdk/

I use it as a scripting language for my game engine, but also for all the tooling around it. Premake for generating the VS solution/makefiles, but also my own tools using IUPLua [1] and a few other modules (lfs, sqlite etc). Pretty much my whole ecosystem is C++/Lua.

[1] - https://www.tecgraf.puc-rio.br/iup/en/iuplua.html

It’s great for embedded scripts in Redis.

I use it as a stateless HTTPS load balancer in NGINX where all the certs are stored on S3/GCS.

I used it because that's what I needed for configuring Hammerspoon. Been rather pleased with the language overall, but don't have any other uses for it. Hammerspoon has been killer, especially once I figured out some simple metaprogramming.

I embed it as a simple interactive query language for a time system at the local computer club. I wanted to use guile, but my fellow computer clubbers lose all their intelligence when they see parentheses.

Pretty much only for modding software/games that provide a lua API. If I were to create a software like that I would definitely consider implementing a scripting interface with LUA.

Mostly for running untrusted third party code (usually video game mods) inside a larger program that is written in C++.