とあるプロジェクトでナノ秒からミリ秒への変換で四捨五入してきた人がいて、時刻を扱うときは保存精度未満は切り捨てるべきというのが常識になっていないなーと思ったので。 2023-10-01 を、何年か表示する時に、2024年に丸める人はいないだろう。 13:45 が何時か表示する時も、13時と表示するだろう。（口頭で何時？と聞かれたら14時と答えるかもしれないけれど） つまり、ある精度で表した時刻は、実際には次のような半開区間を示しているのである。 2023-01-01 00:00:00 <= 2023年 < 2024-01-01 00:00:00 13:45:00.000 <= 13:45 < 13:46:00.000 そして、そう決めたからには一貫して同じように、指定精度未満は切り捨てというルールを維持しなければならない。秒以下は四捨五入で、とかやってはいけないのだ。 一貫しないと何が問題

Twitterでこんな記事を見かけたので。 zenn.dev ジェネリクスの件もそうですが、Goの言語設計は現実主義なのになにか特別なポリシーによるものだと宗教化されてしまって、ファンには勝手に崇拝されてアンチにはディスられがちだなーと感じます。 Goのエラー処理を改善する実験プロジェクトxerrorsがGo本体のerrorsにマージされた時、 errors.New() はスタックトレースを取得していました。しかしGo 1.13がリリースされる前に削除されました。 削除された理由の1つは、今までの errors.New() のパフォーマンスに依存していたコードの速度が低下しアロケーションが増えることです。 github.com しかし、これが理由だと今まで思ってたのですが、実際にはもう1つより重要な理由がありました。エラーのフォーマットです。エラーに複数のフォーマットを持たせようという提案