These are all great changes; I’ve been using elapsedTime() as of late because it doesn’t do the same weird time zone shifts that tick() does. os.clock() is definitely going to make my life so much easier!
I’m still anxiously waiting for the type checker to be released in full so that I can use it in production, but I also appreciate a well-done language over a rushed one.
Particularly hoping to see more with function generics, importing module types statically without requiring that module at runtime, and having classes as first-class citizens. I can’t wait to start an upcoming project in a typed luau codebase, but the type system seems to lack a few more features for me to use it the way I want to use it. I’m hoping syntax can be added in the future if not added at release at the very least.
Well, we can’t really rename things can introduce new names and deprecate old names. In general I’m not sure this deserves a global, so at that point I’d probably bias to some set of RunService properties with descriptive names…
We’re thinking about this but nothing on the immediate roadmap. (edit oh I should mention that we’re considering structs with named fields of course see records from https://www.youtube.com/watch?v=vScM-nk5Avk)
After giving it some more thought, I am coming before you to humbly ask for an update on function generics. Namely: are they still on the roadmap for typed Luau?
Also, as Luau is formally declared a superset, can we have .luau as a valid file type in Studio for saving scripts to a file and importing them from files? It makes sense to distinguish between Lua and Luau at this point.
I completely converted my game from tick() to os.clock() with no problems. I almost always calculated time deltas using tick() to keep timing accurate even if something throttles or skips a frame, and it’s a relief to have a precise method like os.clock() that won’t lose floating point precision as we get further from the unix epoch.
I think this has broken a scheduling feature on my game. I was using r = os.date("*t", timestamp) and os.time({r.year, r.month, ...}) to get the UTC timestamp of the local adjusted time of another UTC timestamp.
But finaly a website for Luau! Wait, Luau is a new language or it still is Lua? If this is a new language, then why create a new language from another language istead of update the version of Lua?
EDIT:
Example: Syntax - Luau
Is it possible to remove the .html? Idk, it would be nice. But this is a really, really big and good update, thanks Roblox!
I know how websites and html are working, what i am trying to say is, is it possible to redirect directly without the « .html »? But its a small feature that could be ignored…
Thank you for taking the time to help me and explain everything! (Now I just hope that a DarkTheme version will be released, at least this one…)
Thanks for letting us know! This is actually an accidental mishap, which is a consequence of us upgrading our os. implementation to follow Lua 5.x. We discussed this internally and decided that we should go back to UTC.
Specifically, in Roblox:
Up until end of 2017, os.time() with a table argument assumed the specified date was in local time
Since 2018 and up until last month, os.time() with a table argument assumed the date was in UTC
Last month we changed it to assume local time zone (accidentally); this is also what Lua 5.x does.
We discussed this and feel like this should be changed back to UTC - both on the grounds of it being a regression and inadvertently breaking code, but also on the grounds of UTC making more sense, since os.time() with no arguments also works in UTC.
time() and os.clock(). They are better as they aren’t affected by float imprecision as tick is.
time() shows seconds since the game started, while os.clock() shows seconds since Lua started. This means that in Studio time() always returns 0 until you start the game, while os.clock() shows seconds since you opened the program. They don’t have much of a difference in-game though.