> 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::

> 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.