Go language part 5
>>992 （前スレ） >>998 （前スレ) >>986 (前スレ) ちなみに前スレ1000と同じく、1桁少ない1000スレッドで同じPCでgoを測ると 推奨NGWord >>992 （前スレ） https://github.com/tinygo-org/tinygo/issues/2000 https://dave.cheney.net/2014/06/07/five-things-that-make-go-fast https://dave.cheney.net/2013/06/02/why-is-a-goroutines-stack-infinite 関数呼び出しのオーバーヘッドだけど、高階関数らしい高階関数も無いしそういうややこしいことはジェネレーター使う文化だと思ってるな。Genericsが本流になってきたらどうする気だろうもも思ってる。 https://github.com/golang/go/wiki/CompilerOptimizations >>9 https://go-tour-jp.appspot.com/moretypes/25 >>6 https://github.com/golang/go/issues/7514 https://github.com/golang/go/blob/go1.13.8/src/runtime/stack.go >>12 >>13 >>11 >>15 >>14 https://stackoverflow.com/questions/7880784/what-is-rss-and-vsz-in-linux-memory-management https://commons.wikimedia.org/wiki/File:Table_of_x86_Registers_svg.svg >>12 >>15 >>19 >>16 https://doc.rust-jp.rs/book-ja/ch09-00-error-handling.html template feature実装したgolangのstable公開3月だっけか >>17 >18 >>4 で再び「957のベンチでは40MB越えないとおかしくて、矛盾してる」と言ってるのが、普通に考えるとRSS対象なので、スレッド数を10kから1kにした俺版でも前スレ1000のC++版との対比する意味もあり、改めてgo版の結果を同じ条件で出した(>>6 )だけ。 >>12 で結論としては2Kだったということ。 >>14 で/procに頼った。 >>21 一般には このasyncおじさんは何も分かってないと思う・・・ async/await,そしてyieldが唯一優れているのは、Goでいうchannelのclose処理が要らないことだけ。 >>27 >>27 >>28 Rustでもできる、は聞き飽きたんだが、Rust話がしたいのか？ >>31 >>32 >>23 https://dave.cheney.net/2014/06/07/five-things-that-make-go-fast >>27 ,28 https://codeburst.io/why-goroutines-are-not-lightweight-threads-7c460c1f155f#396b >>35 >>33 >>37 >>38 >>39 >>41 >>39 >>43 >>44 https://jsfiddle.net/9b0kujsL/ >>38 >>46 >>46 https://github.com/golang/go/blob/master/src/runtime/runtime2.go#L403-L498 https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/include/linux/sched.h#n657 ここら辺はやっぱりチューニングが狂ってる。 OSがそれなりにさばかないよ。グリーンスレッドの価値を全否定だな。 https://jsfiddle.net/z1bvwt3L/1/ >>55 >>57 Rustの標準ライブラリはunsafeのオンパレードだなｗ ライブラリもOS機能を使うならunsafeも致し方ないのではないだろうか、と誤爆にレス >>58 >>63 >>64 >>64 C++スレでもRustスレでもここでも同じで無意味 thread単品で制御できないgoじゃこういう計測ができないのも理解できないとは・・・ C++とRustでもOSスレッドではなくm:nグリーンスレッドを使えばよいだけだろ >>64 >>54 チャンネルが同期なのはバッファが無いとき >>71 Windowsでアップデート後にVScodeでテストを走らせると1.14.13でコンパイルされてるためツールバージョン1.17.7とマッチしませんと言われる いや…落ち着いてエラーログを見たら、例えばruntime/internal/sysが、とか言ってる とりあえず全部をアップデート先に統合する方向で納めた >>74 >>74 >>58 ) >>73 https://zenn.dev/hsaki/books/golang-concurrency/viewer/chaninternal Docker CLIのダウンロードみたいな >>64 rustはもう少し標準ライブラリにも機能増やして欲しい。 >>88 非同期処理ですら紛糾して仕上がったのが2019/11な赤ん坊に無茶言うなって そんなにライブラリ貧困なの？ >>91 >>91 >>92 間違ってる上にスレ違いすぎるな https://mevius.5ch.net/test/read.cgi/tech/1638086359/ >>96 >>95 >>99 >>102 そうだね https://pkg.go.dev/golang.org/x/exp/slices https://gotipplay.golang.org/p/Y2cpCCPjKqr 他のインタフェースが検討されてるとしたら、メソッドチェーンできるようにしたい、とかかな？ GoスレでRustRust言う奴から得るもんは何もない >>106 >>105 の実装のように毎回スライスを生成するのは無駄で遅いから たしかに効率的にするならイテレータにしないとね 今一番rustの話で盛り上がるのがこのスレだからな >>113 >>110 >>40 Istioがまさにそうだよ フリーランスだけど未経験OKのところに応募してみた。 >>117 >>117 >>122 >>123 RustあげてるやつがRustの良さを何も理解できてないのがホント阿呆らしい >>124 >>127 >>127 >>123 >>123 >>132 >>129 コンパイラの仕事が何なのか知らない人がRustを推すのは流石に恥ずかしいからやめてくれ >>134 やはりおじさんはVM系言語しか使ったことがないようだな GoスレでマヌケなRust推しが暴れているという地獄 Rustの方が言語機能の強力さや高速性と省メモリ等の点から最も有利なだけにすぎないからね いわゆるVM系の言語(Java、C#、JavaScript、Python、Rubyなど)はランタイム自体がインタプリタに含まれてるので意識しないんだろうな なんでここまでボロが出る前にスッとROMに徹せられないんだろうね？ Rustのことは忘れて struct の中にスライスと長さを持たせてたよ…orz RustのスライスとGoのスライスは概念が異なる >>148 Goのスライスはうっかりデータ競合を起こしても自己責任 Goのスライスは実質的には可変長配列として使うからね 嘘つきはRustの始まり。std::syncだって同期とが標準モジュールに入ってるし、atomic型だって同じ。並列操作ではgoは他の refrect.DeepEqual() って便利 Javaやpythonからgoに来た人って絶対Rustにも行くよね?w 皆さんストリンガーって保険のためにとか実装してる？ 別にRustを使ってもデータ競合は防げるけど競合状態は防げないし、データ競合を防ぐ目的のために面倒なメモリ管理をやる気にはならないな >>151 >>162 今からGoですを勉強するのって意味ない？ Goの採用はスタートアップなんかでも結構多いので意味無くはない >>164 Goの戦場はニッチだからねぇ Java, C# は使えて当然、C++が分かるなら誉めてもらえる >>164 goは言語自体はあまり面白くないからね みなさんありがとうございます。 >>164 >>166 の言う通りケースバイケースすぎてなんとも Goは文法だけなら超簡単だけど >>171 >>171 https://xn--97-273ae6a4irb6e2hsoiozc2g4b8082p.com/%E3%82%A8%E3%83%83%E3%82%BB%E3%82%A4/%E3%83%97%E3%83%AD%E3%82%B0%E3%83%A9%E3%83%9F%E3%83%B3%E3%82%B0%E8%A8%80%E8%AA%9E%E3%81%AF%E8%A4%87%E6%95%B0%E7%BF%92%E5%BE%97%E3%81%99%E3%81%B9%E3%81%8D/ >>176 も>>177 も勧めてるけどC言語は基礎教養として必須 >>178 >>180 ウェブ業界にいるんなら、Rustの案件は将来も少ないだろうし、 >>171 が仕事で使う目的で学ぶっていう意味でいうならGoのほうがええやろ >>182 >>180 >>181 >C++は元々「必要な機能を選んで使う」思想で、 >>184 >>185 >>186 このおっさん勢いあるスレならどこでも湧くな。そして偏った知識で見境なく喧嘩ふっかける。かまってちゃんが過ぎる。 >>187 >>189 >>190 >>191 >>192 次スレまで待とうかと思ってたけど流石にワッチョイスレ作った方がいいか？ >>193 https://blog.discord.com/why-discord-is-switching-from-go-to-rust-a190bbca2b1f?gi=bd6f6b9c5be3 >>196 VScodeで自前のパッケージを使おうとしたら、importの追加のクイックフィックスが出ないんだけど あ、違うわ 外部パッケージの参照の仕様はまあ仕方ないんだけど ディレクトリ名とpackageでの宣言、二重に記述しないとまともに動かないパッケージ名ルール ITの9年は長いでよ、ロートルには短いかもしれんが。 >>202 https://japan.zdnet.com/article/35174333/ https://thenewstack.io/rust-in-the-linux-kernel-good-enough/#: ~:text=When%20we%20first%20looked%20at%20the%20idea%20of,the%20standard%20C%20normally%20used%20in%20Linux%20development. Rustスレで相手してもらえないからってこっち来るの止めてもらっていいですか 何を勘違いしているのか知らんが、俺のこのスレの直前の書き込みは>>104 cppの話はcppスレでやれよ。 gcnewってなんだこれ、.Net専用とはいえなかなか邪悪な代物だな…… >>196 最近他のどのプログラミング言語スレいってもRustの書き込みあるな >181 >186 >187 >190 >191 >193 >196 >197 >202 >203 >208 >210 >>96 >>96 読んでみたが、なるほどここと同じような話が展開されてる。 >>202 https://mevius.5ch.net/test/read.cgi/tech/1638086359/542 https://japan.zdnet.com/article/35184296/ >>208 >>207 >>211 >>212 >212 >213 >214 >>96 >>217 >>218 標準的なソースコードを集めたコードサンプル集とかあればいいんだけどな。 ハイエンドというほどじゃないが、みんなのGo第二版はよく参考にしてる テーブルドリブンテストはなんか標準かでGenerateされるようになったね テスト対象の呼び出しまで完璧にサポートされてて便利すぎる ジェネリクス使ったmapやsliceのユーティリティが乱立するのかな やっっっとジェネリクス医薬品きたのかよ >>225 >>229 GoCVのWindows版一生動作しなくて泣いてる >>231 今更案件に採用したいとの連絡が来やがった。 go案件一回だけ行けたことあるけど もう go modules 無しで開発できる自信がない… 構造体のブランクフィールド 1.18 で ~T って、T を実装している型という認識で正しいのかな？ 1.18 の言語仕様読んでるけど >>239 これからガンガンでかくなるはずなので、これに耐えられないなら早く逃げてくださいね >>239 >>242 >>243 >>244 >>245 あと珍妙に思えるような気もしなくもない文章が >>245 プログラム作る側からすると便利なライブラリが増えるからいいと思うわ map/reduce/filterみたいな操作をたくさんするとき、マジで面倒だったしジェネリクスあればいろんな場面で助かる >>247 >>251 とにかく読みづらい仕様書になっちまった！ そうですね システムプログラミングしかしてないので Goでコレクションなんか使うか？ >>248 >>258 >>259 >>259 >>261 たまには仕様書も読みなおすと新鮮 日本の製造業何十社から、トップが集まった、MISRA-C 研究会でも言ってた >>266 最近マシにになったと思ったが我慢できないのかな？ >266 >269 >270 >>274 定数、変数、型やらの基本的な言語仕様で型パラメータやらコア型とかのジェネリクス関連の概念も持ち込んで記述する必要がある >>277 Goの長所はシンプルさ ロブパイクが実質リタイアしたから通ったんじゃないかな 一応、大昔からジェネリクスは入れるとロードマップで予告はされてた ジェネリクスなんていらん、ていってるやつのほとんどがロートルジジイばっかりでわらう いや、ジェネリクス導入が遅すぎたこととそれが中途半端であることを問題視する人々が多数派 コンパイラの実装を大幅に変えなくていいから 大体がJava5でジェネリクスが導入されてから、自分で書いた奴ってどれくらいいるの？ golang.org/x/text/encoding/japanese でshiftjisをデコードすると コードを見ても変換失敗時にエラーを返すロジックないし https://go.dev/play/p/8ALF1MMIQPz だめだplaygroundのURLがどこで間違ってるのかわからん playground側の問題かもしれんね https://github.com/golang/go/issues/18898 >>293 >>285 golangの機能追加によるビルド速度低下なんて他の言語のコンパイルの遅さに比べれば毛の生えたようなものでしょ・・・ 否定的意見じゃないんだけど 速度的にはキャッシュに乗る乗らないとか色々ありそうだから そんなわけない、レジスタに乗らないデータは普通にスタックポインタレジスタでスタックに格納される。golangが 関数の引数をレジスタ渡ししても たしか処理系がどのABIを採用しているのかによるんだと思うし、そんな十把一絡げにC言語やらの話を一般化されて話されてもツッコミどころが多い 少なくともLinuxのCでは第6引数まではレジスタで渡すよ cみたいに他からも呼ばれるような言語の場合はスタック積みじゃないかね。 開発者が実装が簡単だったからと言ってるのでレジスタ数とか、GCCの第六天の魔王とか関係ないよ 開発者が実装が簡単だったからと言ってるのでレジスタ数とか、GCCの第六天の魔王とか関係ないよ もう30代くらいの若いお父さんだと菖蒲湯知らないんだな 漏れら極悪非道のageブラザーズ！ GoLandとか使ってる人いるの？ つまりGo以外も書けるGoLandは効率的ということ ちょっとVSCodeに不満を感じてなくて他に目移りしてないんだよな 最近まともなレスが無いけどGoってやっぱ廃れたんだね yoshikiはもうx japanのアルバムは出せないみたいな事言っちゃったしな >>321 もうGoは終わりだな 俺はGo使いからC使いになるよ _ ー――--＿ .＿ ／⌒ヽ GopherくんがキモすぎたからGo言語廃れちゃった…… 見たことあるなと思って検索してみたら2012/06か (ｏﾟДﾟ)＝◯)`3゜)∵ ていうかさ 10年ぐらい前なら美少女化とかしてイラスト描いてる人いそう D言語のマスコット凄くかわいかった マスコットはネタになるくらいだしまあどうでもええけどな 地溝油 Rustスレ→毎日論争が起こるぐらい盛り上がってる >>294 言語仕様をそれなりに語れる言語って実質rustしかないからな いつの間にか世間じゃ1.18の時代なんだなぁ このスレって何を語るんですか？ 今は色んな現場に数年前にGoで作られたLambdaがたくさんありそう Goは互換性高いからいきなりランタイムのバージョン上げてもまず問題ないでしょ AWS の Lambda Node.js runtime の EOLに疲れたのでGoにしていってる話、とかあるね AWS側でランタイムの検証負荷が高いって話？ いや、Go だけ特殊でLinux用にコンパイルした実行イメージをzipしてデプロイするのと、Lambda実行環境との依存がnet/rpcという枯れた技術しかない Lambdaはコンテナイメージがサポートされたから他の言語も塩漬けできるようになったけどね Genericsが出て暫く経ったので聞いてみます。ʕ◔ϖ◔ʔ >>383 https://github.com/samber/lo >>385 AWS Certified Developer - Associate の教科書に書いてあるけど、 >>386 https://github.com/elliotchance/pie >>388 goはそもそもエラーを扱う気概にかける言語だからどうしょうもない >>390 >>388 Rustも例外が無くエラーを返す点でGoと全く同じだが 例外はgotoと同じだぞ Goにあと20年のキャリア賭けてみても大丈夫かね。 >>394 >>392 >>397 GoはそもそもGCがあってランタイムが重たい高水準言語で、ローカル変数でも必要ならヒープに確保するし、 アホか、レジスタ数が限られてる現代未来において必要ならローカル変数なんかヒープやスタックに確保するのは当たり前だ。 Rustは低レベルなシステムプログラミングに使えることが目的な特殊な言語なので >>397 >>388 で実現されてるのはこのレベル1までだね。 >>397 >>388 にはEachがあるよ。エラーを扱えない欠陥品だけど。 半分禁じ手に近いけど、deferでrecoverするという手も無くはない >>402 >>405 >>406 >>407 >>388 のライブラリがヘボいと言っているだけだ Goならyieldみたいな妙なことしなくてもgoroutine内でループしてチャネルで送りつければいいだけだもんな 妙でない==基本的な機能の中で説明できる >>405 無限リストって実際に無限長の何かを使うことは滅多になくて、あくまで遅延リストとして適切に実装されているかどうかの判定基準なんだよね 結局2種類のうちどちらを選ぶか、だけの問題 Go 2のProposalを見ると https://go.googlesource.com/proposal/+/refs/heads/master/design/43651-type-parameters.md >>415 >>414 の(A)のスタイルのイテレータを導入する可能性は下記の通り肯定している >>416 >>414 の(A)がGoでも出来るようになる可能性が残されていると >>417 >>418 >>419 >>421 >>422 イテレータを使うようにしたら、こんなふうになるのかな？ https://github.com/Soft/iter RustのイテレータがCのfor文と同じ速度が出るのも最適化された設計と実装によるものだもんね >>424 何をどう見ても許されてないしロシアが核持ってなかったら、 >>409 おじさんがくるとこうなるのね モックって何使ってる？ >>435 に一票 カバレッジ100%目指さないの？ 別におすすめじゃないけどgomock使ってる がーん、週明けで確認したらGCPでホストしているサービス二個ともが、のきなみサーバーエラー500で動いてない Firestoreのクエリ結果をキャッシュしてるから確かに使ってる あ、よく考えたらGoスレではスレ違いな話題だったスマン 質問 あー、テストで xxxx をインポートしてる別パッケージをインポートしたいときに、xxxx からじゃ循環参照としてコンパイルできないから意味はあるのか ごくまれに package xxxx_test を作ったほうが簡単に解決できることもあるね *bufio.Scanner とか *os.File といった、interface じゃなく struct な戻り値を返す標準関数で、scanner.Scan() とかの戻り値による分岐をカバレッジしたい そもそも例外なケースのカバレッジのために、そんなクソ複雑なメカニズムを入れるのは、保守性を下げてしまうから本末転倒だろうか？ Go的には、差し替えが必要なんだったらScannerを直接使わずに最小限のアドホックなinterfaceを定義し、 >>448 https://pastebin.pl/view/d979ea5b >>449 >>450 そうだな、設計の話だなあ 普通に自前でScanner作れよ 構造体のコンストラクタのコードを見ると必ず構造体のポインタを返していますが、ポインタにするメリットと値を返したときのデメリットを教えて頂きたいです >>454 >>453 >>449 見れば分かるがファイル名を受け取ってos.Openして得たFileからScannerを作ってるわけで、これをどうやって差し替えるかという話 >>453 >>455 コンパイルするファイル内に設定値も全部入れたいんだけど、 jsonファイルをgo-assetsとかgo:embedで組み込んで、それをjson.Unmarshal()で構造化データとして使えばいいと思うよ 個人的には設定はビルド時に埋め込むならソース内にjson風にハードコードする派 組み込みjsonをデフォルトとして、カスタム設定ファイルは外部のjsonにする >>463 >>464 >>464 そんなにバグが怖いならそもそもそんな柔軟な設定ファイル要る？というところを見直すべきでは バグが怖いというより、適切なアナウンスかな フレームワークのginでWebアプリ作りたいなと思ってるんですけど、ginの勉強にいい教材ありますか？ https://gin-gonic.com/ja/ gin自体が良くないからいい教材なんか無い いやGinでいいだろ gin、chi、echoどれも薄っぺらいんだから対して変わらない 月額報酬が最も高い開発言語ランキング 3位は「Python」、2位は「Go」、1位は？ フリーエンジニア向け仕事仲介サービス調べ Goは単価高いけどGoだけ出来ればいいってわけじゃないからなぁ Goのmapをfor分で回すと順序が不定というのはなんでそうなったの？ >>483 Rubyとかは逆に不定じゃなくしたよね。いつだったかのタイミングで。 Rubyの連想配列(Hash)にはshiftっていう変テコなメソッドがあるせいかなあ RubyやPythonの用途なら挿入順でイテレートできるようにするためにかかるコストよりも Go 1.19 is released! https://go.dev/blog/go1.19 Pythonはordered dictがいつの間にか標準dictになってたな 最近の言語仕様書はDeepLすら受け付けない英文なのはどうにかしてくれんかな ふと >>473 実際goをつかいはじめのころはチャンネルの仕様とか使いかたとか調べるのが面倒で gin → beego → echo → chi イマココ 言語仕様書の1.17を底本として翻訳してるんだけど、文書的に酷い(～;～の使いすぎが特に…)し、構成的にもクソだなぁ 仕様書なんて熟読しなくても、フィーリングで書いて動いちゃうから、今まで気にしたこともなかったし そんないいかげんな感覚で思い付きどんどん拡張したその結果が今のC++のていたらくだ！！ C++があんなことになったのはむしろ、C++プログラマたるもの仕様書くらい熟読しているだろうと開発陣が高を括ってきた結果だろう あんなブ厚いARMを読むなんて苦行が過ぎる あるえー？ そもそも規格化されてる言語じゃないし、コミュニティが用意した言語仕様書にそこまで大きな意味はないんじゃないの？ そうか？Googleの割にはまともだったから普及したんだと思うぞ Rustほど初心者が書きにくくはないし だがバグらないために気を付けないといけないことが多い なんかしらんけどGoがしんどいなら使わなくてもいいんだよ バグらないために気を付けなきゃならんことなんて、他の言語に比べるとそんなに多くないだろ 言語設計でしくじってるよなぁと思うのは、構造体の生成回りの構文というか思想 欠点を挙げる流れだ 複合リテラルとして書けばいいんだし、落とし穴的な問題はなくない？ >>520 >>518 >>522 データ競合はあまり遭遇したことないな >>522 きつい現場のGoは他の言語より殊更きつそうだというのはわかるわ channelは複雑なデータのやり取りに使うには難しすぎると感じるね いや、Goに限らない問題でGoのダメなところとか言われてもなぁ いや、けっこうGoに限った問題 例えばCとかでファイルを排他オープンしたままクローズし忘れて書き込みのままになってて、別の箇所で読み込もうとしたけど開けなかったとして >>531 >>531 >>531 >>532 いや普通に同期を取る使い方もできるだろw そもそも本当にパイプとしてストリーム的にデータを流す必要のあるケースなんて稀 そもそもストリームモデルが必要なユースケースってほぼ 分散環境なら外部のメッセージバスに投げるだけだよね >パラダイムのミスマッチなchannel >>541 >>533 の通りで、channelはストリームでありfutureではない、ってことだ。 >>536 >>542 >>535 で書いたけどsync.WaitGroup使ったらどうだ？ パラダイムのミスマッチという理由がわからん。 >>542 >>544 >>545 >>520 の状況なのが事実だよね >>548 まさかこのスレにホーアのCSP本読んでないやついないよな？な？ >>550 >>547 >>547 Goがpromise(future)/async/awaitをサポートしてくれれば今より容易に安全に書けるケースが増えるのは事実だが、 結局ゴルーチンの実装が中途半端だったんだろうね またGoの言語仕様にも問題があった マルチコアを効率よく使うってのがそもそもコンセプトで作られたんだがNodeみたいにしろって意味わからん Goのようにマルチコアを効率よくスケジューリングできて >>558 Goのモデルと比較してのpromiseの優位点としてはこんなとこかな うーん今の時代にpromiseの利点を理解できない人がいるとは驚きですが仕方ない出血大サービスだ >>562 次にpromiseの利点について つまりpromiseがあれば全ては安全に解決される そりゃpromiseでも共有メモリ触ったり外部のリソースをロックしようとしたりすればデッドロックするでしょう >>560 >>565 >>567 ぐちぐち言ってきたが >>568 Nodeしかさわったことないから詳しくは知らんけどasyncawaitモデルだと >>573 >>574 >>575 ユーザーに見せてるのは全てブロッキングなコードなわけじゃん Node/Denoの作者も同じこと言ってるし、async/awaitモデルの方が優れている一言も言ってないな https://mappingthejourney.com/single-post/2017/08/31/episode-8-interview-with-ryan-dahl-creator-of-nodejs/ >>577 >>574 の うんだからユーザーに見せるコードが同期的なことろがわかりやすくて良いって言ってるんだけど？最初その話してたよね？同期的なコードって言ってるよ？ >>576 C10K問題から非同期が流行ったのに、メモリーを使いまわしてたら意味ないのでは？ ウェブ・サーバーが静的なファイルを送り出していた2000年ごろなら非同期が大それた力だっただろうけど。 昔より回線が安価になって接続数が多くなったんだから非同期が必要でしょ 静的なファイルを送るだけなら。 >>563 のここがよく分からない >>566 えっ？もしかしてこの人 >>574 >>587 >>574 >>566 >>588 >>591 今回は実装の話だからサーバー上なら今どきは非同期で実装で合ってると思うよ >>593 上では良いことだけ書いたけどif err != nullはもうそろそろダルいので何とか手を打ってほしいわ きめ細かい制御してるか？ きめ細かいGoのpipelineって、もしかしてGoあんまり書けないのでは…？ きめ細かいでしょう？ https://go.dev/blog/pipelines >>598 >>593 意味わかんね >>566 では promise の利点をこう書いてた >>593 や >>598 が goroutine とチャネルで簡単に実装できるって言ったら >>605 >>607 promiseって普通awaitするのが普通だよね？ >>608 >>607 >>608 まあasync/awaitのほうが初心者に対するハードルは低そうな気はする async/await手軽で簡単だけど複雑なことやろうとすると難しい >>611 promise の利点まとめ >>605 にとってだるくない。 非同期で順列な処理やる場合はasyncのがわかりやすい promiseに似てるけど、全く違うものはerrgroup.Groupと呼ばれます。これもpromiseなんぞと比べれば https://pkg.go.dev/golang.org/x/sync/errgroup#example-Group-JustErrors https://pkg.go.dev/golang.org/x/sync/errgroup#example-Group-Parallel https://pkg.go.dev/golang.org/x/sync/errgroup#example-Group-Pipeline 結局何がChannelに無くて、何がPromiseでしか解決できない問題なの？ >>617 やはり頭がバカ以前のGより脳が小さい、上の人はサンプルをシンプルだとは上でも言ってないが まずは基本的に、シングルスレッドの場合とマルチスレッドだが共有データを使用しない場合は原理的に >>611 が「promiseの方が明らかに楽でバグが生まれない」と言っているのはそのどちらかに帰着するケース。 ストローマン連呼する人が最近5chで増えたと思ったけどこの動画が原因なのねん そもそもGoは何もしなくてもマルチスレッドなんよ。 >>617 JSのPromiseしか知らないんだな 内容ゼロのワイ賢者や煽りに煽りで返すスタイルｗww ストローマンって本題から離れた部分を、わざと誤解して上げつらう詭弁の手法だから、自己紹介してるんだよ うぬぬぬぬ、issueに送るべきだろうか？ >>634 >>634 >>638 >>639 インターフェース型変数という訳のわからないものを導入したのがそもそもの間違いなんだよな で、なんでそんなもんを導入したかというとそもそもジェネリックスがなかったから 理解できないから人格攻撃に出るあたり、お里(国)が知れるというもの いきなり国がどうとか言い出す人って日常会話出来るのか気になる インタフェース変数は普通に色々な言語にあるだろ？ >>636 >>648 func (e *elem) String() string 仕様書にポインタ変数.は勝手に*(ポインタ変数). >>651 ポインタと値レシーバーは特に注意しなくても相互にセレクタとして呼べるんで気にしていなかったんだけど、ポインタでストリンガーを書いたらfmtパッケージの関数では認識してくれなかった まだfmtパッケージの中は見ていないけど、ポインタレシーバーで書くと型スイッチかリフレクションではインタフェースを満たしていないと見なされたりするんじゃないか？とか不安になってきた な、仕様なんてこいつ読んでないだろ？5chぐらいでしか自分の連投でしか意見言えない >>655 理解できない Promise最強ストローマンおじさんw なんか勘違いしてるけど相互運用ではないよ >>659 >>659 >>659 まあ、こんな感じにぜーんぶ読み通さないと系統だった仕様の把握ができそうにない、という点で、かなり品質は良くないんよ 仕様書の全訳に挑んでオカシイとサンプルコード書いて確認してみてレスしてるのに >>662 >>664 はいサンプルね https://go.dev/play/p/X71811pJ1sQ >>667 >>659 >>662 で変換される でもGoの知識増えたしいいんじゃない？ Googleのたかが1プロジェクトが C++で始まるからと言ってGoの終わりを感じ始めるなんてどういう審美眼で生きてんだよ。 >>673 >>674 Googleってコーディングに関しては無茶苦茶保守的というか統制的だからな 数多の捨てられたプロジェクトに比べればGo言語は成功した部類だろうよ。 なんでC++なんて使ってるんだよ Googleは独自のビルドシステムなど過剰に最適化された開発環境を持ってるから、簡単に言語変えられないんだよ いや、たんに仕事が雑なだけだとおもう RustじゃなくてC++なのが逆張りっぽくてキモい Dが2001年、F#が2005年、Goが2009年(年はwikipediaに書いてあった登場時期) 最小とか最大を求める関数は自分で作れって話なの？ 二分探索できたりする場合もあるからそういうライブラリはあえて作ってないんだと思われる windows環境でGoをアップデートするにはどうしたらいいでしょうか？ Chocolateyでやってるのを見てみると、上書きっぽいけど GoなんかどうせWinネイティブで使う意味ないんだから、WSLでHomebrewでも使って入れたらいいんじゃない ちなみにChatGPTはセッション的に一連の会話を一時的に覚えててくれるらしいから、 >>703 Go言語はこの先生きのこれるのか？聞いてみたら面白いかもな。 やはりChatGPTだめだな！ 地元のマイナーなサッカーチームについて聞いたら「日本でも見逃すことのできないチームの一つ」とか適当に答えたぞコイツ >>710 真面目な話、わからんことを素直に「それについてはわかりません」と言ってくれないのはかなりタチがわるいな >>712 rainu/go-command-chain: A go library for easy configure and run command chains. Such like pipelining in unix shells. https://github.com/rainu/go-command-chain CLIの引数の読み取りするライブラリーは何がおすすめ？ https://www.reddit.com/r/golang/comments/9uybnt/choosing_a_library_for_cli_application/ https://github.com/jessevdk/go-flags. I like the declarative approach a lot more than the imperative one used for many other options, and it's extremely feature-rich. >>717 >>718 cobraはサブコマンドを無限に生やすような大規模向け、Kubernetes/dockerで使用されてる。 ジェネリックスって、有名どころのOSSのライブラリで活用されたりしてるの? Go言語でマイクロサービスの実装を解説してる書籍はありますかねえ？ >>724 Go言語入りユニクロTシャツ、Akamaiが提供 コードを動かしてみた人も=ITmedia 今期の公式調査が来たからみんな答えよう Goはこの中途半端な立ち位置のまま 昔Rubyがブイブイいわせていた時、私はPythonを選びました goもこのまま衰退してしまうのだろうか。 そういえばジェネリクスはもう実装されたんだよな。もうinterface{}地獄じゃないのかな。 まだ地獄やろ、 かなり早い段階で翻訳が出たな https://github.com/teivah/100-go-mistakes/blob/master/09-concurrency-practice/68-string-formatting/main.go https://forest.watch.impress.co.jp/docs/bookwatch/news/1524131.html https://www. アmazon.com/100-Mistakes-How-Avoid-Them/dp/1617299596 https://github.com/teivah/100-go-mistakes/issues/30 最近goはじめたけど、例外処理になれないわ 女性がイクときは3パターンある mattnさんのGo本半額だったのに買い忘れた… goいいよな マイクロサービス向けの言語だから 勉強がてらGoでwebサービスやってるけどLaravelで良いじゃんって気がしてしょうがないw > PHP Laravel再評価の時代来そう プロの労働市場は、Ruby, AWS Solution Architect だけ。 米国年収でも、Rubyは、Go/Rust/Elixir の3大言語を超えた！ >>753 >>759 goとrustじゃあ全然言語機能違いすぎるよ 逆にRustでバックエンドのWebサービス実装する 本来についてはどうなんだろうね でも実際GoogleはGoで書かれたものもRustに移行してる RustはC/C++の代替言語なわけで結局メモリ管理のための記述が必要な低級言語なんだよ〜 シンプルな言語機能でコードの保守性を高めることがGo言語の目的で、それはRustと真逆のような Rustが人気な理由は つかメモリ管理が～とか中級者まででしょ javaがウケたのもcがウケたのも >>769 ただしJavaは敷居を下げすぎて業界にバカが多数流入した >>762 こんばんは 言語仕様が簡素な点が特徴だけど >>774 >>773 javaの代わりにGo使うメリットってネイティブコード吐き出すことだと思うけど >>777 > Javaの連中はポインタが使えない(使わなくて済む)からJavaに行ったのだから、 >>779 >>780 >>782 >>773 そのようにC/C++を自分は使いこなせると思い込んでいる多くの人たちによってセキュリティホールが生み出し続けられている https://atmarkit.itmedia.co.jp/ait/articles/2403/18/news045.html AIによるコンパイラによってC/C++は復活する、コンパイル時にメモリ安全がAIによって保障されるのだ >>785 >>786 ) そんな心配しなくてもAIが進化すればGOもC/C++もRustもなくなって別の高級言語が生まれるよ、もう会話してればプログラムができちゃうような感じになる >>788 >>792 >>793 なんかスレが進んどる。半分は読んでない。 >>794 とはいえ数は力である。 Rustの場合は「文法に従ってさえすればリークは防げます、境界オーバーは動的チェックしてます」らしいので、 >>798 >>799 >>785 >>773 ) Cと違ってGoは賢い >>801 >>804 
