Kinda looking forward for type functions and new voxel grid system still
It’s a shame it got delayed though, the lighting system is still a burden to deal with after so many years.
There are still goodies around that I’m waiting for regardless (like new explorer which is apparently faster than qt explorer? 
)
Also, I wonder why there’s some propagation between selecting category and options actually showing up in next-gen studio ribbon, but in Start page that is not a thing? Is start menu more optimized than ribbon?
tl;dr: there’s an immense amount of hubris involved in asserting that you, as a third-party observer, know more about the performance characteristics of the software than the engineers making these decisions are writing.
There is a huge difference between the performance between an interpreted and compiled program. There is a huge difference between the performance of a garbage-collected procedural one and an RAII object-oriented one. There is a huge difference between a language made to run on bare metal and a language made to script lego games .
The engineers working on Studio are, in fact, extremely familiar with writing code in an “RAII object-oriented language,” (they’ve been doing it professionally for years!) and they’re in a much better position to make a statement about what software they’re writing will be more or less performant based on various choices they can make than you are as an entirely external observer.
Many of the assumptions you’re making here about language design and its impact on performance are ill-informed. For instance, you highlight “procedural” and “object-oriented” as points of comparison between Luau and C++. In fact, conventional object-oriented code relying on inheritance has a direct and not insignificant overhead in memory utilization, performance, and cache behavior because it typically introduces virtualization that requires an additional layer of indirection. Ordinary procedural code does not pay this cost.
You’re also making an implication here that RAII is somehow guaranteed to be superior to a garbage collector. This is also not true. RAII has some particular advantages over GC in real-time contexts, namely that deallocation is guaranteed to happen at particular program points syntactically, but it also has distinct disadvantages. The most notable of which is safety, of course, where you can trivially trigger memory unsafety by making mistakes around memory management in C++ that is systematically prevented by a garbage collected language. You’re clearly more interested in performance over safety though, so I imagine you’ll disregard that disadvantage, but it absolutely plays a significant role in the decision here. On the performance side, by deallocating at the earliest program point, you’re likely guaranteeing that lots of deallocation work happens during the frame time. By contrast, in a garbage collected language being run as part of a larger system, you can use specific knowledge about the system to move where garbage collection happens. One of the major performance gains browsers have made with JavaScript, for instance, is moving the garbage collection for their JavaScript engine into parallel execution with the rendering step, completely eliminating the dependency between deallocation and frame time.
Finally, you make some assertion that C++ was “designed to run on bare metal” and that Luau was made to “script lego games,” which I imagine is based on a misunderstanding connected to your opening statement about compiled versus interpreted programs. I’m sure this will sound really pedantic, but it’s useful to understand the full process end-to-end. The reality is that C++ is implemented against an abstract machine model (typically called the C++ abstract machine) which a compiler (such as clang or gcc) transforms into a different abstract machine model (e.g. the AArch64 or x86_64 ISAs). These machine models are then dynamically translated into microcode instructions at runtime for the particular CPU’s microarchitecture to execute. For Luau, the Luau program is implemented against an abstract machine model (essentially your “mental model of Luau”) which a compiler transforms into a different abstract machine model (called the Luau virtual machine). From there, it can either be executed by a program (called the Luau bytecode interpreter) that executes bytecode instructions essentially in terms of the C++ abstract machine, or it can be compiled further down to the same abstract machine models other compilers are targeting (i.e. the AArch64 and x86_64 ISAs) where it will… again be dynamically translated into microcode instructions at runtime for the particular CPU’s microarchitecture to actually execute. The reason to explain all this is to point out that, fundamentally, the translations rely on abstract models of computers at every level for every machine. There’s nothing intrinsically bad about “interpretation” (in a literal sense, the hardware is an interpreted for its microarchitecture), and Luau relies very heavily on compilation to achieve good performance, just as C++ does.
I’m tired of people in the software industry using design choice and hardware advancements as an excuse to write programs that blatantly waste 90% of processing power. The Windows 95 installer was only 1.7 MB, and now we have Google Calendar at nearly 200 MB. It’s actual insanity, and now we’re replacing C++ with Lua because it doesn’t matter!
It’s certainly your value judgment to make if the processing time is wasted, but your attribution of this blowup to language choice is deeply mistaken. Look at the size of every Windows version, and you’ll notice they all increase, despite the OS and its bundled programs continuing to be written in C++. The language choice is not the issue here. Not for processing time utilized, nor for memory utilized. The reason for this “insane” blowup is a massively expanded scope for what computers are expected to actually do. Even for what seems to be “simple” programs, there are significant expectations around support for localization, text-rendering in CJK scripts, right-to-left text, etc. Our desire to have computers do more, and do more correctly, has a much greater impact on the real cost of software than whether people use one language or another.
29 Likes
Why on earth is ROBLOX limiting search results under 70? Incase you forgot ROBLOX there are more than 70 games in each category…
Do you guys really think that’s a good idea? I thought the goal was better discovery not destroying it?! Was this even announced before you did it without telling devs?
6 Likes
I didn’t know a piece of criticism would be so largely rejected by many. But to keep the validity of my standing, I’ll try to respond.
There is so so much I could go into detail about how different the speed/size/whatever of compiled Luau is going to be in comparison to compiled C++. Lua, being a scripting language, utilizes 100% of the heap, carries at runtime a tag of every value’s type, has support only for 64-bit floats, always hashes strings, interfaces with the VM for library calls and garbage collection, etc.
In comparison, C++ can store values on the stack or CPU registers, keep typechecking at compile time and supports multiple fine-tuned ways to represent numbers, strings and data structures. There is no way you are arguing that Roblox made in 4 years a comparable language to an internationally contributed language with work from the smartest minds of our time with 24 years.
Faster than what? You didn’t compare the difference between C++ and Luau, you just compared Luau to NodeJS and air. I concur with @AdvancedOpenGL that this doesn’t even argue anything.
Are… are you seriously comparing filling an array with an iota to some random unnamed engine process? Your results even show that Luau doing that allocation takes half the time it takes to render a widget! That’s clearly worse.
Well, yeah, I’m the client of the product. I kind of experience drastic changes like these in performance. If the software I use is becoming increasingly sluggish, I have the right to criticize the people behind it.
I will not–cannot–accept that this is the opinion of someone with a computer science background. Software interpretation is slower, period. Adding more and more abstraction over another isn’t negligible, its negligent.
Well, I expect that from Microsoft. They’re being filled with bloat and spyware. From a calendar though, is highly alarming.
And believing language choice isn’t the issue is the issue here. We’re being conditioned that abusing hardware for the sake of having an easier job and doing more is actually good. Imagine how destructive an aircraft engineer or building architect having the same disposition would be. Yet that’s the norm for modern software development.
Then why doesn’t it feel faster? I’ve tested the Luau version with FastFlags and its noticeably sluggish compared with the Qt one (not to mention highly unstable).
How can you even say this if it isn’t deployed or even finished yet?
Look, I know what you are all thinking. Why do I think this is a such a big deal? Certainly, I don’t think having a slower widget explorer for a video game editor is going to be the end of the world, but the statement “Replacing C++ with Luau will make it faster” absolutely ticks me off. To me, it’s the culmination of everything I hate about modern computer science and society’s view of it, and that is progression is always good no matter what.
I want to fix that; I care deeply that this gets fixed. I’m studying compiler philosophy and trying to brainstorm new ways to solve the major pain points of memory management, program validation and programmer comprehension. I’m working on implementing a dependent value-based typesystem that solves a multitude of safety and performance problems, and I truly believe it could be revolutionary. But for how it is now, seeing a huge Silicon Valley company disregard the merit of that all on flimsy principles is highly disheartening.
1 Like
Uhh, maybe yall should not refer to Server Authority with acronyms. 
I will not–cannot –accept that this is the opinion of someone with a computer science background. Software interpretation is slower , period. Adding more and more abstraction over another isn’t negligible, its negligent .
Hi, I have a PhD in computer science. Rudely suggesting that I don’t have a background in computer science (or that I’m stupid for making a point about a subject in which I am definitionally an expert) while calling the point I’m making a “nothing burger philosophy of programming” is not appropriate.
The performance penalty of interpretation varies heavily depending on what you’re interpreting and how, and it is not fundamentally doomed to be this thing that is insanely slow. The humans writing software are also operating under constraints including both expanding demand for features and a need to keep all of the context of the program in their head while they’re working on it (which is, in fact, extremely important for the performance and correctness of the product they’re building). The cognitive load of building complex UI in C++ is extremely high, especially if you try to do so while caring about performance. The people who have done this professionally know this very well. The widescale adoption of tools that you happen to not like is not a product of everyone other than you being an idiot, and I think you should consider that when thinking about why the response to your comments were entirely disagreement.
I’m working on implementing a dependent value-based typesystem that solves a multitude of safety and performance problems, and I truly believe it could be revolutionary. But for how it is now, seeing a huge Silicon Valley company disregard the merit of that all on flimsy principles is highly disheartening.
Based on the attitudes you’ve held so far, good luck with that. I’ll eagerly await you showing the world how much smarter you are than everyone who has done programming languages research for the past 60 years.
31 Likes
I’m especially excited for this when it comes out! Dynamically switching this stuff out would make changing my UI so so so much easier.
3 Likes
The problem with Luau performance on Roblox isn’t Luau itself, it’s the bridge from Luau to the engine. Reading instance properties is slow. Writing to instance properties is even slower. Luau itself is an exceptionally fast language and they only continue to make it faster, but even something like writing a couple of properties every frame just eats up frame time. This is the struggle I’ve had with the engine.
2 Likes
YES! Text chat will be coming to console! Will we be able to choose the keybinds for it and add hold durations? If we can’t make it like call of duty’s, you have to hold the select button down for a few seconds then you can chat. And will we be getting voice chat?
3 Likes
I would like to go against that, as things like Vector2int16 exist. And im pretty sure there are bit libraries on rblx now
Why do you think they put is as an FAST FLAG and not an beta feature? Also it feels like you are just trying to notice it as sluggish, Some of my friends, who build a lot, They need to interact with the explorer a lot, (dragging, reparenting, welding stuff), and they have noticed no difference in performance. They have been building for 4+ years, and they have noticed no performance differences.
Apparently 5 other clients are perfectly fine with the current product. Roblox development does not revolve around you, and criticizing being rude to multiple rblx staff members, wont make them be more likely to change the entire language of what studio runs on from luau to c++
5 Likes
Ah thats great to know, thank you!
1 Like
It wasn’t mentioned in the delays so I’m guessing it’s on track. There have been a couple previews of it as well.
2 Likes
I am sorry that you got so rapidly dogpiled here. It isn’t my fault, but I’ve been there and it doesn’t feel good. I hope that your day is going well despite it, haha. I think the take away is really that people just feel strongly about software, which isn’t new information. As a fun experiment, ask a programmer group about variable casing (snake_case is best case).
That said, you should probably learn more about Luau if you’re going to make the claims you’re making. A lot of them (such as “Lua[u] utilizes 100% of the heap”) are verifiably untrue and they undercut your point.
7 Likes
Hey @index_self
Looks like I got off on the wrong foot and want to sincerely apologize for my responses.
As you can see I can get really passionate about these topics that are near to my heart but that should not be an excuse. I should have done a better job at listening and understanding your points, and communicating about that.
Once again, I’m sorry for how I responded.
15 Likes
I’ve seen so many terrible, blatantly AI audio assets uploaded by the DistrokidOfficial account. Is there going to be any change to this?
1 Like
I appreciate your feedback. We’re discussing how to make Custom Logging happen in 2025. Just to confirm, your main needs are:
- The ability to change the log level and have it affect output with tags.
- Including stack traces or locations where errors occur, using call information.
Let us know if there’s anything else we should consider.
4 Likes
Pretty much, we should have control over the stack traces and should be able to exclude certain information, if I have an Error module that logs an error with more details about why it happened, I should be able to leave out the error module’s stack trace from the logs.
3 Likes
Yeah, I know a few of my favorite artists use DistroKid but none of them are on roblox, only the AI slop is
1 Like
The main thing I want is for us to be able to use licensed music again, as don’t get me wrong the music you guys have been providing is great and all but nothing hits harder than being able to use our favourite songs for our experiences.
4 Likes
Oh what’s up?
Wait,isn’t it already always summer? Maybe i’m in a country whose fall is always summer,like brazil.
Umm…what is it?
Finally! We got to get gamepad emulation! I’m so happy with it!
Meh,I’d rather do it myself…
…
Oh,what bugs did you fix since you updated that roadmap?
Oh,what is it?
Oh,these changes could mean i can return to development right now. But those ain’t exactly neccesary.
Oh…what is it?
Did we already could update our experiences?
Finally! Distrokid! But what’s that? Some sort of linux distro for kids?
I don’t need to,sorry…
Okay! 
This is fun,but what if the music doesn’t require rights or is probably unauthorized? Does it mean you cannot upload it to roblox?
You’re thinking you can bring Goanimate grounded videos to Roblox? It uses TTS voices.
Oh,so sad,we can’t get that R6 to R15,do we? People hates this feature and they claim and believe it will break games…
Anyways,I had to cover the important things after i readed all the roadmap fall 2024 edition.
Thank you for those improvements,Roblox!
1 Like