It’s a spelling habit, at the end of the day how it’s capitalized does not affect the product.
Why are PR requests and issues publicly disabled in the repository?
We had to temporarily disable repository interaction for non-contributors as we figure out the issue moderation process.
6 Likes
will this make it easier for people to exploit? i feal like this could open up the possibility for more exploits. be careful with this. the last tihng we need is ore exploiters, its hard enough to keep them off your game already.
It’ll be easier for both developer and exploiter, to either fix exploits or make exploits, so it’s technicallly a win win for both sadly.
(post deleted by author)
1 Like
Not really. Exploits ran fine, even without using Luau. At most they might have typechecking now, but it won’t change much.
1 Like
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!
5 Likes
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!
6 Likes
Is the script Becoming safe for use?.
1 Like
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.
2 Likes
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).
3 Likes
You could just do
task = task or {
spawn = function(f, ...)
coroutine.wrap(f)(...)
end
}
1 Like
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)
2 Likes
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.
6 Likes
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.
3 Likes
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.
3 Likes
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?
2 Likes
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?
2 Likes
It’s good for embedded scripting systems, such as game engines and CAD/modeling tool plugins.
1 Like