Ravi is a Lua dialect that adds optional types to the VM, not just to the compiler

Typing that reaches into the VM instead of stopping at the compiler

The usual way to add types to a dynamic language is to check them at compile time and then throw the information away, which is what the README says about Typed Lua: that effort is very similar to the approach taken by TypeScript in the JavaScript world, where the code is eventually translated to standard Lua and executed in an unmodified VM. Ravi's stated motivation is different. The author wants to enhance the VM so it can perform more efficient operations when the types are known, and type information is meant to be exploited by JIT compilation. The visible consequence is type specific bytecodes, listed as a feature in their own right, and an extended bytecode format that makes Ravi incompatible with Lua 5.x bytecode. The dialect relationship also runs the other way: since the typing is optional, Lua programs are valid Ravi programs.

A defer statement, backported from Lua 5.4 patches

Ravi has a `defer` statement for releasing resources, and it is the clearest example of the project's approach to Lua upstream. The repository carries patches for Lua 5.3 and for Lua 5.4 in its `patches/` directory, and the README links each one as implementing the defer statement. The author's position on the equivalent Lua 5.4 feature is stated in the position statement section: `<close>` variables are not planned, because Ravi has the `defer` statement which is the better option in his opinion. The same section records what has been back-ported from Lua 5.4, including the generational garbage collector, the new random number generator, string to number coercion moving into the string library metamethods, and the utf8 library accepting codepoints up to 2^31. It also records what has not, such as `<const>` variables, which are not planned, and the removal of the 5.1 and 5.2 compatibility layers, which is not implemented because Ravi keeps those layers as Lua 5.3 does.

JIT and AOT compilation through the MIR backend

Ravi's JIT is powered by MIR, a compact JIT backend in its own repository, and the repository includes a `mir/` directory as a submodule. There is also support for AOT compilation to native code, with a new compiler framework for both JIT and AOT work and an `aot-examples/` directory showing AOT compilation to a shared library. The JIT is not the point of the project, though, and the author says so directly: Ravi has a different goal compared to LuaJIT, prioritising ease of maintenance and support, language safety and compatibility with Lua 5.3 over maximum performance. That framing matters for expectations. Ravi is presented as a language you can hand to non-expert programmers, with the typing optional and the VM improved where the types allow, rather than as a faster LuaJIT. The AOT route is the one that is closest to a conventional compiler pipeline.

Lua 5.3 source compatibility, with real exceptions

Ravi should be able to run all Lua 5.3 programs in interpreted mode, but the README is careful about the caveats, and the reduced limits are the concrete ones. Ravi uses an extended bytecode, so it is not compatible with Lua 5.x bytecode, and the changed bytecode structure reduces several limits: MAXUPVAL drops from 255 to 125, LUAI_MAXCCALLS from 200 to 125, MAXREGS from 255 to 125 and MAXVARS from 200 to 125. Programs using Ravi's enhanced types, such as arrays, cannot be run by standard Lua at all, though the reverse direction works, since all Ravi types can be passed to Lua functions. Operations on Ravi arrays inside Lua code are subject to restrictions. Values crossing from Lua into Ravi are type-checked when assigned to typed variables, and there is a known issue in which upvalues cannot subvert the static typing of annotated local variables.

The quick make build skips the JIT on purpose

The top level Makefile is honest about its own limitations. Its opening comment says the preferred build method for Ravi is CMake, and that the Makefile might be adequate if you want a quick build without JIT or other options, since it is based on the standard Lua Makefile. The settings block at the top is the usual Lua one: the platform selector, the install prefix defaulting to `/usr/local`, the install locations for binaries, headers, libraries and modules, and the `V= 5.3` version marker. The `test` target is minimal, it just runs the interpreter with a version flag:

test: dummy
	src/ravi -v

The install target creates the binary, include and library directories and copies the headers, which are the standard Lua header set. So the Makefile is a convenience path, and anything involving the JIT means using the CMake build or following the MIR JIT build instructions in the documentation. The repository also has a `CMakeLists.txt`, a `build-utils/` directory, a `docker/` directory and a `ravicomp/` directory for the compiler work.

A Visual Studio debugger extension, and an embedding preview

Two features point at how the project expects to be used. There is a Visual Studio Code debugger extension, published in the marketplace as ravilang.ravi-debug, and the README describes it as an interpreted mode debugger, so it is not a way to step through JIT-compiled code. There is also a preview feature for embedding C code snippets, documented in the ravi-compiler wiki under Embedding-C, and the author has written an article about the same subject. Embedding C in a Lua dialect is a significant feature to have at preview stage, since it is the point at which the language stops being safe for non-expert programmers, which is a stated goal. A separate repository, Suravi, is described as a distribution with batteries, and there is a `.devcontainer/` directory and a `readthedocs/` directory for the documentation.

Beta tags from 2023, commits in 2026

The maintenance picture needs two dates, not one. The last push to the master branch was on 2026-09-12, so the source is still moving. The most recent release tag is 1.0-beta11, titled as a Ravi 1.0 Beta-11 release with JIT and AOT compilation support, dated 2023-01-14, preceded by beta10 in November 2022 and beta9a in July 2022. The version has therefore sat at 1.0 beta for a long stretch, which tells you the author has not felt the need to cut a 1.0 final, and a beta tag is a fair signal about the stability of a language implementation. The licence is a custom one that GitHub cannot classify, with the LICENSE file in the repository root as the document that governs. For an embeddable language runtime, that is worth reading before you depend on it.

Editorial conclusion

Adopt Ravi if you are already working in Lua and want optional type annotations that the VM can exploit, and you are willing to accept a dialect that is source compatible but not bytecode compatible with Lua. Do not adopt it if you need to run the same bytecode on stock Lua, because the extended bytecode format rules that out, and do not expect the performance work to come free, since the author prioritises maintainability and safety over maximum speed. Verify first that the MIR JIT builds in your environment, since the quick make build deliberately omits it, and read the compatibility section before you rely on any Lua library.

Frequently asked questions

Official sources

1. dibyendumajumdar/ravi on GitHub
2. Issues
3. Project website
4. README
5. Releases