3 ms·

I was persuaded by the proposal. Do you still prefer directly exposing the monotonic clock? If so, why?

• justinsb 10y ago
  Simply that the proposal is complex and involves subtleties of behaviour, and I worry that there may be further unexpected consequences found later (like the equality surprises). I do think that the proposal nicely works around the problem of back-compatibility for the APIs which were using a time.Time instead of a time.Duration. But: I expect that many of the uses of time.Now to measure elapsed time were accompanied by a comment along the lines of "// TODO: use a monotonic clock when go exposes it". I see little harm in exposing `time.MonotonicNow` or similar, in addition to these changes, particularly as this is what the original github issue requested: https://github.com/golang/go/issues/12914 https://github.com/golang/go/issues/12914 This could also be done at very low risk in the `golang.org/x` packages, and the hypothesis that the go community does not understand monotonic clocks could be tested, by looking at the rate of adoption.
  • rspeer 10y ago
    > But: I expect that many of the uses of time.Now to measure elapsed time were accompanied by a comment along the lines of "// TODO: use a monotonic clock when go exposes it". You may be too optimistic. I think most developers haven't heard about monotonic clocks. Cox describes this in his proposal: "Providing two APIs makes it very easy (and likely) for a developer to write programs that fail only rarely, but typically all at the same time."
  • fpoling 10y ago
    I have definitely wrote Go code that assumed monotonic time without any comments. In fact I became aware of the issue only very recently programming in C++. So for me the proposal is very practical and fixes my code with me doing nothing.