Goにatexitやグローバルなデストラクタがない理由 - Qiita

CやC++ではatexit関数で関数を登録しておくと、プログラムの終了時にその関数を自動的に走らせることができる。そういう機能はRubyやPythonにもある。 Goにはそういう機能はない。実装を忘れているのではなくて、意図的にそういう機能を持たせていないのだ。これについてIan Lance Taylorさんが大変説得力のある説明をしていた。 まず第一に、どんなプログラムでも任意の箇所でクラッシュしうるし、まったくバグのないプログラムでもいきなりkillで殺されたりマシンが電源断で落ちるということがある。従ってどんなプログラムも、突然終了させられたあとに、もう一度きちんと動くことができなければならない。つまりatexitはきれいに終了するための機能ということで、atexitが呼び出されないとうまく動かないプログラムというのはそもそも間違っているということになる。 大きなC++プログラムでは

[koyancya]

ウケるｗ -> "結局std::at_quick_exitというのも同時に導入された"

[embedded]

「あるとないのでは、ないほうがよいというのがGoのデザイン上の選択なのだ。」

[tanakh]

atexitはしらんけどデストラクタに類する機能無しでリソース管理するの地獄では

[yohshiy]

言いたいことはわかるけど、本当に電源ブチッに対応できる言語なんて存在しないでしょ。

[you21979]

“あるのとないのでは、ないほうがよいというのがGoのデザイン”このコンセプトが好き

[kasumani]

Goにatexitやデストラクタがない理由 CやC++ではatexit関数で関数を登録しておくと、プログラムの終了時にその関数を自動的に走らせることができる。そういう機能はRubyやPythonにもある。 Tags: ifttt, kasumaniのストックした投稿 -

[Magicant]

atexit が駄目なのは分かるがデストラクタを否定する理由にはなってゐない

[YaSuYuKi]

なくても動く必要がある物なら、始めから存在しなくていいという判断か

[trashtoy]

「なんでもかんでもできる」という状態は、作る人には良いけれどそれを保守する立場の人にとっては逆に迷惑だったりすることも多いので、このような秩序をもたらすことを重視するデザインは歓迎したい

[t-wada]

“os.Exitはdeferを実行せずに即座に終了する。このデザインはときどき不便なことも引き起こすが（atexitが確かに便利というのは否定しない）、あるのとないのでは、ないほうがよいというのがGoのデザイン上の選択”

[nemoba]

この辺りはフォールトトレラントや安易なフェイルセーフ機構に頼るんじゃなくてデザインに取り込めというGoogleの思想っぽい。ふとハードウェアに手を出した今のGoogleも同じ考えなのか気になった。

[ngyuki]

atexit はともかくデストラクタもそうなの？

[theatrical]

「選択の自由こそが正義！」なC++とは、対象的だな。どちらがよいという事もないだろうけども、少なくともチーム開発ではGoのほうがよいかな。

[yosuke_furukawa]

at_quick_exit...

[itouhiro]

「atexitが呼び出されないとうまく動かないプログラムというのはそもそも間違っている」「あるとないのでは、ないほうがよいというのがGoのデザイン上の選択」

[mirakui]

いい話

[sonots]

なるほど〜。理由があったのか。

[ledsun]

ほほう