I heard that TS is the new revolutionairy thing. Should i stop lua and d otS? can someone say the benefits of both? I dont know what i should do ts looks hard compared to lua
7 Likes
From my point of view, TypeScript is not designed for programming on Roblox. It can be fun to create games using this language, especially for the pleasure of coding something other than Lua. However, in reality, your game will always run in Lua. Roblox does not natively support TypeScript, which means that your TypeScript code will be decompiled into Lua to function. In other words, you are letting an âalgorithmâ write your code. You lose complete control of your code, and there is a risk of performance loss.
TypeScript is an object-oriented language that uses classes, while Lua does not support classes but uses metatables instead. Some may argue that creating classes is better or something similar, but it is an illusion because the decompiler will be forced to use metatables to simulate your classes. Some may claim that your code will be cleaner and more readable by writing in TypeScript. The fact is that the cleanliness and clarity of your code depend solely on your efforts in this regard.
Personally, I have no issues at this level; my Lua code is clear and clean because I have opted for a well-organized structure, and I donât feel the need to use something else to code my games. I believe itâs better to focus on Lua since it is the language that Roblox supports. You will undoubtedly achieve better results by writing your code directly in Lua instead of letting a decompiler write it for you.
Nevertheless, youâre free to choose either one and form your own opinion on the matter.
6 Likes
The benefits of roblox-ts are not always apparent until you reach a large scaled projects with a big code base. The main pro of roblox-ts is its type system, which excels above luauâs. This also allows you to use the npm package manager that opens up a wide variety of packages other than the standard Wally.
Learning roblox-ts for a small side project would be a fun challenge, but in reality if you donât have a decent understanding of how Luau works then thereâs no point. It all is transposed to Lua code anyway.
There are definitely better options for good code bases and packages that are natively written in Luau. The decision is your and itâs good to look at the proâs and conâs of everything.
4 Likes
Sorry for the bump, but I have a question.
If typescript isnât optimized for roblox, then why do few games and developers make their games on it, even if the performance is dropping?
Even 4 front page games with 50K+ players use typescript, and they lag alot
What do you mean by âtypescript isnât optimized for robloxâ? Surely if its transpiled to lua anyway it wouldnât matter as the end result would be the same
1 Like
Well, it is that each encoding and decoding process takes resources and time. Roblox engine is optimized to decode Lua to C++/C#.
With CPP and CS being low-level languages, they are reasonably and significantly faster than high-level languages. The compiling or interpreting process from Lua to cpp/cs is faster than ts to cpp/cs, as the Roblox engine is more optimized in Luau and not TS directly.
1 Like
Yeah, no.
To be clear, Roblox does NOT run TypeScript.
When you write a game using TS, you have to âexportâ (transpile) it into Luau, that the Roblox engine can then run on.
The transpilation process isnât done by Roblox, itâs on you as the user, which if youâre using a Roblox-TS library like Rojo, is as simple as hitting a few buttons.
The intent of Roblox-TS is to provide an interface for developers to write game code using a language that more explicitly supports OOP than Lua - not to natively support Roblox to run TS.
Just writing this to be clear.
2 Likes
Hm, thank you for the clarification.
Yeah, I tried to make things very short which made no sense. Adding an extra transpiring process does not make performance faster, it instead makes it slower. So, at any choice making a game based solely on TS is much laggier and slower than Luau alone.
Major disadvantage is that you wonât find that much example code/answered questions.
Youâll often have to resort to converting Luau code snippets to typescript.
Since you mention typescript looks hard compared to Lua, I wouldnât bother going for typescript. You can do the same thing in Lua, but (arguably) easier and faster than in typescript.
How does adding an extra transpiling process automatically reduce performance? The transpiling process is done outside the engine before the game is run, or even published. Regardless of whether you script in Luau or Typescript, the C++ written Roblox engine will be interpreting Luau bytecode. The engine doesnât know whether the code was originally written in Typescript.
The only thing that matters is whether the Luau code generated from Typescript code is less efficient than Luau code the user would write if they scripted in Luau instead of Typescript.
I havenât used Typescript but since someone mentioned that Typescript classes are converted to Luau metatable classes which are a common way to implement classes when scripting in Luau directly, I believe the performance would be similar. Writing in Typescript may prevent some optimization opportunities but I donât think thatâs necessarily a significant problem.
Could you explain why you said less efficient before, if you meant to say it does not reduce performance or quality or efficiency.
I was saying that TypeScript code is not necessarily less efficient than Luau code. You could write equally efficient or less efficient code for the same purpose directly in Luau.
You may have more freedom in optimizing if you code directly in Luau. However, whether the final result is slower when written in TypeScript depends on whether you would use that additional freedom if you coded it in Luau instead. If you wouldnât utilize that freedom anyway, the performance would be the same regardless of which language you use because the code is Luau bytecode for the engine regardless.
Btw even if its 1 + 1, itâs still an extra process and a thread for doing it.
While large games typically have large code and functions/events.
- TypeScript â Luau â C++/C# â Assembly Language â Binary
- Luau â C++/C# â Assembly Language â Binary
This is not the exact one, there are many more - this is just to give a basic idea behind the transpiling interrupting and compiling process.
The transpiling process is an extra add-on if you use TS and not all TS Libraries/Modules can be easily converted to Luau, and the same with Luau to TypeScript, itâs generally comparatively faster and efficient to use Luau over TS in Roblox for optimized gameplay.
Are you saying that summing two numbers is less efficient if the code is originally written in TypeScript instead of Luau? I would imagine that the Luau code for this would be the exact same regardless of whether the code is originally written in Luau or typescript.
Comparing the performance of Luau and TypeScript is different from comparing the performance of Luau and C++. TypeScript is converted to Luau before the game runs but Luau is not converted to C++ at all. The Luau source code is converted to bytecode that consists of tokens that are some kind fo constants. Luau bytecode is interpreted by code that is written in C++.
I donât know much about how bytecode is structured or how its interpretation works. But here are some examples of what a token can apparently be:
- an instruction for getting or setting something or calling a function (information for getting the variable or function is in a different token).
- a number telling the position of something in a constants array or stack array
I read somewhere that the interpreter uses switch statements to run different C++ code for each different instruction (I believe the instruction is just a number).
Addition (and any other operation) in C++ is significantly faster than in Luau because in the case of a Luau addition, the C++ code needs to not only do the addition but also interpret Luau bytecode and perhaps do some extra things.
One reason for using a language that is converted to bytecode is that it makes it easier for Roblox to limit what developers are able to do with the code. Another reason is that the code will work on any device.
Generating Luau from TypeScript takes a little bit of development time (I assume itâs just clicking some buttons), but at runtime, there is no conversion from TypeScript to Luau. But yes, if you want to maximize performance, writing directly in Luau does give you more opportunities for that.
And I donât think that Roblox uses C# for anything. C# is a high level language like Luau, not a low level language like C++.
I donât know much about this kind of stuff but this is based on what Iâve read. I think you are right about C++ being converted to assembly and assembly being converted to binary, though.
No - not at all. I meant to say even a small task is an extra work for any device.
Low-level languages, like assembly language or machine code, are faster than high-level languages because they are closer to the machine code that the computer understands. Here are a few reasons why low-level languages are faster:
-
Directly Mapped to Machine Instructions: Low-level languages are usually directly mapped to machine instructions, which means there is less overhead in translation. Each instruction in a low-level language often corresponds to a single machine instruction, making them more efficient in terms of execution.
-
Efficient Use of Hardware: Low-level languages allow programmers to have more direct control over hardware resources like registers and memory. This enables them to write code that is optimized for the specific hardware architecture, resulting in faster execution.
-
Less Abstraction: Low-level languages have less abstraction than high-level languages. This means that programmers have a clearer understanding of how their code will be executed by the computer, allowing them to make more efficient use of resources.
-
Fewer Runtime Overheads: High-level languages often have additional runtime overheads, such as garbage collection and dynamic typing, which can impact performance. Low-level languages, on the other hand, typically have fewer of these overheads, leading to faster execution.
-
Optimization Opportunities: Low-level languages provide more opportunities for manual optimization. Programmers can write code specifically tailored to the task at hand, taking advantage of the specific features of the hardware to achieve better performance.
However, itâs important to note that the speed difference between low-level and high-level languages is becoming less significant with advancements in compiler technology and hardware. High-level languages are also more productive and easier to maintain, which often outweighs the performance benefits of low-level languages in many scenarios.
1 Like
Yes, I know low-level languages are faster because of being closer to machine code. What I said is related to what you said. I may have worded it poorly, though. Iâve edited it now. What I mean is Iâm pretty sure the following is true:
- C++ addition source code results in a spesific set of lower level instructions in the compiled code.
- The C++ source code of the Luau interpreter contains code for getting the next bytecode token, and it also contains code (maybe a switch statement) for using this token to figure out which Luau operation to do. Thereâs a code path for each operation. The C++ source code path for Luau addition includes C++ addition source code. However, it may contain C++ source code for something else too such as checking the types of the values being added.
When running the interpreter, getting the token involves some low-level instructions, the switch statement involves some low level instructions, the C++ addition operation involves some low level instructions, and the possible extra things (checking types of the values being added?) involve even more low level instructions.
So a single Luau addition involves C++ addition but the Luau addition also involves extra C++ operations and thus extra low level instructions.
One of the reasons why running Luau code requires more low-level instructions is what you have in your first point. Luau bytecode isnât directly mapped to low-level instructions but is instead converted to tokens that are values in a lower-level language that lower-level code reads to figure out which other lower-level code to run.
Another reason is that, as mentioned before, even after figuring out which Luau operation to do, the C++ code path for a single Luau operation may consist of multiple C++ operations (lower-level operations) which each consist of one or more even lower-level operations.
Luau is a language run (interpreted) by another language C++, and if you made another language that is interpreted by Luau code, then the number of low-level operations for a single operation like an addition would once again multiply.
Sorry for repeating myself. Anyways, in conclusion, a reason why languages further away from machine code are less efficient is because a single operation in a higher-level language results in multiple operations in a lower-level language. However, as you mentioned, there are also other reasons that arenât related to what I said such as the extra background operations like garbage collection that arenât tied to spesific high-level operations.
Also, Iâm not sure if C++ should be called a low-level langauge since itâs an abstraction over lower-level languages. I just felt like itâs ok to call it a low-level language because itâs lower-level than Luau and itâs compiled to an even lower-level language.
1 Like