Go language part 3

**デフォルトの名無しさん** · 2019/10/17(木) 21:38:04.78

Goについて扱うスレッドです。
GoはGoogleによって開発された言語です。

公式ドキュメント
http://golang.org/doc/

日本語訳
http://golang.jp

※前スレ
Go language part 2
https://mevius.5ch.net/test/read.cgi/tech/1510395926/

**デフォルトの名無しさん** · 2019/10/17(木) 22:00:39.82

>>1乙
テンプレが古すぎるんで作ってみたがどうだろ

公式
https://golang.org

公式ドキュメント
https://golang.org/doc/

公式外パッケージドキュメント
https://godoc.org

ブラウザ上で試し書き
https://play.golang.org

**デフォルトの名無しさん** · 2019/10/17(木) 22:34:25.92

golang.jpは外して良いね

**デフォルトの名無しさん** · 2019/10/18(金) 00:00:29.03

golang.jp は、エイベルの古川昇部長が、社内で始めた翻訳プロジェクトだろ？
最近は、活動してないのか？

改訂2版基礎からわかる Go言語、古川昇(エイベル)、2015

**デフォルトの名無しさん** · 2019/10/18(金) 00:45:01.73

その人もうやめてるでしょ

**デフォルトの名無しさん** · 2019/10/18(金) 13:53:47.66

先週から仕事でGoやることになったんだが、この言語辛すぎないか・・・？
ジェネリクスないしエラーが辛い。ジェネリクスは2.0で入るらしいが。
Goの作法だとエラーハンドリング忘れて次の処理を書けるリスクが常に孕んでてて書いてて全然安心できない。
あと詳細なエラー情報見ようとするとcustomErr,ok:=err.(CustomError)みたいにしないと情報とれないの危なすぎでしょ。
なんでカスタムエラー型認められていないの？

**デフォルトの名無しさん** · 2019/10/18(金) 14:25:55.97

>>6
認められていない訳じゃない
しかし、カスタムなエラー型だと正常時にnilが帰ってきた時に
if err!=nil {} がtrue判断を食らうという厄介なバグがある
これは型付きnilというバグだが、仕様と言い張ってる模様
仕様なら、the predeclared identifier nil, which has no typeの記述とか直せや！

**デフォルトの名無しさん** · 2019/10/18(金) 14:31:17.21

>>6
エラー処理を忘れるうっかりさんは例外だってキャッチ忘れるだろな

そして、エラー処理は1.13でほんの気持ちだけ改修入ってるからチェック
Is, As

**デフォルトの名無しさん** · 2019/10/18(金) 14:39:41.03

**デフォルトの名無しさん** · 2019/10/18(金) 15:49:30.94

>>7 認められてないというよりか風潮といった感じか
カスタムエラーがstructじゃなくてinterfaceならいけるんじゃない？
まあどのみち使用しているライブラリがerror返してるからどうしようもないんだけどな
俺はMySQLのエラー番号が知りたいだけなのにどうして危険な操作を強いられるんだ

>>8 まず俺はGoのエラーと例外を引き合いに出してはいない(例外は糞だが)
例えば関数の戻り値がT,errorのような場合でerrorじゃないときだけTの戻り値にアクセスできるような仕組みが欲しい
ScalaのEitherやRustのResultのようなやつな
今はジェネリクスないからそういう実装はできないだろうけど
そもそも職場の制約で.1.13は使えないが、IsもAsも対してかわらんなって印象だわ。
ライブラリの実装者が中で返すエラーの型を変えた場合、IsやAsしててもコンパイルエラーにならず適切なエラー処理ができずに実行されてしまう。
戻り値の型できちんとカスタムエラー型を明示してくれてればコンパイルエラーで気づけるんだけどな

今さっき聞いたんだけど、2.0で入る予定のエラーハンドリング周りのサポート、error型のみが対象らしいんだってな。
2.0にはいると本当にカスタムエラーの道が閉ざされてしまいそうだけど本当にそれでええんやろか

**デフォルトの名無しさん** · 2019/10/18(金) 16:01:34.41

エラー処理の観点から見るとジェネリクスないのはもう相当きついね
関数型脳は捨てるしかない

**デフォルトの名無しさん** · 2019/10/18(金) 19:57:12.19

まあRustも関数型言語かというと違うけどな。標準ライブラリにはモナドないし。
ジェネリクスが必要なものに関しては今使えないから仕方がない面はあるとは思う。

ただカスタムエラー型が実質使えない状態になってるのは辛いなあとは思う

**デフォルトの名無しさん** · 2019/10/18(金) 21:03:52.48

モナドあってもdo記法相当ないときついからね

**デフォルトの名無しさん** · 2019/10/19(土) 15:58:08.27

exe でかいな・・・

**デフォルトの名無しさん** · 2019/10/19(土) 19:06:00.27

う、うん…

**デフォルトの名無しさん** · 2019/10/19(土) 19:56:56.88

2MBは静的リンクされてる実行ファイルなら普通よ
C系のリンカーの出力だとままある
動的リンクされてDLLとかアセンブリとかSOをロードする実行ファイルとは違う
ロードが速いはずというメリットもある

**デフォルトの名無しさん** · 2019/10/19(土) 22:13:55.22

せやな
この特性でインスタンスの起動が早くてクラウドだと重宝するね
反面WASMとかだと辛いという話は聞いている

**デフォルトの名無しさん** · 2019/10/20(日) 10:01:30.26

そもそもC/C++自体がすでに第一選択の言語じゃなくて、応答性やパフォーマンスの問題で消去法で選ばれる言語だし、
Goはそれで弾かれる側の言語なんで無理無理

Goが選択肢に入るような要件ならC++は選択肢に入らないし、逆もまた然り

**デフォルトの名無しさん** · 2019/10/20(日) 10:16:19.34

しかし、C++は他に選択肢が無いというよりアセンブラより生産性が高いという消去法で選択される言語
C++よりも生産性が高いと思う人間、例えばGoogleとか俺にとっては消去法での乗り換えが充分に考えられる

**デフォルトの名無しさん** · 2019/10/20(日) 10:22:02.89

あ、もうちょい書き足りなかった
つまり、ベターなアセンブラの地位をC/C++から奪おうという狙いの言語、という位置付けだと考えるよ