undefined | Better HN

0 pointswwalexander4y ago0 comments

> you must first cast the user value to milliseconds

Incorrect. You must cast the user value to a time.Duration, since Go is a type-safe language, and like most type-safe [1] languages, its numerical operations generally require their operands to be of the same type.

You might be thinking of multiplying a user-provided value by a constant (of type time.Duration) defined by the time package, like time.Millisecond or time.Hour. I’m under the impression this is a very intentional choice to require user-provided values to be explicitly annotated with their units. Some implementations/variants of durations use nanoseconds, some milliseconds, some seconds, and requiring this assumption to be explicit in the code helps avoid critical bugs like the Mars Climate Orbiter failure. [2]

The time package (and other stdlib packages) definitely has some warts, especially the time format parsing, but I’ve always appreciated the approach taken for durations.

[1] We could get into more advanced type inference here like Rust’s From/TryFrom traits, but the debate between simplicity vs. expressiveness in Go has been retreaded here tens of thousands of times and I doubt either of us has anything new to say on the topic.

[2] https://en.m.wikipedia.org/wiki/Mars_Climate_Orbiter

0 comments

3 comments · 1 top-level

naniwaduni4y ago· 2 in thread

> Incorrect. You must cast the user value to a time.Duration, since Go is a type-safe language, and like most type-safe [1] languages, its numerical operations generally require their operands to be of the same type.

This is cargo-cult type-safety; stop a moment to consider the dimensions implied by the types.

wwalexanderOP4y ago

“Units” in the last bit was maybe the wrong word.

To be clear: time.Duration is a type, and is the only part of this discussion where “type safety” is a factor.

time.Millisecond is a constant time.Duration whose value represents the duration of a millisecond. time.Millisecond et al are not a unit as in chemistry class, so you’re not supposed to get a time.Millisecond^2 by multiplying them. Just like in any other typed language, T * T -> T, not T^2 (where T = time.Duration), since it’s a type and not a unit.

time.Millisecond et al instead make you explicitly annotate the scale of user-provided durations. When you write

    d := time.Second*time.Duration(input)

you are assigning to d a value of type time.Duration equal to the duration of one second multiplied by the input. You are free to not use the constants defined by the time package and instead create time.Durations from the literal number of nanoseconds in the duration, if you so choose:

    d := time.Duration(input)*1000000000

But since the time package already defines convenient constants for standard durations, those will be used instead and be far more explicit and readable.

This has nothing to do with dimensional analysis of units, of the sort you do in physical sciences. I don’t know of any general-purpose languages that include dimensional analysis in the language or their standard library’s datetime package, but I’d be curious if you know of one (that isn’t specifically geared towards the sciences) - seems like the sort of thing Ada might include? In any case, I don’t think a language focused on keeping a simple feature set like Go should be a trailblazer here. Durations are easy.

dnautics4y ago

It's still bonkers to make you cast an non-duration input to time.Duration. this causes cognitive confusion, because you are effectively labelling the multiplicand as something that it isn't. All pls with types have semantic meaning for the types if nothing else, so if you can't see why this is a real problem, I can only say: Stockholm syndrome.

"numerical operations generally require their operands to be of the same type"

The correct decision would have been to make the * operator be allowed to operate on a time.Duration and an integer, just as you are uncontroversially allowed to operate * on a float and an integer -- to refute your statement and go even stronger I don't know of ANY pls that require * operands be the same type.

However, that is not what go chose. And we are talking about the choices go made. This is very much NOT well thought out and very ill-considered, especially since "the right thing" is so easy.

3 more replies

j / k navigate · click thread line to collapse