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/

**デフォルトの名無しさん** · 2020/02/14(金) 17:05:12.42

Raku？

**デフォルトの名無しさん** · 2020/02/23(日) 01:33:36.39

golang.jpが壊れて治らないから諦めてwebarchive行くことにした

**デフォルトの名無しさん** · 2020/02/23(日) 05:51:08.90

あのサイト更新しないなら迷惑だから手放して欲しい

**デフォルトの名無しさん** · 2020/02/23(日) 07:32:28.47

golangが完全に終焉するとき
名前がgoneにかわる

**デフォルトの名無しさん** · 2020/02/23(日) 17:32:58.19

golang-jp.netみたいな日本向けドメイン取って誰かが新しいサイト作って

**デフォルトの名無しさん** · 2020/02/23(日) 17:33:15.17

アフィリエイトで広告踏みますのでよろしくおねがいします

**デフォルトの名無しさん** · 2020/02/23(日) 18:26:12.17

gone lang

**デフォルトの名無しさん** · 2020/02/24(月) 09:46:04.88

Ghosn lang

**デフォルトの名無しさん** · 2020/02/25(火) 09:16:55.76

go(rust)lang

**デフォルトの名無しさん** · 2020/02/26(水) 01:59:09.78

goとrustは目指す目的が違いすぎて、並べて書く意味がなさすぎ

**デフォルトの名無しさん** · 2020/02/26(水) 12:27:16.65

go 1.14

**デフォルトの名無しさん** · 2020/02/26(水) 13:50:20.35

ｷﾀ━━━━(ﾟ∀ﾟ)━━━━!!

**デフォルトの名無しさん** · 2020/02/26(水) 20:33:01.24

1.14のissueって昨日まで20個以上残ってたと思ったけど、あれどうしたのかな

**デフォルトの名無しさん** · 2020/02/26(水) 20:55:36.03

release blocker issueは2個くらいだったし
それ以外は次バージョンに延期でしょ

**デフォルトの名無しさん** · 2020/02/27(木) 01:35:23.22

>>297
とりあえずブロックするって方向はそんなに悪くはないと思う。
あとはブロックされてリークしたgoルーチンの回収をどうするか。

**デフォルトの名無しさん** · 2020/03/03(火) 01:30:23.85

プログラミング言語人気ランキング2020、2位に「大躍進」したあの言語
https://active.nikkeibp.co.jp/atcl/act/19/00124/022700001/

**デフォルトの名無しさん** · 2020/03/03(火) 01:54:48.77

>>317
なにこのクソ統計

**デフォルトの名無しさん** · 2020/03/03(火) 06:54:36.36

「つまらないアンケートに答える層が使っている言語」の統計
FORTRANより下に主流の言語があるのがなかなか

**デフォルトの名無しさん** · 2020/03/03(火) 15:18:27.96

C/C++いまだに多いけどどういう人が投票してるんだろう
統計でデタラメな誘導するのはやめて欲しいよ

**デフォルトの名無しさん** · 2020/03/03(火) 15:55:28.64

お前らが見慣れてるような言語ランキングだって相当なバイアスがかかってるだろう
日本の実情としてはまあ納得できるランキングだと思うけどな
むしろこの面子でGoが意外と健闘してるのは驚き
C/C++が多いのは、業務システム分野では互いに競合する言語が比較的多いのに対して、組み込みや制御の分野の中では代替が事実上存在しないからだろうね

**デフォルトの名無しさん** · 2020/03/03(火) 17:03:27.84

Rubyは始まりも、オワコンなのよ
そうよ、Perlと共にお墓に向かってるの
どんなときでも時代はPHP♪
homubrewもrubyを切り捨てた現実を受け入れなさい！

**デフォルトの名無しさん** · 2020/03/03(火) 17:35:54.85

FORTRANがあるということは製造業なのかな
それも主に自動車産業

**デフォルトの名無しさん** · 2020/03/03(火) 18:07:23.29

アセンブリも多すぎ

**デフォルトの名無しさん** · 2020/03/07(土) 02:35:58.91

>>317
4位SQLてw

**デフォルトの名無しさん** · 2020/03/07(土) 07:25:40.42

まあ、職業プログラマーでSQL使わない奴なんてまず居ないだろから

**デフォルトの名無しさん** · 2020/03/07(土) 22:21:25.44

今の現場、DBが完全にDynamoDB（KvS）に移行したぞ
リレーショナルデータベース使わなくなった

**デフォルトの名無しさん** · 2020/03/08(日) 02:34:50.44

いくらサービスのOLTP系のDBがDynamoDBオンリーでも、会社なら業務系のDBとかデータ分析用のDWHとかあるしWebエンジニアでもたまにはそういうところ触ることもあるだろ?
お前の狭い業務では使わなくなった、の間違いだ

**デフォルトの名無しさん** · 2020/03/08(日) 03:17:31.31

どうでもええわｗ

**デフォルトの名無しさん** · 2020/03/08(日) 04:52:01.22

それにしても使えば使うほどクソさが見えてきて
嫌悪しかでてこない言語だなgolangは

**デフォルトの名無しさん** · 2020/03/08(日) 08:39:45.83

なんでそんなこと言うの？

**デフォルトの名無しさん** · 2020/03/08(日) 13:05:02.79

>それにしても使えば使うほどクソさが見えてきて
これはほぼどの言語にも当てはまらなくはない

>嫌悪しかでてこない言語だなgolangは
個人の主観です

**デフォルトの名無しさん** · 2020/03/12(木) 09:34:07.31

Kotlinは使えば使うほど良いなと思う
サーバーサイドもKotlinの世界になればいいのだ

**デフォルトの名無しさん** · 2020/03/12(木) 12:44:20.39

ちょっと鮮度が落ちた話だけど Let's Encrypt が幾つかの証明書を無効化する羽目に
その原因がgolangあるあるの、実体配列ループでコピーしたオブジェクト書き換えてたバグらしい
実体配列ってクソだな

**デフォルトの名無しさん** · 2020/03/12(木) 12:51:29.46

何で参照を渡していたのか不思議…
数行下では値渡しにしているのに

**デフォルトの名無しさん** · 2020/03/13(金) 02:40:12.76

>>334
大人しくpython使ってればこんなことには

**デフォルトの名無しさん** · 2020/03/13(金) 05:59:29.90

pythonのほうでも、旧アマ driveを便利に使えるようにする一番有名だった
3rd partyツールが、関数に渡す引数の扱いを間違えて別の人のファイルが
見えるようになったりしてたけどね
旧driveの容量無制限と3rd partyへのAPI解放をやめさせた遠因

**デフォルトの名無しさん** · 2020/03/14(土) 11:58:15.74

>>333
goとcとphpしかやったことないんだけど、Kotlinええの？

**デフォルトの名無しさん** · 2020/03/14(土) 12:17:59.41

>>333
Javaランタイムで動かす別言語だと思ってたが、サーバでは使えんの？
そもそもgolangスレで発言した意図がわかんない
Javaスレに行けば？

**デフォルトの名無しさん** · 2020/03/14(土) 14:12:55.38

コンテナ時代にJavaはなあ
Java系はそのエコシステムの中だけで完結するからこそ意味があるんだよ
そもそもJavaプラットフォームは十分にポータブルで、コンテナのような低レイヤの抽象化を必要としない
Javaをコンテナに閉じ込めて動かすのはJavaの全盛期を知る者としては屈辱だよ

**デフォルトの名無しさん** · 2020/03/14(土) 14:50:10.22

WSLは許せるのか

**デフォルトの名無しさん** · 2020/03/15(日) 00:47:49.73

Javaの欠点はメモリを食い過ぎること
本当にこれだけだと思う

**デフォルトの名無しさん** · 2020/03/15(日) 08:43:01.20

javaの欠点はメソッド名が長すぎ
何をするにも面倒臭い
アレとアレをつなげてコレとコレをつなげてやっとこさHellow World

**デフォルトの名無しさん** · 2020/03/16(月) 09:48:42.75

Javaとかいて邪魔と読みます。くらいに要らない子

**デフォルトの名無しさん** · 2020/03/27(金) 23:34:18.93

Java馬鹿にしてるやついるけど

if err != nil をコピペしまくる言語よりかはダサくないよ（笑）

**デフォルトの名無しさん** · 2020/03/28(土) 00:54:18.47

JavaをバカにしていいのはC#とかの直系親族かなー
でも御先祖様だから敬わないと
golangから見てそれこそカブる部分が少ないんで他所の御家庭

でもVBさんちは何とかしてほしいと思ってしまう自分を許して

**デフォルトの名無しさん** · 2020/03/28(土) 10:49:35.20

コピペって(笑)、インテリセンスとかスニペットが無い世界の人は大変だな

**デフォルトの名無しさん** · 2020/03/28(土) 13:55:52.36

Javaがバカにされるのはそれを使っているプログラマのせいじゃないかと思う。
企業需要が大きいから促成栽培のドカタが量産されたという。

純粋に言語として評価したら、CやC++の問題点をよく研究している印象なんだがな。

**デフォルトの名無しさん** · 2020/03/28(土) 14:41:47.75

ダサいと感じるかどうかは人それぞれだが
エラーハンドリングのボイラープレートが
どうしようもなく多いのは事実だよね

Go2に期待してたんだがな

**デフォルトの名無しさん** · 2020/03/28(土) 14:51:39.39

Goのやり方の是非はともかく、例外がいつどこから飛んでくるかわからない「漠然とした不安」がないのはいい
あの不安は少なからず脳の働きを阻害して生産性を下げてると思うわ

**デフォルトの名無しさん** · 2020/03/28(土) 18:25:33.89

書く量が多くなるとかそれぐらいは別にいいんだけどさぁー
どうせコピペするだけだし(笑)
最初にエラーハンドリングはそこまで要らないなと思って書いてたコード群が
後で扱うデータの仕様変更があってエラーハンドリングが必要になったときに
ガッポリその部分覆ってまとめてエラー扱うってのが一切できないんだよな
こうなってしまうと全部のコードリファクタしないといけないしなんなら
個別のロジックまで追いかけて問題ないかチェックしないといけなくなる
こういうところがgoはクソなんだよな

**デフォルトの名無しさん** · 2020/03/28(土) 18:48:45.17

> 最初にエラーハンドリングはそこまで要らないなと思って書いてたコード群が

単に見通しが甘いだけなんじゃないか

**デフォルトの名無しさん** · 2020/03/28(土) 19:28:58.20

Cでlongjump使いまくってたタイプじゃね？

**デフォルトの名無しさん** · 2020/03/29(日) 01:28:26.45

>>352
だから何？
お前が見通してくれるわけじゃないなら黙ってろよ

**デフォルトの名無しさん** · 2020/03/29(日) 01:31:05.49

顔真っ赤だぞｗ

**デフォルトの名無しさん** · 2020/03/29(日) 01:58:14.56

由緒正しい2chの流れだな

**デフォルトの名無しさん** · 2020/03/29(日) 09:36:10.09

>後で扱うデータの仕様変更があってエラーハンドリングが必要になったときに
>ガッポリその部分覆ってまとめてエラー扱うってのが一切できないんだよな

これ自体が例外ありきの発想のように思う

**デフォルトの名無しさん** · 2020/03/29(日) 09:50:09.28

Goだと極一部の簡単な関数を除けば基本的にerrを返すから、後でerr発生箇所が増えても影響は関数一つだけだろう
それが問題になるようなアホみたいに長い関数を書いてるならそれ以前の問題だな

**デフォルトの名無しさん** · 2020/03/29(日) 10:32:30.34

errorを返すように関数を変えたなら
call siteをすべて変更しなきゃいけないってのは仕方がない
それは考え方の違いだから将来的にも修正されることは無いと思われる

ただcall siteで単にエラーをpropagateするだけなのに
毎度毎度`if err != nil`書かせるのは頭悪いしノイズ比が高すぎる

開発陣も問題だと思ってるからどうにか改善しようとしてるけど
下の提案はダメになったからどんなに早くてもあと数年は現状維持だろうね
https://go.googlesource.com/proposal/+/master/design/go2draft-error-handling-overview.md
https://go.googlesource.com/proposal/+/master/design/32437-try-builtin.md

**デフォルトの名無しさん** · 2020/03/29(日) 12:46:52.07

vscode で if err!=nil のブロックをデフォルトで折り畳んでくれたら、おれは嬉しい

**デフォルトの名無しさん** · 2020/03/30(月) 01:14:32.45

err返すくせに型に現れないのは正直ゴミ

**デフォルトの名無しさん** · 2020/03/30(月) 01:28:23.67

またお前か

**デフォルトの名無しさん** · 2020/03/30(月) 03:48:40.78

またお前かって初めてこのスレに書き込んだんだが
そういって一生ゴミ仕様から目を背け続けろな

**デフォルトの名無しさん** · 2020/03/30(月) 09:45:11.16

わかったよ、ゴミ

**デフォルトの名無しさん** · 2020/03/30(月) 10:59:24.22

errさんイライラwwwwwwwwwwwwwwwwww

**デフォルトの名無しさん** · 2020/03/30(月) 11:27:55.23

errさんはPHPしか触ってこなかったから気にしないんだよ

**デフォルトの名無しさん** · 2020/04/01(水) 02:09:08.12

Cだともっと酷いよ？
戻りでエラー返すと本来の戻り値が潰れるから
&errorとかいう独自定義のエラー用構造体を引数に毎回渡す
これに比べたら天国

**デフォルトの名無しさん** · 2020/04/01(水) 10:12:05.33

Goは標準ライブラリが豊富っていうけどどこらへんが豊富なの？
Goは並行処理が得意なのに並列処理が得意とか実際に触ってるわけでもないのに書く人多いから豊富ってのも嘘なんじゃないかと思ってる

**デフォルトの名無しさん** · 2020/04/01(水) 10:14:23.29

そうだよ嘘だよ。じゃね～さよなら

**デフォルトの名無しさん** · 2020/04/01(水) 10:49:13.13

>>367
GetLastError
エラーを取得するには関数を使います

**デフォルトの名無しさん** · 2020/04/01(水) 11:07:46.88

GetLastError() って Windows OS のみ？

**デフォルトの名無しさん** · 2020/04/01(水) 12:24:45.60

Cだと戻り値でデータ返したりエラーコード返したりやりたい放題で一貫性が無さすぎ
Javaとかはtry catch地獄
Cでレジスタで戻り値返さずに複数値返せる設計にしてれば標準となって皆幸福だったのに

**デフォルトの名無しさん** · 2020/04/01(水) 12:30:21.07

最近のは(小さい)構造体なら返せるやろ
デカいのは無駄だし
mallocしたのだと解放が面倒だが

**デフォルトの名無しさん** · 2020/04/01(水) 14:22:10.98

>>372
ハードウェアの構造無視しすぎ。
それでみな幸せならとっくにそうなっとるわ。
cでもスタックの使い方の規約なんて昔と相当変わってる。

**デフォルトの名無しさん** · 2020/04/01(水) 14:28:21.58

スレ違い

**デフォルトの名無しさん** · 2020/04/01(水) 16:03:45.28

>>370
Windowsの作法やん
それにグローバルなエラー情報とか論外

**デフォルトの名無しさん** · 2020/04/02(木) 08:03:50.65

>>374
ん、その昔の段階で戻り値の返し方で言語仕様的に一工夫してくれてたらという正直ムチャ振りなレスだったんだけど

**デフォルトの名無しさん** · 2020/04/02(木) 17:36:34.36

Goって複数の戻り値はスタックにおいてるのかね？
その辺どうなってるんだろう

**デフォルトの名無しさん** · 2020/04/02(木) 21:18:47.20

コンパイル時にサイズが決まるならスタックに積んで返すのは難しくないだろう。
今どきCでも構造体を返したりできるし。

**デフォルトの名無しさん** · 2020/04/14(火) 13:45:39.46

老人介護用言語すぎてストレスしかない
なんで今の御時世にこんな微妙な言語使わなければならんのだ
ポインタ意識したりするよりドメイン層の設計に時間を割いたほうがマシだわ
はぁ…

**デフォルトの名無しさん** · 2020/04/14(火) 13:52:00.63

無理して使わんでもええがな

**デフォルトの名無しさん** · 2020/04/14(火) 13:58:34.65

どの言語にも言えるけど
全ては実験台でしかない

**デフォルトの名無しさん** · 2020/04/14(火) 14:26:34.45

権限だけ持ってる考えなしの馬鹿が採用を決めたせいで無理して使うしかないんだわ
トラップ多くてその調査のせいで学習コスト跳ね上がるし
並列処理簡単って動かすだけならそりゃ簡単だろうが…ってレベルの完成度の低さで
CPUフルで使い切るような事やらせようと思ったら面倒さも管理も段違いの面倒さ…

愚痴はまぁともかく、structって脳死して全部ポインタで扱うほうがいいんけ？
というかstructに実装持たせるような意識なんて投げ捨てて旧石器時代を目指すほうが良い言語？

**デフォルトの名無しさん** · 2020/04/14(火) 14:32:51.20

あくまで関数が主体であり、structはオブジェクト指向的な実体というより、単なる文脈と考えればいい
Rustも同様の考え方だし、C#なんかも最近はそういう方向へ進みつつある
善し悪しはともかく最近の流行りではある

**デフォルトの名無しさん** · 2020/04/14(火) 14:38:21.41

>>383
基本的にはちょっと楽なCだからね
まともなC使いは第一引数にオブジェクトのポインタわたしてたし
継承も構造体使って同じことしてた
むしろC使いは理想的な言語を作ってくれた！と思ってる

**デフォルトの名無しさん** · 2020/04/14(火) 17:35:01.14

>>383
CPUフルに使いきるなら素直に別プロセスにして上位レイヤーで分散するよう工夫したほうが結局コスト安く済むような印象がある
まあWeb系じゃないならそうは行かない場合もあるんだろうけど

**デフォルトの名無しさん** · 2020/04/14(火) 17:47:59.69

ハイパースレッディング的にCPUを並列化したいならGoなんで使うものじゃないよ

**デフォルトの名無しさん** · 2020/04/14(火) 17:55:25.26

simulationライブラリで純粋な関数式プログラミングをする
ttp://x0000.net/topic.aspx?id=3631-0

UIライブラリ (C#, 2D) を作ったよ
ttp://x0000.net/topic.aspx?id=3688-0

連続と離散を統一した！
ttp://x0000.net/topic.aspx?id=3709-0

4Dエンジン
ttp://x0000.net/topic.aspx?id=3677-0

matrixのライブラリ
ttp://x0000.net/topic.aspx?id=3711-0

ある強力なFor関数
ttp://x0000.net/topic.aspx?id=3630-0

SQLライブラリ
ttp://x0000.net/topic.aspx?id=3675-0

**デフォルトの名無しさん** · 2020/04/14(火) 21:22:08.02

>>383
コア数分のgoroutineでCPU使ってくれない？なにかそんなに面倒なことあったっけ？

**デフォルトの名無しさん** · 2020/04/14(火) 22:32:46.86

golangのポインタ周りはrangeでイラっとしたくらいだわ
他はわかりやすいし使いやすい印象

**デフォルトの名無しさん** · 2020/04/15(水) 00:46:12.61

いやいや・・ポインタも構造体の実体からもアクセスがどっちも . とか
トラップすぎて草はえるわ
そりゃさだいたいは問題ないよ、だけどな大体のとこは良いけどたまーに
罠にハマるっていうパターンの問題が一番やっかいな罠になるもんなんだよ
そんな中途半端なことするぐらいならいっそハナから面倒なままにしてくれるか
あるいはしょうっちゅう問題が起きるから常に注意して書く必要がある、ぐらい
のほうがよっぽどマシ
GO言語はこの「だいたいいいけどたまに罠」がクソ多すぎてほんとクソ言語だよ

**デフォルトの名無しさん** · 2020/04/15(水) 01:09:47.19

　 /＼＿＿_／＼
／　／　　　ヽ ::: ＼
|　（●）,　、（●）、　| 　　／￣￣￣￣￣￣￣
|　　,,ノ(、_, )ヽ、,, 　 | 　＜　まーたはじまった
|　　　,;‐＝‐ヽ　 .:::::| 　　＼＿＿＿＿＿＿＿
＼　　｀ニニ´　 .:::／
／｀ー‐--‐‐―´´＼

**デフォルトの名無しさん** · 2020/04/15(水) 02:17:30.11

全部ポインタにしてるわ
現代のアーキテクチャからしたら明らかに遅くなりそうだが
C脳だから全部ポインタw

**デフォルトの名無しさん** · 2020/04/15(水) 03:27:51.37

全部ポインタは無駄処理増えてパフォーマンス的に良くないようだけど
そうした方が言語トラップを回避できる可能性が高いって時点でうんこであることは間違いないと思うよ
コードをひと目見てすぐ問題があると判断できないようなトラップが散りばめられてて学習コストが低いとか嘘だわ

インポートも微妙、名前ぶつかりすぎでローカル変数名が半端になっていく
エクスポートの仕様も半端、プロパティとかないから構造体のフィールドは全開放で
扱う側に全責任が委ねられてしまうしパッケージ変数とか公開した日にゃノーガード戦法しかない
その割にリフレクションでの制限だけはクソきつくて非エクスポート関数の参照や値の変更は実質ほぼ不可能
あとエラーもうんこ
goのerrorをバケツリレーしていくような実装って、結局のところJavaでいうところの throws Exception を
全メソッドに書いちゃうようなゴミ実装をより面倒くさい記述にしただけみたいな感じ
エラーの中身が型として読み解けないせいで意識しないといけないスコープが広がりすぎるから超めんどくさい
エラー処理をせずもみ消したいときにtry/catchがいらないみたいな、死ぬほどどうでもいい利点くらいしかひねり出せない

言語の決定権がなく仕方がなく使ってるけど、全てを把握できてて自分以外が触らないような
単機能の小さいツール作るくらいの用途くらいでしか使いたくない言語って感じで、書くほどストレスが溜まっていくぜ…
これを絶賛する人たちが本当に最高だと思ってるのかマジでわからんくなる…

**デフォルトの名無しさん** · 2020/04/15(水) 04:05:18.88

今Go使ってる人はなんちゃっての人は少ないからねえ
まともにGoやってますって人の少なさよ

**デフォルトの名無しさん** · 2020/04/15(水) 07:24:14.59

はて、ポインタで無駄処理ってのは聞いたことないな

アセンブラのレベルから見ると、実体って概念は配列要素へのアクセスを先頭からの相対位置で行うという、限られた局面でしか現れないもの
あ、自動変数の実現としてスタックを積んでスタックボトムからのオフセットを使用するのは一般的ではあるか
ともかく実体渡しはCとかあの辺りの言語で実装された二次的なもので、あくまでポインタの糖衣構文じゃないの？

俺が最近のCPUを知らないからトンチンカンなのかな？
ベクタ計算がプリミティブに使われない限り、よりマシンに近い記述がポインタだと理解しているんだが

**デフォルトの名無しさん** · 2020/04/15(水) 11:39:38.66

せっかくのキャッシュなのに
キャッシュ捨てまくりが発生

**デフォルトの名無しさん** · 2020/04/15(水) 11:42:52.38

ちゃんと読んで答えてるっぽい奴居て草
今君は川に流れてるウンコを態々拾いに行ったのだ
ばっちぃから触っちゃ駄目だろ、ちゃんと反省しろよ

**デフォルトの名無しさん** · 2020/04/15(水) 13:07:39.95

>>220-221

**デフォルトの名無しさん** · 2020/04/15(水) 19:49:21.31

>>399
それが何で遅くなるのか理解して言ってるか？
ポインタが無駄な処理になるからじゃなく、メモリアクセスとメモリ管理を最適化するため
実体配列のニッチな需要があるかぎりは実体は廃止できないという意見

正直、そういう需要なんて切って捨てていいと思う
Javaみたいに

**デフォルトの名無しさん** · 2020/04/17(金) 18:19:15.53

Javaはスレッド跨ぐ場合はスレッドごとにコピーした値をキャッシュしたりはしているし
それで起きる問題を回避するための手段も用意されてる

Goがただ面倒くさいゴミ言語って話でJavaを例えに上げるのは理解してなさそうに見えちゃわない？