Goのerrorがスタックトレースを含まない理由 - methaneのブログ

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

[envs]

cockroachdb/errorsは良いライブラリなのだが、あまりに名前に難がありすぎる。ゴキブリなのも最悪だが、標準のerrorsと名前が被るのも最悪すぎる。いちいちcerrorsとエイリアスをつける羽目になり厳しい……

[t-wada]

"Goの開発者が何か特別なポリシーや理由でスタックトレースをエラーに付けていないわけではありません。単に影響範囲がデカい言語仕様やコアライブラリの新規APIに対する仕様追加に極めて慎重で時間をかけてるだけ"

[strawberryhunter]

アライアス・・・何のことかと思ったがaliasのことか。

[tomato3713]

“すでに使われている表示手段は後方互換性のために変えられないので、スタックトレース付きでエラー表示をするための追加仕様が必要なのです。表示する手段が存在しないのに、単に遅くてアロケーションが多いだけの

[taguch1]

こういう話題はよく飲み会のつまみになる。汎用性が高い言語だからコアには最小限でっていう感じの設計で、問題にする人は自分の環境のことしか考えてないからよくぶつかったりする。

[onesplat]

goのアホ共って出来ないことに屁理屈をつけたがるよな

[progrhyme]

なるほどー

[turanukimaru]

Goのスタックトレースはほぼ役に立たないしエラーなんてerror返してログを吐けばいい。Goに限らずスタックトレースが欲しいのは設計が悪いかFWが複雑すぎるだけだ。他人のクソ設計はどうにもならない？まぁそうやね。

[maturi]

スタートレック