agree with most points in top post except: * float64 for timestamp
for the same reason as ppl don't use floating points for banking applications, but instead use either integer in some units eg cents or fraction of cents, or other fixed point arithmetics. floats will cause issues with rounding or difference wrt roundtrips, not to mention stringification I'd instead use: distinct int64 representing unix timestamp in either milliseconds (range of +/\- 300M years) or microseconds (range of +/\- 300K years); this will need BigInt for js platform. Caveat: leap seconds. note: if your application requires large range/precision, then use: distinct int128 (doesn't exist yet apart from compiler/int128.nim) or type Timestamp = array[2, int64]; this could be exposed in nim and work with both js, c, vm backends (but raises some concern regarding whether we'll then need compiler/int256.nim; hopefully something smarter can be used as that'd be wasteful) > I did not want to use json. I wanted to use binary formats .. compressed > binary formats. that's very application dependent; if you need fwd/backward compatibility, or a schema, or performance, json is bad, protocol buffer or capnproto would be better > Write good tools with command line parameters ideally, "everything is a library", but yes, sometimes a binary that wraps it is good > Always put your code into a src dir. I agree. src is just good hygiene that prevents bugs (eg prevents import pkg/cligen/oops_not_intended_as_source) and should be the default, if not enforced. > In my experience that's the best way to break your project because on install > nimble removes the src directory and then all your paths are wrong. [..]This > is so broken that even in nimble you had workaround like this The issue you mention is real, and the workaround is bad; IMO the fix is to improve nimble, or, if it can't be fixed, add an import syntax import this/nimblepkg/common
