Type safety and time units in Go and D

[Laeeth Isharc via Digitalmars-d]

  the question of why that is the way it is, it's because we
>> actually
>> thought of all that shit when designing the time library :) I 
>> was a big
>> proponent of not using the same type to mean duration and 
>> timestamp, and
>> only allowing sane operations. Jonathan was the same way.
>
> That separation is one of the main reasons for introducing

I would like to express my appreciation to the implementors  (I 
guess Jonathan and Stephen) as well as to the Phobos guardians 
for taking the pains to implement the datetime library in a 
thoughtful and conscious way.

Dates are not conventionally the most glamorous part of a 
library, but they are very important in some key use cases for D. 
  Much of finance is about net present value, and for that you 
need to get datetimes right.  Every swap has a bunch of 
cashflows, and you need to apply various market conventions in 
generating these.  Eg cashflows are every three months, and you 
roll forward if the payment day is a holiday, unless that would 
take you to the next month, in which case you roll backwards.  
Similarly for analyzing high frequency data, one needs to be able 
to work easily with timestamps.

I was so frustrated by numpy's datetime64 that I ended up rolling 
my own, so it is encouraging that my new chosen platform (D) 
natively does a much better job.

The level of attention to detail, high standards, and 
appreciation of beauty are some of the best things about the 
language and the people here.

On a different note, and having read the discussion Jonathan 
linked to: bounded int, and better messages about template 
constraints would certainly be things I would find helpful.