If you call `time.Sleep()` the reported duration will reflect that call, but it's only simulating the delay. The duration of a CPU-heavy task is always reported as 0.00s.
=== RUN TestSleep // calls time.Sleep(2 * time.Second)
Real duration: 554µs
--- PASS: TestSleep (2.00s)
=== RUN TestBusyLoop // for i := 0; i < 1000000000; i++ { ... }
Real duration: 390.826ms
--- PASS: TestBusyLoop (0.00s)
PASS
The simulation is quite good: if you have multiple threads that use `time.Sleep()`, their output will be interleaved correctly. The output panel will even display the lines one at a time as if it's streaming them from the server, but in reality the entire output is received at once and the "streaming" effect is simulated on the client.
Concurrency is one of Go's core features, so it figures the playground would allow some form of concurrency even when the clock is fake.
Interesting. I suppose that makes sense, to let them speed up execution... I am a bit curious how it'd affect concurrent behavior based on time changes (e.g. if it's cpu-bound for longer than the sleep, does the wake still occur in the middle? Or does it wait to advance time until everything's blocked? What if you runtime.Yield? etc?), but that's certainly an efficient option for a public execution environment like this.
