[過去ﾛｸﾞ] Go language part 3 (1002ﾚｽ)
上下前次1-新
抽出解除 ﾚｽ栞
このｽﾚｯﾄﾞは過去ﾛｸﾞ倉庫に格納されています｡
次ｽﾚ検索 歴削→次ｽﾚ 栞削→次ｽﾚ 過去ﾛｸﾞﾒﾆｭｰ
ﾘﾛｰﾄﾞ規制です｡10分ほどで解除するので､他のﾌﾞﾗｳｻﾞへ避難してください｡
58: 56 [sage] 2019/10/26(土) 19:00:33.37 ID:WK67sdAG(2/3) AAS
書いた後にアレだが、 >>5555(1): デフォルトの名無しさん [sage] 2019/10/26(土) 17:57:54.28 ID:cnCbS4wm(1/3) AAS
普通にjson.Unmarshal()するだけで、mapになるそうだから
入っていないキーは入っていないと分かるのとちがう？
設定ファイルとか使うコード書いたことないから受け売りなんだけど
のやり方のほうが良い
var persons []map[string]interface{}
394: デフォルトの名無しさん [sage] 2020/04/15(水) 03:27:51.37 ID:j+vnhNUd(1) AAS
全部ポインタは無駄処理増えてパフォーマンス的に良くないようだけど
そうした方が言語トラップを回避できる可能性が高いって時点でうんこであることは間違いないと思うよ
コードをひと目見てすぐ問題があると判断できないようなトラップが散りばめられてて学習コストが低いとか嘘だわ
インポートも微妙、名前ぶつかりすぎでローカル変数名が半端になっていく
エクスポートの仕様も半端、プロパティとかないから構造体のフィールドは全開放で
扱う側に全責任が委ねられてしまうしパッケージ変数とか公開した日にゃノーガード戦法しかない
その割にリフレクションでの制限だけはクソきつくて非エクスポート関数の参照や値の変更は実質ほぼ不可能
あとエラーもうんこ
goのerrorをバケツリレーしていくような実装って、結局のところJavaでいうところの throws Exception を
全メソッドに書いちゃうようなゴミ実装をより面倒くさい記述にしただけみたいな感じ
エラーの中身が型として読み解けないせいで意識しないといけないスコープが広がりすぎるから超めんどくさい
エラー処理をせずもみ消したいときにtry/catchがいらないみたいな、死ぬほどどうでもいい利点くらいしかひねり出せない
言語の決定権がなく仕方がなく使ってるけど、全てを把握できてて自分以外が触らないような
単機能の小さいツール作るくらいの用途くらいでしか使いたくない言語って感じで、書くほどストレスが溜まっていくぜ…
これを絶賛する人たちが本当に最高だと思ってるのかマジでわからんくなる…
721: デフォルトの名無しさん [sage] 2020/09/29(火) 15:53:59.37 ID:ztORdlGy(2/5) AAS
>>720720(1): デフォルトの名無しさん [sage] 2020/09/29(火) 09:38:24.05 ID:rZRnYPTQ(1) AAS
>>719
いや、サイズが大きいのは基本的に可変長であるスライス、string、mapなのだから、それらだけは内部的にポインタを持って実質的に常にポインタ渡しとなるようにしておけば、常に値渡しでもパフォーマンス的にほぼ問題にならんだろうというのがGoの設計意図だよ
個人的には、同一の実体として振る舞うようなOOのインスタンスに近い性質の構造体はポインタ渡し、単なる値の寄せ集めは値渡しとして使い分ける
ググってみたら、goではスタック足りなくなると拡張すんのか……すげーな
827: デフォルトの名無しさん [sage] 2020/11/01(日) 22:45:13.37 ID:xkjSw6A1(2/2) AAS
わざわざgoスレに乗り込んできて何がしたかったんだろ
851(2): デフォルトの名無しさん [sage] 2020/11/03(火) 02:20:11.37 ID:irabVcQc(1) AAS
疲れてるのに長い文章読む気もおこらんから読んでないが
>>847847(2): デフォルトの名無しさん [sage] 2020/11/03(火) 00:10:32.82 ID:OQJ1TfTq(1/11) AAS
>>846
そりゃご丁寧にどうも。
ただ、今ここで話した限り、以前の印象「Go使いはC++を使えない馬鹿」ってのを再認識したけどな。
C++も無駄に複雑になって、しかもそれを使いこなすのが目的みたいな勘違い野郎がネット上には増えてるし、
あれはあれでおかしな事になってるが。
ただGoはちょっと立ち位置が悪い。
「端の言語」はとりあえずは生き残れるんだよ。Goはどの面もそこに該当しない。
今なら「最易」枠がPHP/JS/Python。
「最速」枠がC/C++。
「堅牢」枠がJava。
中庸といえば聞こえは良いが、実際に積極的にGoを選ぶ理由がない。
上記の言語はそれなりに糞だと分かってても最○を求めたら他に選択肢がないから選ばれる。
だからのさばってる。
goroutineの思想は確かに面白いが、今はそれを生かせるハードがない。
そしてそのハードを開発させるほど影響力も大きくない。
(ただしGo向けハードウェア開発自体は簡単だから、やる気になればすぐ出来るが)
あとはgenerateだね。
ただしgenerateが向いてるのは下地の言語が全機能を持っている場合であって、(つまりC++)
Goみたいに綺麗に制限されてる言語には向いてないんだな。
だけ読んで俺は基本的に同意の人間なんだが・・
ちなみにわしはC++が一番好みで最初の数行に同意なんだが
複雑すぎるとか難癖つけるやつが多いがC++が今の形に発展したのには理由がある
哲学、美学先行で必要もなくわかりにくくしているわけではない実用が最優先言語なのだ
Go も正直なんでこんな流行してるのか今一理由がわかんない
これ使うくらいなら既存言語を用途にあわせてチョイスすりゃいいじゃん、ともおもうが
まあ小型のプログラムをサクサクと書くには便利な言語だね
ただし、Go は名前がクソ
あとエラーハンドリングはなんとかしろわりとマジで
931: デフォルトの名無しさん [] 2020/11/05(木) 22:41:27.37 ID:BWbga0la(2/2) AAS
>>919919(1): デフォルトの名無しさん [] 2020/11/05(木) 17:50:15.36 ID:goPbZhqC(1) AAS
>>914
F#とかどうよ
外部ﾘﾝｸ:qiita.com
高速な動作, 簡単な配布
・.NET Core は現状で最も高速な .NET 実装の1つで, ベンチマーク上では例えば Go とほぼ同等〜少し速い程度のパフォーマンスを発揮します.
・.NET Core は Go と似たようなスタンドアロンバイナリの生成をサポートしており23, .NET Core ランタイムがインストールされていない Windows / OS X / Linux 環境上で実行可能な状態で配布することができます.
F#いいよな。
でも ocaml も流行ってないしなぁ。
ocaml は歴史もあるし金融系で使われてたり実績も十分そうなんだけど。
951: デフォルトの名無しさん [sage] 2020/11/11(水) 16:24:39.37 ID:2YRRcyS5(1) AAS
Typing [Generic] Go
外部ﾘﾝｸ[pdf]:www.dropbox.com
上下前次1-新書関写板覧索設栞歴
ｽﾚ情報 赤ﾚｽ抽出 画像ﾚｽ抽出 歴の未読ｽﾚ AAｻﾑﾈｲﾙ
ぬこの手 ぬこTOP 0.041s