The interesting engineering problem isn't necessarily inventing fundamentally new operations. It's providing convenient ways to express existing operations while preserving predictable behavior, efficient execution, and useful tooling.
JSL doesn't require a permanent fork of Luau's compiler.
Instead, L3i implements a source frontend that recognizes the extended syntax, lowers it into ordinary Luau, and maintains source mappings so diagnostics and analysis refer to the code you actually wrote.
The resulting program still goes through Luau's compiler and type checker.
That means we get to experiment with language features without maintaining an entirely separate compiler backend or type system.
It's also meant a rather absurd amount of work ensuring that the resulting code behaves exactly as intended. Evaluation order, short-circuiting, error conditions, type inference, and performance all matter.
A language feature that makes code prettier but quietly destroys performance isn't particularly attractive to me.
## So why build all this?
Initially? Performance.
I started experimenting with moving native applications and tools into Luau, then became increasingly interested in what could be accomplished with a relatively small native runtime and a much larger programmable environment.
That eventually produced L3i, JSL, and Jess.
Jess itself has grown into something much broader: applications, packages, workspaces, capability-controlled execution, and infrastructure for tools and games.
But the underlying motivation remains the same.
How much work can we move into Lua without giving up the performance and control that traditionally push developers toward native languages?
I don't think the answer is necessarily to turn Lua into Python or Rust. I like Lua precisely because it isn't those languages.
I do, however, think there are useful ideas worth borrowing.
Some come from Python. Some come from Rust. Some come from staring at a perfectly reasonable syntax decision and deciding that it simply isn't offensive enough.
And I'm perfectly willing to throw an idea away if the measurements don't justify keeping it.
For anyone interested in the implementation, the L3i dialect documentation covers the lowering model, semantics, source mappings, and performance measurements in detail.
Both projects are open source under MIT/Apache-2.0. They're still evolving, and I'd welcome technically grounded criticism.
## So here's a question.
What's one feature from another programming language that you desperately wish Lua or Luau had?
And, more importantly, what would it actually buy us?
I'm especially interested in features that improve expressiveness without imposing significant runtime costs, or that let us express operations in ways a compiler can optimize more effectively than conventional function-based APIs.
Tell me what you'd add. Tell me what you'd absolutely refuse to add.
Bring your worst ideas. I have a compiler and questionable impulse control.
JSL: I started optimizing Lua and accidentally built a language dialect
This entire adventure started with an obsession over Lua performance.
It has since escalated into maintaining a custom Luau dialect.
Oops.
I'm the developer of Jess, an open-source, cross-platform application runtime built on Luau, powered by a Rust binding framework called L3i.
Jess uses JSL (.jsl) as its primary scripting language. The familiar Luau foundation is still there: gradual typing, strict checking, tables, functions, and all the usual conveniences.
But I wanted to see how far we could push the language without losing the things that make Lua attractive in the first place.
And, crucially, without making it slower.
## First, the boring part.
A complete Jess script looks like this:
--!strict
local log = require('@jess/log').new 'hello'
print(`Hello from Jess {jess.version}.`)
log.info 'ready'
Run it with:
jess run hello.jsl
Nothing particularly exciting. It's Luau, running outside Roblox, with access to a set of native APIs, a type checker, a module system, and a CLI.
That's the baseline.
Now let's make things interesting.
## Comprehensions, reducers, and generators
One of my favorite additions is Python-inspired comprehensions, with a slightly different approach to their syntax and execution.
-- Filter and project
local ids = [for e in entities if e.active => e.id]
-- Sum without constructing an intermediate array
local mass = sum[for body in bodies => body.mass]
-- Short-circuiting boolean reduction
local heavy = any[for body in bodies => body.mass > 100]
-- Pairwise iteration, requiring equal lengths
local totals = [for a, b in zipStrict(xs, ys) => a + b]
We support nested generators, filters, range, enumerate, zipShortest, and zipStrict, along with sum, min, max, any, and all reducers.
An ordinary comprehension produces a dense, 1-based array. Reducers operate directly on the generated values without constructing intermediate tables.
The important part is how these expressions compile.
They're lowered into ordinary Luau loops.
No iterator objects. No callback per element. No intermediate arrays unless the operation actually requires one.
In our instruction-count benchmarks, the resulting loops execute extremely close to equivalent handwritten implementations. There are explicit semantic checks, such as rejecting nil projections, but we've been careful to measure their costs rather than simply assume the syntax is free.
## Slices and destructuring
We've also added slicing and record patterns.
-- Inclusive, 1-based slicing
local sample = values[1:16]
-- Destructure a record
local {x, y, z} = position
-- Rename fields
local {health: hp, name} = entity
-- Nested destructuring
local {transform: {position: pos, rotation}} = entity
Patterns work in local declarations, function parameters, and comprehension generators.
They lower to ordinary local bindings and field accesses, preserving Luau's normal indexing behavior, including metamethods.
There isn't a new object model lurking underneath this. That's intentional.
## And because apparently that wasn't enough...
The dialect also supports typed buffer slices and sinks.
For example:
-- Read f32 values from 16-byte records
local mass = sum[for value in bodies[1:n, "f32@16"] => value]
-- Reuse an existing table as output storage
into(scratch)[for x in values if x > 0 => x * 2]
This is particularly interesting for the kinds of workloads I've been experimenting with: processing binary formats, large datasets, game assets, and other situations where allocating thousands of temporary Lua objects isn't particularly appealing.
Certain recognized buffer reductions can even dispatch directly into L3i's native bulk-data operations instead of executing a scalar loop.
This is where the relationship between the language and the runtime starts getting interesting.
I've been building Limer, a desktop development environment for creating GUI applications in Lua, and version 2.0 is out! It's available for Windows, macOS, and Linux.
The idea is simple: write your application once and use the same codebase across all three operating systems. No separate implementations for each platform.
# What makes Limer interesting?
Visual designer: Drag real widgets onto a canvas, configure properties, arrange layouts, and generate readable Lua code that you can own and modify.
Live inspector: Inspect running applications, change widget properties, and execute Lua code.
60+ widgets and components: Including layouts, charts, and SQLite support.
Standalone distribution: Limer comes with its required dependencies, so you don't need to install Lua separately or manually configure its runtime.
Application building: Package your projects for distribution across supported desktop platforms.
API search and error reporting: Find API functionality quickly and track down errors in your code.
Limer is built on Limekit, my GUI framework for Lua. Interestingly, Limer's development tools—including its project manager, code runner, visual designer, and live inspector—are themselves built in Lua using Limekit.
It's a Lua desktop app for building Lua desktop apps.
# Prefer VS Code?
There's also a Limekit VS Code extension for developers who prefer their existing editor.
It includes code completion, API documentation, diagnostics, Lua error reporting, code snippets, and a Run button.
# Download Limer 2.0
GitHub repository and downloads:
https://github.com/mitosisX/Limer-Limekit
The engine running all of the magic behind the scenes
https://github.com/mitosisX/Limekit
Limer and Limekit are free and open source under GPL-3.0.
If you find the project interesting, please consider giving the repository a ⭐ on GitHub! It helps more developers discover the project and motivates me to keep improving it.
A quick note: the macOS builds still need more testing on real Macs, and the applications aren't code-signed yet. Feedback and bug reports are very welcome.
I'd love to hear what you think. What would you build with Lua on the desktop?
Se me borraron los datos guardados de mi juego al actualizar windows (LuaTools)
/r/PiratedGames/comments/1xbx8d7/se_me_borraron_los_datos_guardados_de_mi_juego_al/