With the beta feature enabled, Studio seems to reliably crash whenever it tries loading my game. Said game consists of 2 places (though it crashes when trying to enter the game at all, in the start place) and has team create enabled, if any of that is relevant. When type checking is enabled, this crash always happens and I cannot load the game. When type checking is disabled, this doesn’t happen at all.
This particular time it seemed to persist a bit at the loading game screen before just giving the standard error prompt and closing.
I uploaded what I think to be the log file generated during the crash, though I’m not completely sure it’s the right one. It’s probably not necessary at all, but I also uploaded a screenshot of the window’s state before the crash in case me describing it isn’t clear.
We have disabled parsing of type annotations because of this; the release of Studio tomorrow will temporarily deactivate as as we clearly need to find a backwards compatible syntax for this.
In general, our desire is to find the solution that provides a smooth transition path for developers who only know Lua and/or have a lot of existing Lua code. A completely new language forces you to rewrite code in that language to get benefits from this, whereas with Luau types you can choose yourself to add as many or as few or no type annotations as you would like.
Additionally integration of a new language is not straightforward from many axes, including fragmentation of community (does this mean people can no longer share code with each other if they use a different language?), interoperability between modules inside Roblox (can I use your module if I use Lua and you don’t?) and interoperability with modules outside of Roblox (as nice as Roblox-TS is, you will not be able to run existing TypeScript code using it - so not all benefits of adopting a mature existing language apply).
There are other challenges with “standard” routes, e.g. TypeScript route makes it much harder for us to use types to improve performance.
A new language would be more easily accepted by the community if there were tools to convert it to and from Lua. Lua would remain a simple language that’s easy for young developers to understand, and a new language would be easier for advanced users to write/maintain, and allow for intuitive access to previously impossible optimizations.
I don’t know what path is best, it depends on the language/syntax specifics, ease of maintenance for Roblox engineering, and whether our games will actually run faster.
All of those reasons make total sense. Thanks for the response. From a community management perspective, I now understand why supporting a second language would be a large hurdle. Best case scenario, it would be great to see the changes to Luau be available outside the Roblox platform. I’m excited to see the new things to come; keep up the good work!
I’m not sure how advantageous the tooling angle is unless you can reach semantical parity, and it’s really hard to do this. For example it’s unclear how you convert between JS and Lua in either direction while keeping the code readable and performant - existing tranpsilers I’m aware of drop at least one of (comprehensive feature coverage, readable output, performant output) to work.
We’ve evaluated all of these tradeoffs a while back and decided that we want something that doesn’t exist right now, which is what we’re building. On a technology level it will hopefully be superior to alternate options once we’re done (we’re not done yet!) along the axes we care about.
This doesn’t mean we will never consider alternate languages - depending on the methodology and what exactly is the angle, it may be a viable approach - clearly for existing languages there’s some space between “integrate a fully compatible implementation” (e.g. embed your favorite JavaScript engine) vs “transpile with a lot of restrictions” here (demonstrated by Roblox-TS, you get good interop for it and you can do it externally to the platform).
Why not make a property on SourceContainers that enables type-related syntax, which is true by default? That way, there won’t be any compatibility issues with old code at all, since they will have the new syntax disabled, and you can add as much new syntax as you want (specifically, new keywords that are kind of important for a type system).
Our plan is to enable the type-related syntax by default because this minimizes the divergence between syntax between different script sources. We really don’t want to create multiple incompatible dialects of Lua, we just want to create one that is compatible with code people have been writing on the platform for 10+ years.
For example, you need to be able to copy source between different files and still have the code run.
The --!strict part in particular would still affect ability of the code to type-check, but this doesn’t impact whether the code can run - only whether in Studio or other contexts where type checking is ran you get warnings.
We might introduce alternate ways to enable strict mode similar to what you’re proposing later, but crucially strict mode only affects the mode the type checker runs in - which types it infers and which constructs it complains about - not anything else. The syntax should apply everywhere.
And yeah, unfortunately it makes our lives harder. But compatibility is worth the price.
What exactly does the type checker do when not in strict mode and you pass the wrong argument type to a function? I don’t see anything happen in studio.
From what Zeuxcg has said so far, it seems like the team is planning to optimize Luau to take advantage of types (faster Lua execution thanks to types). If I’m not mistaken, Zeuxcg’s 2019 hack week Luau JIT experiment ran faster with some sort of type checking implementation.
Woah. O_O
There is only one word to describe something like this.
Dope.
I didn’t even know that anything like this was in the works! Also, if someone else is more familiar with typescript, please tell me he is making a custom class with this line right here?
The main issue with Lua is that it’s impossible for a compiler to know what the majority of your code will do before execution. This is why vanilla 5.1 only does some basic optimizations like simplifying maths, while LuaJIT only optimizes the code in specific instances. A major culprit of this are 100% type unsafe variables, since a parsed value can be a number or a boolean, a reference or a primitive. For example, if val then end will run if val is anything but false or nil.
but when are we getting compound operators?
its literally in every programming language besides lua, dont even mention that its supposed to be “simple” and not complex, because this post clearly shows that simplicity isnt really relevant anymore.
if you dont know what im talking about, it is operators like ++, --, +=, -=, *=, and /=.
code like this:
local a = 5
local b = 3
a = a + b
print(a)
can be shortened to this:
local a = 5
local b = 3
a += b
print(a)
it just gets more and more useful the longer the two values you are trying to add together are…
I don’t think I said that exactly. I don’t think we are going to ever add ++/— because of syntactic ambiguity. As for += et al - we don’t have this planned right now. Because of complexities with metatables if we ever add this, this would just make the code shorter, not faster. But maybe we will decide it’s worthwhile - ergonomics are important and we’re adding continue for this reason. If we ever add += et all these would be statements though unlike in C-derived languages.
I would think that you just dont reassign the variable? I dont use C# or C++ so I have no idea of any other advantages of using constant instead of just not updating the variable
The advantage is that you know for sure that the given variable never changes. In Javascript I often see the phrase “Reduce Immutable State” thrown around and so that is done by using the const keyword.
that is compatible with code people have been writing on the platform for 10+ years.
