That makes less sense – they are not meant to denote logical operators. It’s to denote type unions and intersections.
8 Likes
yes but it is convenient, and developers who might type || instead of |, it also teaches you something about another language in a way.
That aside, these updates have been awesome! Continue has been a dream for my insane iteration habits, and so have the performance gains 
Out of curiosity, which is faster when checking for nil (assuming x is not false)? Do type annotations change the performance of these checks?
if x then print("Not null!") end
if x ~= nil then print("Not null!") end
36 Likes
I love that you guys just built your own interpreter and made it so much better. That’s some serious engineering commitment. Everyone benefits from this, including the players.
15 Likes
Any updates on multithreading?
10 Likes
Hooray for Luau! However, I’m quite upset that I’ve gotten no word from staff about this 100% reproducible studio crashing bug that occurs with the “Script Analysis” beta feature enabled, even though it’s been well over a month since I reported it.
2 Likes
Amazing recap! Cant wait to see what improvements are going to take place. A great work for those people who work on that!
Also big F for LoadLibrary.
1 Like
We’re actively looking into this bug, but it’s a bit non-trivial to resolve.
6 Likes
Also another question! Here’s my current code for classes within the type system:
--!strict
type MyClass = {
foo: string,
speak: (MyClass) => nil
}
local MyClass = {}
function MyClass.new(foo: string) => MyClass
local self = setmetatable({}, {__index = MyClass})
self.foo = foo
end
function MyClass:speak()
print("Bar bar",self.foo, "!")
end
local ins: MyClass = MyClass.new("hello!")
ins:speak()
It might be more ergonomic if parts of the class type could be inferred somehow. I’m honestly not sure how you’d pull it off, but is stuff like this under consideration?
4 Likes
I’d expect if x to be a bit faster. We have a pending optimization in backlog to optimize comparisons with constants a bit better. Type information currently doesn’t affect code generation.
3 Likes
&& is also a double address operator in C++. That has nothing to do with learning another language, it just pushes false sense of familiarity which can result mistakes that are hard to find.
5 Likes
Agreed, but it’s just something that shouldn’t happen. I shouldn’t have to go and disable type checking, restart studio, reopen the level, make all the necessary changes to the script I’m using, enable the beta feature AGAIN, restart studio AGAIN, then reopen the level AGAIN every time there’s an update to the script just to stop studio from crashing.
1 Like
I never got to know LoadLibrary ;(
3 Likes
I’m sorry for being quite confused but is Luau basically another language that’s going to be used for ROBLOX?
Does this mean that ROBLOX programmers will have to change their ways of scripting and learn the next prefixes and syntax?
I’m just quite confused because I’m not sure what’s going on.
2 Likes
Luau is still Lua. It’s just the internal name for the new implementation of Lua they’ve made. You won’t have to worry about learning new syntax, unless you care about type annotations (essentially, there will be a new syntax for adding what type a variable is and what a function returns).
I assume this means the automatic importing of types via require, or is there some other support that I’ve not noticed?
Also, is the syntax for typed Lua considered stable (only additions, never changes or removals) or should we hold out on using it for serious work still?
4 Likes
This is a great recap! 
Nice job.
1 Like
Now that’s a quality update, thank you guys for this amazing update!
1 Like
This hasn’t shipped yet; once it will ship require will automatically import types but the import is namespaced, that is
local Foo = require(path.to.module)
Will make it possible to refer to types in that module as Foo.Bar. And, importantly, will actually mean that the Foo table itself has a correct type so that we can typecheck access to that table and use of the functions declared within it.
6 Likes
Super excited with all the work being done on Luau. It’s fun watching a language be adopted for Roblox’s specific use-cases and challenges.
I, and many other developers, do some things to require by name instead of direct path, sort of like how npm modules load by name. This has never been directly kosher, but it really helps simplify refactoring codebases.
Is there anything on the roadmap to provide to Roblox Studio how these modules are resolved, or should we expect this sort of different resolution system to never be supported? Does Roblox have a new module resolution system in mind besides direct pathing?
8 Likes
All I meant that it is used in a lot of other languages and it would be nice to see it in luau too.
1 Like