4 ms·

The real problem is `duration * time.Millisecond` makes no sense. The time api seems a bit obtuse. Why not `duration.milliseconds`?

jgrahamc 13y ago
Agree. Part of the problem here is that the Go time.Duration is just an int64 so you can do arithmetic on them. It would be better if there was something like NewDurationMilliseconds(). Thus the type here allowed me to shoot myself in the foot. Having said that it doesn't change the fact that looking into the 'flaky' test was the right thing to do. Even if the type system were different I'm sure I would have shot myself in the foot in some other way.
- barrkel 13y ago
  Seems it would rather be better if there was a .net TimeSpan / JodaTime Duration type, or better yet, a type system that understood units.
Titanous 13y ago
time.Duration is a count of nanoseconds, and time.Millisecond is a constant that represents the number of nanoseconds in a millisecond. http://golang.org/pkg/time/#Duration http://golang.org/pkg/time/#Duration
- AaronFriel 13y ago
  This is the sort of thing having a Haskell-like typesystem would fix - multiplying something by "time.Millisecond" is difficult to discern the semantic meaning of, especially when nothing in the code/language prevents you from doing it multiple times. The idea of storing this information as just a regular Int64 bothers me after spending so much time in type system nirvana.
  - dragonwriter 13y ago
    > The idea of storing this information as just a regular Int64 bothers me after spending so much time in type system nirvana. Its not a regular int64, its a distinct named type (Duration) where int64 is the underyling time. I'm still getting familiar with Go -- and don't have it on the machine I'm using at the moment -- but from the docs named types are incompatible with other named types with the same underlying types in numerous contexts, but it looks like one place where named types are leaky abstractions is their interaction with operators.
    - dragonwriter 13y ago
      To illustrate this point, this code: package main import ( "time" "fmt" ) func ident(x int64) int64 { return x } func main() { t := time.Duration(1) v := math.Inf(t) } produces the error: cannot use t (type time.Duration) as type int64 in function argument The issue is with Go's arithmetic operators subverting the type system more than with the type system itself.
deleted 13y ago
[deleted]

jgrahamc 13y ago

Agree. Part of the problem here is that the Go time.Duration is just an int64 so you can do arithmetic on them. It would be better if there was something like NewDurationMilliseconds(). Thus the type here allowed me to shoot myself in the foot. Having said that it doesn't change the fact that looking into the 'flaky' test was the right thing to do. Even if the type system were different I'm sure I would have shot myself in the foot in some other way.

barrkel 13y ago
Seems it would rather be better if there was a .net TimeSpan / JodaTime Duration type, or better yet, a type system that understood units.

Titanous 13y ago

time.Duration is a count of nanoseconds, and time.Millisecond is a constant that represents the number of nanoseconds in a millisecond. http://golang.org/pkg/time/#Duration http://golang.org/pkg/time/#Duration

AaronFriel 13y ago
This is the sort of thing having a Haskell-like typesystem would fix - multiplying something by "time.Millisecond" is difficult to discern the semantic meaning of, especially when nothing in the code/language prevents you from doing it multiple times. The idea of storing this information as just a regular Int64 bothers me after spending so much time in type system nirvana.
- dragonwriter 13y ago
  > The idea of storing this information as just a regular Int64 bothers me after spending so much time in type system nirvana. Its not a regular int64, its a distinct named type (Duration) where int64 is the underyling time. I'm still getting familiar with Go -- and don't have it on the machine I'm using at the moment -- but from the docs named types are incompatible with other named types with the same underlying types in numerous contexts, but it looks like one place where named types are leaky abstractions is their interaction with operators.
  - dragonwriter 13y ago
    To illustrate this point, this code: package main import ( "time" "fmt" ) func ident(x int64) int64 { return x } func main() { t := time.Duration(1) v := math.Inf(t) } produces the error: cannot use t (type time.Duration) as type int64 in function argument The issue is with Go's arithmetic operators subverting the type system more than with the type system itself.

deleted 13y ago

[deleted]