Tangential, but it bothers me that in Go that I can't multiply a Duration by an int/float, but instead have to convert to Duration and multiply two Durations together! Does this upset anyone else?
Yes. The kind of type modeling this is doing is not very physics-unit-minded at all (where any multiplicative operation potentially creates a new type). Rather, it is trying to prevent non-additive (add/subtract/compare) operations bugs viewed as common/high risk.
I mean, your example in the context of these dim.analysis discussions would really have an output type of DurationSquared, not Duration which is what usual prog.lang modeling does for arithmetic ops.
Go also is not alone. E.g., the Nim std/times has a `*` defined for (int, Duration) but not (float, Duration).
Personally, I suspect prog.langs with native 64-bit ints are better off just using raw nanoseconds for this kind of thing (even time since the epoch gets you into Star Trek centuries.. something like 10 human generations from now).
> which is what usual prog.lang modeling does for arithmetic ops.
I mean, in Python you can't multiply two timedeltas and in Rust you can't multiply two time::Durations. So I'd say that it's not programming language modeling in general that's the problem but rather that Go is putting itself in a category of languages that lose the original semantics of the thing the type is modeling. I'm not sure what other languages are with Go there.
