I'm surprised Reviewable[0] hasn't come up in this discussion. It does a great job of allowing stacked code reviews and even handles rebases nicely; the reviewer sees the diff between commit #1 and commit #1' (prime = after rebase).
CockroachDB[1] has been using it since very early in the project.
I also switched my dev team to it once it grew sufficiently large (at a now acquired startup). The primary thing it enables is actually having a structured conversation about your changes, and having several _revisions_ of your changes through which the reviewer can navigate, much like Gerrit or its progenitor - Critique. Once you experience that, there's simply no going back to anything else.
The UX makes me want to gouge my eyes out with a dirty spoon, but it's still worth it, in spite of the UX. I'm baffled why MS/GitHub can't just go ahead and rip it off at this point, to replace its own utterly atrocious PR review workflow.
Controlling my terminal emulators through a browser is like managing processes with Doom: something that, while interesting and certainly shouldn't be precluded, I am unable to think of a use case where I would actually do it. Making web sockets the scripting interface for a program that in most cases you do NOT want to actually expose to the web a) makes no sense; b) is a security incident waiting to happen.
Sadly, those benchmarks (at the bottom of the thread) were done with a GCC that already included all the GCC 8.1 bells and whistles - results were unchanged under 8.1.
The downside to this solution is that the concrete option types are exported. I believe it's possible to return unexported types from exported functions, which would solve this, but that golint complains about that pattern.
In addition to being extremely precise, TrueTime is explicit about error in its measurements.
In other words, a call to TrueTime returns a lower and upper bound for the current time, which is important for systems like Spanner or CockroachDB when operations must be linearized.
In effect, Spanner sleeps on each operation for a duration of [latest_upper_bound - current_lower_bound] to ensure that operations are strictly ordered.
Your suggestion might improve typical clock synchronization, but still leaves defining the critical offset threshold to the operator, and importantly leaves little choice for software like CockroachDB other than to crash when it detects that the invariant is violated.
CockroachDB[1] has been using it since very early in the project.
[0] https://reviewable.io/
[1] https://github.com/cockroachdb/cockroach