It should be noted that results of these aren’t equivalent:
task.spawn(function()
print(task.wait())
end)
task.spawn(function()
print(game:GetService"RunService".Heartbeat:Wait())
end)
task.wait()'s DeltaTime result will count from the time of the call, while Heartbeat:Wait() will count from the previous Heartbeat.
Also, task.delay() causes a crash instead of an error.
Is this almost like some kind of task manager for Studio?
Because you can’t do Heartbeat:Wait(2) since :Wait() function on RBXScriptSignals doesn’t take any arguments?
What is the fastSpawn pattern?
So what’s the difference of task.wait, task.spawn, and wait, spawn?
I’m still struggling to understand use cases for task.defer. I understand how it works and how it fits into the library but under what circumstances would you want code to run at some predetermined point later in time that you have no control over? Is there any real benefit in doing so?
I also don’t understand this. How is it not a replacement for spawn? And wasn’t the original fastspawn method implemented with BindableEvents? With deferred events that would mean that it wouldn’t be an immediate resumption, unless of course I’m misinterpreting the meaning of “fastSpawn pattern”.
deferred on Nevermore (originally fastSpawn)
“An expensive way to spawn a function. However, unlike spawn(), it executes on the same frame, and unlike coroutines, does not obscure errors.”
(edit: changed link to folder with README, was originally set to a release branch)
I assume for legacy purposes, old games experiences whose behavior could be compromised if they just redo the old functions.
Will documentation for task happen soon? I’d expect it to be available on the developer hub for more info and on task scheduler article on availability of a class (aka today).
Hmmm… what is happening??
Is this basically like coroutine? I mean, I am a builder, not knowing much about these, but isn’t it the same thing?
Updated my “Spawn is Evil” article to just point to the new task library. Glad that this problem finally has an easy solution that doesn’t require several paragraphs to explain!
Wanted to test the accuracy to see if task.wait has any benefits. Here’s the results of averaging the delta time of each function 20 times:
task.wait really is EXACTLY Heartbeat:Wait(), only much easier to type out. For anyone asking the differences between wait and task.wait, the answer is accuracy.
You should use defer in cases where you want to run some code after the current code has yielded, terminated, or you simply don’t care about the exact timing of it. Meanwhile the new spawn method will halt the calling thread until the thread it resumes has finished executing. So the main benefit is it won’t halt your code but will still execute almost immediately.
The new spawn method resumes a thread immediately while the old one waited a frame before resuming the callback and was subject to throttling. You can best replicate the old behavior by doing the following:
task.delay(0, function () ... end)
With deferred Lua enabled, events are deferred which is the reason for adding the new spawn method. It allows you to replicate the behavior of fastSpawn when deferred events are disabled.
Documentation will be coming soon. In the meantime you can refer to this thread.
you can do for example task.wait(1) and it will wait 1 second, and VERY ACCURATLY
Also, it kinda runs a bit faster than heartbeat < 0.0000001 nanosecond faster, and will you guys fix the problem thats its very inaccurate the first few seconds of starting the game?
This is a spectacular update!
A long awaited accuracy improvement for wait and an alternative to using coroutines and is speedier inside the call than out!
Really cool, excited for Parallel Lua!! 
Hi! Thanks for this.
As someone who uses coroutines a lot to get around the shortcomings of spawn, are there practical differences between task.spawn(f) and coroutine.resume(coroutine.create(f))? (or even coroutine.wrap(f)()?
The time returned by Heartbeat:Wait() will be the time since the last frame while the time returned by task.wait() will be the total time elapsed since that call. In other words, this is to be expected.
You can really see the difference when calling task.wait() from one of our other engine events. For example, the following will result in a much shorter yield time.
RunService.Stepped:Wait()
print(task.wait())
Not gonna lie this scared me for a second. I thought by “finished executing” you meant the resumed thread had to be dead before it returned to the calling thread but that is definitely not the case.
Thanks for clearing up the rest of it though, although I still find it hard to believe that you wouldn’t care about execution order of your code but the part about running code after the current code yields or terminates makes perfect sense.