(post deleted by author)
Not really. Exploits ran fine, even without using Luau. At most they might have typechecking now, but it won’t change much.
Closed-source Luau is just as vulnerable as open-source (although admittedly a tad harder to actualy figure out those vulnerabilities), but open-source Luau makes it more /likely/ that vulnerabilities are found, and closed, more quickly.
Roblox isn’t stupid, either. The Luau branch used for Roblox will have lots of verification and code review passes - bad, vulnerability-creating pull requests simply won’t be absorbed. And additionally–accidentally bad, vulnerability-creating pull requests are /more likely/ to be caught, simply because more people will be /able/ to review them!
This makes it easier to discover vulnerabilites that can lead to exploits, but only in the language itself – most Roblox exploits are targetting the APIs and vulnerabilities in individual /games/ /experiences/, not specifically Luau.
The upside is that it makes it easier for everyone to find these vulnerabilities – most importantly the people with the knowledge and ability to patch them.
@vrs2210 It’s not a win-win for all actors – its very much a net positive in favor of fewer vulnerabilities!
Is the script Becoming safe for use?.
Now all we need are some C bindings.
Luau is fairly limited in scope by comparison with just C++ but with C bindings thats basically interop access for most languages.
For those worrying about exploits: The integration into Roblox is still closed source and write your network code securely.
It seems that many people have the misconception that the Luau in the github is the same one that is in the Roblox player.
This is not the case, because the Roblox player and Roblox studio are like 2 different game engines, while they function outside the same, internally they are a lot different.
So no, it wouldnt make exploiting the Roblox Player any easier (expect maybe a little bit but only you should have a secure game structure).
You could just do
task = task or {
spawn = function(f, ...)
coroutine.wrap(f)(...)
end
}
I’m just losing global optimization that way, so it’s slower to access.
That isn’t even the issue, coroutine.wrap
is the only way to run a coroutine without getting rid of stack trace in OS Luau, however it only works for running functions. You can’t resume other coroutines using it, there’s no way afaik to resume a coroutine without losing your stack trace errors. I do custom resumption of threads quite a lot in Roblox Luau, and that would probably carry to OS Luau if I’m ever using it one day.
Having task.spawn
would also mean we could use GoodSignal and FastSignal without changing any code. In this case, yes, coroutine.wrap
would work, but afaik, and it should be pretty obvious that it should be slower, (Since you have to call an object that coroutine.wrap
returns) and that wouldn’t be ideal.
I can understand it not being added because of OS Luau’s “target users” not being people that just download it to use it raw, but actually to integrate it into something like a game engine.
I also don’t know if it’s possible to even add it, but then again I didn’t get any response from any engineer telling me otherwise, so.
task.spawn
is just lower-level than what coroutine.wrap
is, and it’s much more preferred to me and a lot of other people.
And this is ugly: ↓
coroutine.wrap(function()
end)()
-- Compared to this:
task.spawn(function()
end)
I mean, that’s true, but only barely. Yes, Luau could include task.spawn
, however, it couldn’t include task.defer
and task.delay
, because including those requires the presence of an event loop / task scheduler inside of your program, which there’s no requirement that the program consuming Luau has.
It would be kind of strange to only include one of the functions from the library.
Thanks, Roblox! This is incredible! Now, Roblox developers won’t have to learn new languages to create things off the platform. Can’t wait to see how high new inventions will soar.
In order to get task spawning functionality in open-source Luau, the application embedding Luau needs to have a task scheduler. Indeed, in order for any yielding operations, like sleeping/waiting, to be supported, you need a task scheduler of some kind. Perhaps it’s a simple one like “resume the coroutine immediately whenever it yields”, or perhaps it’s one that keeps references to coroutines around and keeps track individually of what events they are waiting on (like what Roblox does).
This is the responsibility of the embedder, not Luau itself.
Now this is useful, People can now use Luau outside of Roblox for their own projects. The question is: What kind of projects can we do with Luau? Is Luau as useful as Python, Java and etc outside of roblox?
sorry if this is off-topic, but I still wonder what is going on. I want someone to elaborate by what this"Luau goes open-source" thing means. Can someone explain it to me?
It’s good for embedded scripting systems, such as game engines and CAD/modeling tool plugins.
As days, weeks, years, pass… The developer community sees the need for the open-source. Many companies discourage it, though; other corporations, such as Mozilla (the creator of Firefox) and Wikipedia have embraced it… They are now successful. Now I see ROBLOX taking “steps” (for the lack of a better word) to the open-source movement.
Basically, all the inner workings of luau, the dialect of lua Roblox uses, have become free to use for everybody (on certain conditions described in the license)/
Wow, really glad to hear this! Didn’t expect this to release this year, great work Roblox!
This is very true. The Roblox client, at least on Windows, uses struct field shuffling, pointer encoding, VMProtect & other measures to make it more difficult to reverse-engineer. The public version of Luau has been run through “Rodactor”, which removes all the proprietary security measures from the code.
This topic was automatically closed 120 days after the last reply. New replies are no longer allowed.