HN user

jdmnd

27 karma

[ my public key: https://keybase.io/jdmnd; my proof: https://keybase.io/jdmnd/sigs/Af9ucrAQhWL_rQyUQeLhcXrBfD0q5yZtHOXqAFDo_vU ]

Posts1
Comments10
View on HN

What you're suggesting seems like a spectacular leap. I do not think it is very likely that the unnamed employee at Cloudflare that was micro-optimising code in the DNS resolver is also the author of this RFC, Joe Abley (the current Director of Engineering at the company, and formerly Director of DNS Operations at ICANN).

It works for any type that implements the `std::error::Error` trait; which is something you can easily implement for your own types. If you want your errors to be integers for some reason, you can wrap that type in a zero-sized "newtype" wrapper, and implement `Error` for that.

The Stack Overflow answer you linked seems to be claiming that it's simply easier to return strings, but I wouldn't say this is a restriction imposed by the language.

I just realized I’m agreeing with a social justice warrior about something

Why are you accusing thinkxl of being a “social justice warrior” and why, exactly do you feel that that undermines your agreement? Is website usability a liberal ideology? Lacking any actual justification your edit feels very out of place on hn.

  Timestamps are 64bit nanoseconds
As far as I can tell, this will overflow in just 11 years – 2028-06-15 09:33:27.3709551615 UTC

Why would this go into a new standard? Is there a practical use for such a high level of granularity?

edit: off by a factor of 10 in my calculation... It's actually

2554-07-21 23:34:33.709551615 UTC