<@U0BFDUP0E> i respect what you are saying... but ...

# announcements

[sss]

@jw i respect what you are saying... but there is value for an application developer if the architects of kotlin condensed these issues into an implementation abstraction. nobody has to use it... but there is HUGE value in sane defaults for the end consumer. take a look at the latest comment on the golang thread

The fact that an organization like CloudFlare, a prominent Go user and contributor, had a publicly visible outage due to this, should be a wake up call for the Go community.

While there is always a possibility that the engineers at CloudFlare would have made that mistake anyway, the truth is that this mistake is incredibly easy to make in Go because there is no standard alternative, and because of this it's a mistake that is widespread in a lot of prominent open-source Go projects (I mentioned gRPC as another example earlier), which further exacerbates the problem.

Go itself doesn't use time.Now() for its own bookkeeping needs, why force everybody to re-implement the platform-specific details behind runtime.nanotime()? For a systems programming language, isn't this need fundamental enough to warrant an API in the standard library?

edit: or using a hack like the one we published to expose runtime.nanotime() at https://github.com/aristanetworks/goarista/tree/master/monotime