4 ms·

What is correct is that duration ± duration = duration, duration * scalar = duration, timestamp ± duration = timestamp, timestamp - timestamp = duration, and an

What is correct is that duration ± duration = duration, duration * scalar = duration, timestamp ± duration = timestamp, timestamp - timestamp = duration, and anything else doesn't compile.

Groxx 5y ago
To call it out specifically: this does not include `duration * duration = duration` Go is currently allowing that, which makes `delaySecs * time.Second` a billion times larger than it appears to intend. I've personally run across code that has this kind of flaw in it... at least several dozen times. It's the kind of thing that's only noticed when it misbehaves visibly while someone is watching it. (I read a lot of other-teams' code, which is in various states of quality and disarray)
- chrismorgan 5y ago
  And it’s not just that Go allows that, but that that’s actually the only general way of doing it, as Go only allows duration * scalar in constant context (which is admittedly all most people do with durations, which is why I say it’s still probably better than Go did it this way, given their deliberately limited type system).
svnpenn 5y ago
If you exponent time.Duration, that's a user error. What you're suggesting would be like a compiler error for multiplying two int64s
- conradludgate 5y ago
  It should be fine to multiply two durations, but it should not return the same time.Duration type
- linkdd 5y ago
  What they're suggesting is that `time.Duration` should not be an int64. 1 second * 1 second = 1 second² 1 meter * 1 meter = 1 meter² 1 meter / 1 second = 1 m/s Those are not user errors, those are physical values. A physical value is two things: - a scalar (int64, float, ...) - a unit (meter, second, inches, ...) If the type system of your programming language does not allow you to define units, this should at least be a structure with a scalar and an enum, and functions to cast from one unit to another (if possible). Working with units is a common thing in science.
  - skissane 5y ago
    > A physical value is two things: I would argue it is actually three things: a scalar, a unit, and an indication of error – which is at least another scalar, but there are multiple ways of expressing error, so it might require more than just a single scalar (such as an interval and the probability the actual value lies within that interval.) > If the type system of your programming language does not allow you to define units, this should at least be a structure with a scalar and an enum Ideally more than just an enum – Newton = kg*m*s^-2 (equivalently kg^1*m^1*s^-2) – which suggests a set of pairs (unit and exponent).
    - linkdd 5y ago
      Yes, thank you for the precisions, this just make my point stronger: int64/float are very ill-suited to represent such values. And it's especially true for time units. For example, "how many seconds is one month?" does not make sense, but "how many seconds is january/february/march?" does make sense. The unit "month" does not really exist, each calendar month is its own unit. And "february" is not even a "stable" unit because sometimes it's 28 days, sometimes it's 29 days. Even a minute can some rare times be 61 seconds. This is why in physics, we use seconds multiplied by powers of 10 and nothing else. To my knowledge, there is not a single programming language that differentiate a "scalar" and a "quantity" (scalar, unit, error).
afiori 5y ago
not being able to sum timestamps is a bit beyond the scope of units, it is more of a vector vs point distinction

What is correct is that duration ± duration = duration, duration * scalar = duration, timestamp ± duration = timestamp, timestamp - timestamp = duration, and anything else doesn't compile.

Groxx 5y ago

To call it out specifically: this does not include `duration * duration = duration` Go is currently allowing that, which makes `delaySecs * time.Second` a billion times larger than it appears to intend. I've personally run across code that has this kind of flaw in it... at least several dozen times. It's the kind of thing that's only noticed when it misbehaves visibly while someone is watching it. (I read a lot of other-teams' code, which is in various states of quality and disarray)

chrismorgan 5y ago
And it’s not just that Go allows that, but that that’s actually the only general way of doing it, as Go only allows duration * scalar in constant context (which is admittedly all most people do with durations, which is why I say it’s still probably better than Go did it this way, given their deliberately limited type system).

svnpenn 5y ago

If you exponent time.Duration, that's a user error. What you're suggesting would be like a compiler error for multiplying two int64s

conradludgate 5y ago
It should be fine to multiply two durations, but it should not return the same time.Duration type
linkdd 5y ago
What they're suggesting is that `time.Duration` should not be an int64. 1 second * 1 second = 1 second² 1 meter * 1 meter = 1 meter² 1 meter / 1 second = 1 m/s Those are not user errors, those are physical values. A physical value is two things: - a scalar (int64, float, ...) - a unit (meter, second, inches, ...) If the type system of your programming language does not allow you to define units, this should at least be a structure with a scalar and an enum, and functions to cast from one unit to another (if possible). Working with units is a common thing in science.
- skissane 5y ago
  > A physical value is two things: I would argue it is actually three things: a scalar, a unit, and an indication of error – which is at least another scalar, but there are multiple ways of expressing error, so it might require more than just a single scalar (such as an interval and the probability the actual value lies within that interval.) > If the type system of your programming language does not allow you to define units, this should at least be a structure with a scalar and an enum Ideally more than just an enum – Newton = kg*m*s^-2 (equivalently kg^1*m^1*s^-2) – which suggests a set of pairs (unit and exponent).
  - linkdd 5y ago
    Yes, thank you for the precisions, this just make my point stronger: int64/float are very ill-suited to represent such values. And it's especially true for time units. For example, "how many seconds is one month?" does not make sense, but "how many seconds is january/february/march?" does make sense. The unit "month" does not really exist, each calendar month is its own unit. And "february" is not even a "stable" unit because sometimes it's 28 days, sometimes it's 29 days. Even a minute can some rare times be 61 seconds. This is why in physics, we use seconds multiplied by powers of 10 and nothing else. To my knowledge, there is not a single programming language that differentiate a "scalar" and a "quantity" (scalar, unit, error).

afiori 5y ago

not being able to sum timestamps is a bit beyond the scope of units, it is more of a vector vs point distinction