Runtime Containers with Package Manager Support in Roblox Studio

Feature Requests Studio Features
1

As a Roblox developer, it is currently too hard to:

  • Use programming languages other than LuaU inside Roblox Studio.
  • Integrate external libraries and frameworks safely.
  • Manage dependencies for external languages directly from Studio.

If Roblox is able to address this issue, it would improve my development experience because:

  • I could safely use Python, Rust, JavaScript, or other languages inside Roblox.
  • I could install and manage external libraries directly in Studio, without workarounds.
  • This would unlock faster development of complex systems, AI, procedural generation, and more.

Use Cases:

  1. AI and Data Processing

    • Problem: Implementing machine learning or advanced math in LuaU is limited.
    • Example (Python):
      import numpy as np
data = np.random.rand(100, 2)
mean = np.mean(data, axis=0)
    • Benefit: Using Python with libraries like numpy or scikit-learn enables efficient computation inside Roblox.

  2. Procedural Generation

    • Problem: Generating large terrains or structures in LuaU can be slow.
    • Example (Rust):
      use rand::Rng;

fn generate_terrain(width: usize, height: usize) -> Vec<Vec<f32>> {
    let mut rng = rand::thread_rng();
    (0..width).map(|_| (0..height).map(|_| rng.gen_range(0.0..1.0)).collect()).collect()
}
    • Benefit: High-performance languages allow complex generation, results passed to LuaU.

  3. Package Manager Integration (Sub-Feature Idea)

    • Problem: Managing external dependencies manually is tedious.
    • Proposal: Roblox Studio could interface with package managers like pip, cargo, or npm for each runtime container.
    • Benefit: Developers could install libraries directly inside Studio, making Runtime Containers fully self-contained and production-ready.

Additional Thoughts:

  • Each container should be sandboxed to protect Roblox security.
  • Curated library support ensures safety and performance.
  • This system would turn Roblox into a polyglot development platform for games and educational tools.

Summary: Runtime Containers with package manager support could allow Roblox developers to safely use multiple languages and external libraries, opening a whole new level of creativity and technical capability inside Roblox Studio.

2

Shameless promotion, but my team and I are working on a package manager solution called Forest. (https://forest.dev/)

In regard to using other languages, the main thing is it doesn’t make sense from an engine perspective. Are these things you’d need a runtime or just in studio? If it was just studio, you could set up a pipeline that lets you interface with a local server for computation logic via HTTP, but any language container you end up using would have to be accessed by Lua anyway to interface with any physical instances, so you’d lose the real benefit for anything that’s not strictly computational.

3

Hey there,

I’m not sure why the Forest folks are plugging their product here, but the overarching request is about support for multiple languages on Roblox. So, I’ll address that question, as the question about using package management for those languages only really makes sense to ask if Roblox was built on multiple programming languages. There’s lots of ways to imagine “support for multiple languages,” but I’m going to address two: the one that is most similar to how Roblox works today, and the one that you’ve actually suggested here.

It is certainly possible to imagine a product similar to Roblox that was built intrinsically with a multilingual approach in mind where the core runtime of the platform was built around something like the JVM or the CLR. In such a world, Studio would’ve been designed around being a multilingual editor, and the whole product would probably look quite different (in some ways better, in some ways worse). There’d be different security tradeoffs between the different runtime choices, we’d probably have had a number of existentially critical security vulnerabilities over the history of the company, and the destiny of the whole platform would be fundamentally beholden to the whims of the companies that own the runtimes we built on (Oracle and Microsoft respectively for the two I mentioned).

In the world we live in, Roblox made a choice in the mid-00s to use Lua as the foundation of programmability on the platform because the runtime was very small, easily embedded into the larger game engine, and ultimately an industry standard for Games. Lua’s VM design is not built with multilanguage support in mind, and when we wrote Luau and the Luau VM to replace it, there was already millions of lines of code in Lua on the platform. Our goal was to make everything transparently work, but work better, run faster, etc., rather than to fundamentally rearchitect the platform around multilanguage support. This is an intentional strategy choice: we believe our community is stronger when there is a consistent language that programmers know and work in. It means documentation, tutorials, libraries, plugins, videos, etc. are overwhelmingly focused on the same language and same developer experience, and that investments in those things benefit as many creators as possible. It also means that we can focus our development efforts around making Luau, Studio’s Script Editor, Luau’s development tooling, and so forth as excellent as they can be, rather than having to split our limited resources across support and documentation for a large number of languages.

The specific proposal to build an entire new architecture for Roblox around containers (presumably thinking of Docker) is a difficult one. Docker does not actually support Windows and has pretty mixed support on macOS, and their entire approach to containerization depends on specific integrations with the Linux kernel. Without explicit kernel support, you end up having to rely on virtualization to achieve the sandboxing you’re trying to have in mind, which comes at considerable performance costs that would be hard to justify in a world where performance is already one of the greatest creator pain points. And even if we could somehow get past all of that, we’re left with an immensely difficult problem: how do all of the containers talk together? How do the containers talk to the engine? How do we make programming for Roblox accessible with a programming model built around complex container orchestration and communication strategies? These are all in principle things we could address, but professional engineers with a decade of experience still regularly run into critical bugs stemming from the difficulties of understanding large container-based systems and the answers to the communication questions will all come at very real costs that would likely make it very difficult for people to make performant experiences on Roblox without considerable amounts of experience in software development.

tl;dr: making a massive multi-language developer platform that’s easy-to-learn, easy-to-use, and highly performant is an essentially unsolved problem with unbounded costs both in terms of money and in terms of complexity, and we strongly believe Roblox is better off doing less, better.

P.S. the language is called Luau after the Hawaiian festival, it’s not an acronym and the u is not capitalized. :slight_smile:

4 Likes
4

What about support for other languages that also compile to Luau bytecode? I personally have some gripes with Luau that would just not fit with the language at all (and as such, I’d like to refrain from making an RFC just for it to be immediately shot down, as that would just be a waste of everyone’s time). I could write a language that compiles to Luau, but then I wouldn’t have nice support for it in Studio and I’d be limited to using tools like Rojo, which is fine for big projects but isn’t all that great for simple testing.

I understand the sentiment of “only one language” due to documentation, but what about letting developers of said Luau-adjacent languages provide their own versions of the code snippets in the documentation that can show in place of the Luau if the user explicitly states they wants to see that language?

side note, I also agree that focusing on one language only is the best, but my question stems from knowing quite a bit of other languages and feeling like “if only I could do this in Luau”—not that I want to outright just write some language that you would never consider adding (like Java or OCaml) in Roblox.

5

What about support for other languages that also compile to Luau bytecode?

If there was serious investment from anyone today in another language that compiled directly to Luau bytecode, that would definitely be a conversation worth having! In particular, there’d be a first-order requirement of us needing to invest a lot in hardening the VM against arbitrary bytecode. Today, we’re confident in the sandboxing and security of the VM when we know that the bytecode is in the image of our compiler (i.e. when we know that what we’re executing is something that either was or would’ve been generated by our compiler), but we have not done all the work necessary to know that for arbitrary bytecode sequences and that’d be an obvious prerequisite to opening up the VM to other compilers targeting it on Roblox. Of course, outside of Roblox, you’re very free today to compile to Luau bytecode and execute it in a Luau VM.

There’s also always going to be a resource balancing act to do, especially for things requiring active support on our end. The entirety of Studio’s Script Editor, for instance, is built around Luau specifically, so the most immediate desired user story of “I would like to be able to edit scripts in X language with autocomplete, hover type, go-to-definitions, etc.” would be a very significant amount of work. As is, the Script Editor team has a bunch of high priority work they’re trying to do to make the experience better for today’s users, programming in Luau, but adding on huge architectural changes to their backlog would be a tall order, and likely wouldn’t come to fruition for quite some time even if everyone bought into the idea that supporting a second language targeting the Luau VM was the right call.

I understand the sentiment of “only one language” due to documentation, but what about letting developers of said Luau-adjacent languages provide their own versions of the code snippets in the documentation that can show in place of the Luau if the user explicitly states they wants to see that language?

As I alluded to above, there isn’t anyone (at least that we’re aware of on the Luau team) working on any languages targeting the Luau VM today, but there are a few reasonably mature projects targeting compilation to Luau like roblox-ts. I’m not responsible for the decision-making around Creator Docs, but I don’t think it would be an unreasonable suggestion to ask for the community to be able to contribute (clearly-marked-as-third-party) equivalents for code samples in our docs. We’ve made some progress in the past few years on highlighting mature third-party tooling in our docs already, and that feels like a consistent step in support of that to me.

my question stems from knowing quite a bit of other languages and feeling like “if only I could do this in Luau”

From my perspective on the Luau team (which really has a charge to own any Roblox-developed languages that power scripting in the Engine), I’d say that it’s not difficult to imagine a future in which there are more languages targeting the same VM, but that that future is clearly a ways out since there is a tremendous amount of work we can still do today that makes Luau and Luau development actively better, and that sort of work is an immediate lift for all creators and all of their existing projects, as opposed to investments in new languages which are limited to only benefiting future work. As much as humanly possible, we want to make Luau into a language so delightful that programming in other languages makes you wish “if only I could be doing this in Luau,” and I think until we’ve clearly hit a wall there, it’ll be hard for us to justify building an entirely new language or frontend to the Luau VM.

4 Likes
6

This is a great response—thank you!