Luau Recap: June 2020

[AwesomePossum212]

@zeuxcg

Compound assignments

A long-standing feature request for Lua is compound assignments. Somehow Lua never got this feature, but Luau now implements += , -= , *= , /= , %= , ^= and ..= operators.

This is amazing. There has been so many times where I have had to do something like:
workspace.Userdata:FindFirstChild(player.Name.."_Data").Money.Value = workspace.Userdata:FindFirstChild(player.Name.."_Data").Money.Value + 1

And I always felt like it was taking forever having to type out THE EXACT SAME THING TWICE (and repeating the action increases the chance of misspelling or otherwise messing something up). Now my code can be cleaner with only having to type:
workspace.Userdata:FindFirstChild(player.Name.."_Data").Money.Value += 1

@zeuxcg

tick() sounds perfect - it has a high resolution (usually around 1 microsecond), and a well-defined baseline - it counts since UNIX epoch! Or, well, it actually doesn’t. On Windows, it returns you a variant of the UNIX timestamp in local time zone. In addition, it can be off by 1 second from the actual, real UNIX timestamp, and might have other idiosyncrasies on non-Windows platforms. We’re going to deprecate this in the future.

I remember seeing a recent discussion on how it could be inaccurate, so it’s great to get some more info on how tick() works.

[zeuxcg]

@Ruben_Zanzus

Will the keyword tick() get completely deprecated or is the function itself going to be replaced/rewritten? (No need to edit any scripts that use tick() ?)

For us usually “deprecated” means “it works but the use is discouraged”.

For hourly reward systems, the use of os.time() is likely more appropriate. tick() on Windows is time zone specific, which means that if the user plays the game from two different time zones in the single day you may see some strange results from this.

edit ah, and also it’s different between Windows and other systems, so if the same user plays the game on desktop and mobile the resulting times are going to differ. All of this is likely not too critical for your use case, but the point of deprecating this function is that it has incredibly strange behavior that nobody actually wants. Of course games using it will continue to work just as they do today.

[nooneisback]

The github post has a small error. You forgot to add p:Point instead of just p. Right now p.z will not error. (at least it shouldn’t)

[ReturnedTrue (Tr_uth)]

@zeuxcg

Optimize typeof() to run ~6x faster. It used to be that type() was much faster than typeof() but they now should be more or less comparable.

Is there any reason to use type() nowadays? The only use I can find is that if you need to check it was a userdata for some odd reason.

(Sandboxing Page)

debug. library has been removed to a large extent, as it has functions that aren’t memory safe and other functions break isolation; the only supported functions are traceback and getinfo (with reduced functionality).

We also have profilebegin/profileend

Props to the people working on this! Luau is becoming seriously awesome.

[Automationeer (Eleanor)]

Please note that at this time we are not ready to make Luau implementation publically available in the source form. Right now the only interface to Luau is the Roblox engine (exposed in Roblox game client/server and Roblox Studio).

Is there (even the very unlikely chance) that Luau will ever be open sourced anytime in the next year or two?

@zeuxcg

thanks […] @zeuxcg!

[Quenty]

Ok. This system clock is confusing me, so I want to clarify some things. For context, I use tick() for everything right now, including computing spring deltas for updating a UI element.

Is this grid accurate?

The implication is I should use os.clock() or time() for EVERYTHING, unless I want stuff to synchronize with the game time. I’m ok with clocks running backwards if my clock doesn’t lag, although maybe that can create stutter?

Can you tell me if:

• time() lags if simulation lags
• time() is 1:1 with real time, or would disconnect?
• What is time()"s resolution?
• What does “stable baseline” mean in reference to os.clock()? Does os.clock() run backwards? Does it drift over time?
• Does calling any of these methods have performance implications?

[zeuxcg]

os.clock() isn’t relative to anything in particular. I think your table is correct otherwise? time() indeed reflects the simulation time so it’s not a good solution for UI animations :-/

edit ah, no, time() baseline is wrong in the table - time() actually starts when the game starts (which is important! on mobile this means it’ll start when the user hits Play, not when they started the app)

This is a surprisingly complex topic

[zeuxcg]

@Quenty

Can you tell me if:

• time() lags if simulation lags

Yes.

• time() is 1:1 with real time, or would disconnect?

It’s 1:1 with simulation time, so it can disconnect. It’s good to use when you’re using it to model simulation of your own objects.

• What is time()"s resolution?

It’s advanced every frame by the precise amount of time (~microseconds) it took to complete the last frame, but note that it’s actually the same during the frame - which is good for simulation because this means you can use it in multiple scripts and have a consistent simulation behavior

• What does “stable baseline” mean in reference to os.clock()? Does os.clock() run backwards? Does it drift over time?

It just means that you shouldn’t assume that “0” in os.clock() timeline means anything. It should be monotonic, which means that whether it drifts over time or not is, uh, dependent on your definition of drifting (drifting from what?)

• Does calling any of these methods have performance implications?

time() and os.clock() are pretty fast. os.time() might be a touch slower? I wouldn’t be hugely concerned with this unless you call either in a tight loop.

[Dekkonot]

The description of hex escapes on this page is incorrect; the syntax is \xAB, not \0xAB.

Otherwise, this seems like… a description for a github repo, not just for us. Specifically, the details on sandboxing and embedding Luau give me pause since it reads like a pitch for using Luau and explanation of it…

I don’t have anything specific to say about this thread beyond “thanks for the website” though. I’ll spare you running commentary as I read through it.

---

It’s common in Lua for function arguments or other values to store either a value of a given type or nil; this is represented as a union (number | nil), but can be specified using ? as a shorthand syntax (number?).

Was this ever properly announced anywhere or is this just on the website?

[Quenty]

Excellent information! Thank you! I’ve had several discussions about what exactly to use, so this is very good to learn!

A few more questions:

• I’m hearing that I should replace all my tick() calls with os.clock() calls! Does that seem right?
• Is time() good for clock/spring steps in cameras? I think maybe using that would fix some issues with animations.
• Is time() the same as RunService.Heartbeat() and RunService.Stepped()'s dt?
  • Can I avoid using these parameters, and just use time() instead, if I wanted to?

Does this updated table look correct?

Thank you so much, this is very interesting.

[zeuxcg]

@Dekkonot

The description of hex escapes on this page is incorrect; the syntax is \xAB , not \0xAB .

Thanks!

@Dekkonot

Otherwise, this seems like… a description for a github repo, not just for us. Specifically, the details on sandboxing and embedding Luau give me pause since it reads like a pitch for using Luau and explanation of it…

As noted the site serves both Roblox developers who want to be up to date on what Luau can do, and also as an information portal to answer “what, why, how” questions about Luau vs Lua. Also Roblox community tends to be very technical and curious so the extra detail hopefully doesn’t hurt either! No comments other than this

@Dekkonot

Was this ever properly announced anywhere or is this just on the website?

We supported this from day 1 I believe, but I don’t recall if this was described in the original type checking beta post. This is part of the motivation to have the web site

[zeuxcg]

@Quenty

• Is time() good for clock/spring steps in cameras? I think maybe using that would fix some issues with animations.

Probably not, because this would mean it slows down when physics starts to throttle. For this the ideal case for us would be to expose a time value similar to game time (which is what time() returns) that’s a consistent render time synced with RenderStepped…

Although we have pretty bold plans re: physics simulation that may affect this. For now I think os.clock() is an adequate replacement to tick() for anything that doesn’t need the “almost UNIX timestamp” characteristics?

Is time() the same as RunService.Heartbeat() and RunService.Stepped()'s dt?

time() isn’t a delta time, but it should be the same as the first argument to Stepped.

[TheBristlefrost (Bristlefrost)]

Why does the “view project on GitHub” redirect to 404? Might want to fix it or even better make Luau open source, I would love to use Lua + static types in my external backend for my Roblox game.

[J_guar515 (Jaguar_515)]

The Luau repository is private, and Luau’s implementation isn’t ready to be publicly available in it’s source form yet, as said in the Open Source section of Why Luau?

Please note that at this time we are not ready to make Luau implementation publically available in the source form. Right now the only interface to Luau is the Roblox engine (exposed in Roblox game client/server and Roblox Studio).

[zeuxcg]

We don’t generally oppose syntax changes, however syntax changes are the highest impact changes to the language and as such they deserve a lot of scrutiny. For example, syntax that provides an alternate method to spell something without significant readability / performance improvements might not be a good idea. There’s no clear cut rules here, here’s a snippet from an internal discussion we’ve had on this topic a few months ago with my comments:

To answer the “frequency” question, I checked our Lua codebase - out of 530K lines of code, 1536 lines of code match the pattern “foo = foo op bar” (for op representing any proposed operators). Compared to that for example, ‘break’ occurs only about 280 times.

The “where do we stop” question is valid. I don’t know if I have a comprehensive answer to this. My general view is:

• If a feature is standard in modern languages, this adds feature points
• If a feature makes the language easier to use or more ergonomic, this adds feature points
• If a feature unlocks singificant performance advantages, this adds feature points
• If a feature makes code harder to read or understand for people who aren’t experts, this subtracts feature points
• If a feature makes code more ambiguous to visually parse or makes it easier to introduce errors in the code, this subtracts feature points
• If a feature has backwards compatibility implications, we can’t ship it

I don’t think that we should adopt the stance “if it’s not in Lua we shouldn’t add it”, but of course the stance “it’s in language X so we should add it” is harmful as well. Speaking of syntactic features that don’t represent the type annotations, so far we’ve added two:

• continue - this is standard in programming languages and makes Lua a bit more ergonomic
• binary literals and underscores in number literals - this is not standard in programming languages, but modern languages generally have this, and it’s easy to explain and makes numbers easier to read

There was one feature we’ve talked about which is standard in all programming languages, but we haven’t added it yet because of ambiguity concerns, which is “return inside a block” (it makes it much more ergonomic to test changes in the code, right now you need to use do return end which is a poor workaround). These concerns don’t make this change backwards-incompatible, so we can ship it, but so far decided not to.

I’m not sure if there are other considerations to apply. I agree we shouldn’t add syntax (or semantics!) blindly, but I don’t know that this gives any guidance to how we actually pick syntax we do ship.

Hopefully this helps. We will add new syntax if we decide that it’s really impactful, but we won’t add new syntax just because language X has it or just because it seems like a neat idea.

On constants, there’s some information here https://roblox.github.io/luau/compatibility.html#lua-54. We may pursue this but it currently doesn’t have substantial upsides, and it’s not obvious that one more way to declare a local is a good idea. There’s probably a long way before this in establishing mutability constraints within the type system.

edit oh, the “feature points” in the comment above are in reference to an excellent Negative 100 Points - Strongly Emergent (unfortunately the original article has been lost when MSDN blogs were discontinued).

[AxisAngle (AxisAngles)]

A lot of this is really exciting! Thank you so much for all the work you have been doing on increasing usability and performance.

How would you feel about renaming time() to simulatedTime() or simulatedtime()?

Also, are structs in the pipeline?
Ideally these would get the same performance:

function add(
	a1, a2, a3, a4, a5, a6, a7, a8, a9
	b1, b2, b3, b4, b5, b6, b7, b8, b9
)
	return
		a1 + b1,
		a2 + b2,
		a3 + b3,
		a4 + b4,
		a5 + b5,
		a6 + b6,
		a7 + b7,
		a8 + b8,
		a9 + b9
end


type structType = [
	[1]: number;
	[2]: number;
	[3]: number;
	[4]: number;
	[5]: number;
	[6]: number;
	[7]: number;
	[8]: number;
	[9]: number;
]

function add(A, B)
	return [
		[1] = A[1] + B[1];
		[2] = A[2] + B[2];
		[3] = A[3] + B[3];
		[4] = A[4] + B[4];
		[5] = A[5] + B[5];
		[6] = A[6] + B[6];
		[7] = A[7] + B[7];
		[8] = A[8] + B[8];
		[9] = A[9] + B[9];
	]: structType
end

[DataBrain (Amber)]

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.

[zeuxcg]

@AxisAngle

How would you feel about renaming time() to simulatedTime() or simulatedtime() ?

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…

@AxisAngle

Also, are structs in the pipeline?

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)

[devSparkle]

Secretly more excited for this than any other update.

That being said, since you’re basically overhauling the language… can I get a continue?

[Dekkonot]

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.