[過去ﾛｸﾞ] Go language part 3 (1002ﾚｽ)
上下前次1-新
抽出解除 ﾚｽ栞
このｽﾚｯﾄﾞは過去ﾛｸﾞ倉庫に格納されています｡
次ｽﾚ検索 歴削→次ｽﾚ 栞削→次ｽﾚ 過去ﾛｸﾞﾒﾆｭｰ
57: デフォルトの名無しさん [sage] 2019/10/26(土) 18:56:16.09 ID:ZMkO6rZZ(1) AAS
LTSVに
外部ﾘﾝｸ:play.golang.org
Golang初めて1週間未満なのでいろいろあれかもしれんが
110(1): デフォルトの名無しさん [sage] 2019/11/25(月) 22:24:43.09 ID:ELiIkdft(1/2) AAS
>>109109(2): デフォルトの名無しさん [] 2019/11/25(月) 21:36:43.85 ID:aLYZ9MFJ(1) AAS
初心者なんだがcontextの使い道がいまいちわからん。
cancelとかなんかいいサンプルないかな。
パッケージドキュメントのExampleが、自分としては分かりやすかった
WithCancelしか使ってないけど
あと、go vet がバグっていて親contextのCancel関数があるのに
子供のCancel関数を_で捨てると怒られる
外部ﾘﾝｸ:github.com
暫定的な解決法は一旦変数に取ってから_に代入
263: デフォルトの名無しさん [sage] 2020/02/03(月) 20:45:13.09 ID:eCgFnDlS(1) AAS
間違ってたらコンパイルエラー出るから、コンパイルエラーが出ないほう
呼んだ先の関数の引数の定義をよーく読め
でも、実際に渡している方の部分を見て書いてる可能性もあるか……
インターフェースの配列を受け取る関数だとすると、どちらでもコンパイルエラーは起こらない
ぶっちゃけ、その場合はどちらでも構わないことが多い
[]xxxxは、xxxxがインターフェースでなく構造体だったなら、十中八九はバグだと思う
バグでなく意図的に使うケースもありはするけど………………
357: デフォルトの名無しさん [sage] 2020/03/29(日) 09:36:10.09 ID:ryRl/n6a(1) AAS
>後で扱うデータの仕様変更があってエラーハンドリングが必要になったときに
>ガッポリその部分覆ってまとめてエラー扱うってのが一切できないんだよな
これ自体が例外ありきの発想のように思う
475(1): デフォルトの名無しさん [sage] 2020/05/08(金) 16:04:03.09 ID:SpWQlQbz(1) AAS
言語仕様より標準ライブラリのクックブック的な本が充実して欲しいかな
結局Goのソースやテストコード読まなきゃ使い方がわからないのが多過ぎるし
600: デフォルトの名無しさん [sage] 2020/05/26(火) 07:48:46.09 ID:FE3JTR8c(1) AAS
過ぎたるは猶及ばざるが如し
671(1): デフォルトの名無しさん [sage] 2020/07/05(日) 18:02:06.09 ID:gmGxEZ+k(1) AAS
いいえ
716: デフォルトの名無しさん [sage] 2020/09/11(金) 20:12:33.09 ID:ICNKkV5S(1/2) AAS
GitHubかGoogleSourceRepositoryにホストすればいいのにな
737: デフォルトの名無しさん [sage] 2020/10/07(水) 08:43:42.09 ID:9tAnRZjq(1) AAS
Pythonでマップのインデックスで {(a,b): c} とやってるのを見て、ちょっと羨ましく感じた
Goだとタプルは型じゃないもんな
774(1): デフォルトの名無しさん [sage] 2020/10/31(土) 17:32:11.09 ID:Zi1/vk95(1) AAS
>>771771(2): デフォルトの名無しさん [sage] 2020/10/31(土) 16:39:03.74 ID:o6XGTKTG(1) AAS
つーか名前をへんてこにして誤魔化すとかじゃなく
リアルにポインタの概念(何かのオブジェクトを指す変数)を消し去ろうとしたら
あらゆるものをコピーでもっといてしかもそれらを常に同期して同じ値になるように
常に維持する仕組みにするしかないがそんな非効率きわまりない言語が実用に値するはずがない
全部イミュータブルにすりゃいいんだよ
コピーと参照渡しを区別する必要がなくなる
881(2): デフォルトの名無しさん [] 2020/11/04(水) 00:15:06.09 ID:BNFfXKWA(2/4) AAS
>>876876(1): デフォルトの名無しさん [sage] 2020/11/03(火) 22:46:43.82 ID:OQJ1TfTq(11/11) AAS
>>866
ついでだから本家の方読んできた。
まずそもそもReadStatesをそんなにバカスカ更新するようなアーキが必要なのか？という疑問はあるが、
それはさておき。
これは、多数のオブジェクトを「生存したまま」でメモリを埋める、
つまりオンメモリDBのような使い方をするアプリとGCが絶望的に相性が悪くて、それに該当した、ということなのだろう。
これはGoがショボイというよりはGCの限界で、C++/Rustしかねえわな、ということだと思うよ。
JavaでもC#でも同じ結果になる気はする。
だからそういうアプリでGC言語使っちゃ駄目、というのが教訓だと思うよ。
まぁーやっぱ、gcってよくねーわ。
捨てる前提のプロトタイプにはgcあり言語もよいと思う、ほんで大部分の案件はそれで十分ってのもあっる。
げももっと性能を、、、てやると今なら c/c++/rust の3つしかナイショ。
990(1): デフォルトの名無しさん [sage] 2020/11/15(日) 19:05:53.09 ID:uPufg4Im(1) AAS
モダンな言語使ってる所だと単価云々より労働環境のメリットの方がデカい
エンジニアファーストだしフルリモート出来るし
単価高くても出社必須・クソスペPC・下請けみたいな所は論外
上下前次1-新書関写板覧索設栞歴
ｽﾚ情報 赤ﾚｽ抽出 画像ﾚｽ抽出 歴の未読ｽﾚ AAｻﾑﾈｲﾙ
ぬこの手 ぬこTOP 0.039s