改めて見直すGoの特徴

極力Goならではな特徴をいくつか挙げていく。 依存解決が必要最低限で互換性を考慮しつつ決定的 モジュール単位で依存をダウンロード。コンパイル対象はサブパッケージ単位。 依存の明示方法はコードに埋め込まれ、かつ未参照のインポートはコンパイルエラー。 つまり動作するコードのすべては正確な依存ツリーが明示されていて余計な依存は引き込まれない。 そして持ち前のコンパイルの速さを含め、相当深い依存ツリーでも依存解決にかかる時間は既知の処理系の中でも最速レベル。（唯一勝てるのはプリビルドバイナリが配布されている場合くらい） また、コンパイルやリンクに必要な処理量そのものが比較的少ないため、開発環境負荷も小さい。 かなり巨大なプロジェクトであってもメモリ8GBで困るようなことが無い。つまり、CI環境の維持にもローコストで済む。 ライブラリの提供側では後方互換性が破壊されるような変更はV1->V2というよ

[snowcrush]

よいまとめ。Goを批判する際はこれくらいの設計上の観点は理解した上でしてほしいなと思ったり。

[inatax]

一番外側にある文法は地味だけど、裏側のコンパイラに注力している言語ってイメージ。仕事道具って感じで、楽しくプログラミングしようって方向には向いてないよね / とりあえずRustとGoを比較させたがる風潮は割と謎

[hasiduki]

もっと楽に並行処理書けるようになって欲しいな！！！！！

[atsushieno]

GCが*有る*時点でわれわれリアルタイムC/C++クラスタはまずgoを選ばないけど（WCETの問題だから）、軽いのはホントそうっぽい（5, 6年くらい昔からそうだと思うが）

[knjname]

良いまとめだと思う　最近割と好きになってきた

[nippondanji]

クラスとか例外が無くてとっつきにくいのが最大の特徴じゃね

[uehaj]

いい記事

[jay-es]

"GoとRustを比較しても仕方がない面はある"

[zyzy]

Javaっぽいというか、コンパイルできるお陰で速いPython的に手軽に扱うべきものというイメージだった。

[l-_-ll]

"・協調型スレッドだとブロッキング処理を混ぜてはいけない　goroutineは軽量かつプリエンプティブなOSスレッドのように良いとこどりの性質がある。"

[yarumato]

“GoとRustはコマンドラインツールを作りやすい以外は実は得意分野が被らない。RustはC/C++資産の活用や置き換えが得意（特定環境にフォーカスして作りこむ）でGoはそうではなくJava的用途（特定環境に縛られない）に向く”

[akiramaz]

goにはなぜか憧れがある

[minaminoani]

「GOGOGOGO~~~~！」とか「JAPA~~~~N!!」とか言いがち

[havanap]

コンパイルはホント爆速

[versatile]

この人結構な go 信者なんだよなぁ。欠点とかもちゃんと提示して欲しい気持ち。あと、 rust と比較してほしい。

[t2y-1979]

ありがたい