Go language part 4

1 名前：デフォルトの名無しさん mailto:sage [2020/11/16(月) 04:14:40.64 ID:fB5+0hxC.net] Goについて扱うスレッドです。 GoはGoogleによって開発された言語です。 公式 https://golang.org 公式ドキュメント https://golang.org/doc/ 公式外パッケージドキュメント https://godoc.org ブラウザ上で試し書き https://play.golang.org ※前スレ Go language part 3 https://mevius.5ch.net/test/read.cgi/tech/1571315884/ 641 名前：デフォルトの名無しさん mailto:sage [2021/11/04(木) 19:21:19.80 ID:5gkz3BSt.net] だってアマとか無料枠ないんだもん 一年目だけってのは、単に初回サービスって言うんだよ 642 名前：デフォルトの名無しさん [2021/11/05(金) 14:20:53.38 ID:0z+NMKpK.net] Herokuとか 643 名前：デフォルトの名無しさん mailto:sage [2021/11/07(日) 15:35:29.83 ID:mQ9A5wfK.net] 社会人なら別にEC2使ってもマイナーサービスのサーバ台ぐらい余裕やで。 一ヶ月分の料金なんて、スタバ2回分くらいだろ。 そら安いほうがいいけど。 644 名前：デフォルトの名無しさん mailto:sage [2021/11/07(日) 22:23:20.41 ID:aZyVG3bY.net] micro使えば安いけど明らかにメモリが足りないんだよな おまけに調子に乗ってぶん回すと詰まるし 最低でもmedium程度は欲しいがそうなると結構高くなる 645 名前：デフォルトの名無しさん mailto:sage [2021/11/07(日) 22:38:38.82 ID:VzSbYdr/.net] Oracle Cloudは？ コンソールが重くて独自性強いけど起動してしまえばいっしょ 646 名前：デフォルトの名無しさん mailto:sage [2021/11/07(日) 23:41:21.11 ID:KgxySftM.net] サイト立ててもアクセスが日に数件なんでほとんどマシン回ってないやww 647 名前：デフォルトの名無しさん [2021/11/08(月) 16:12:42.92 ID:KvpLYeV7.net] microといえば思い出す、大手のNでスワップしまくりなんも考えてないSEが手配したmicro しかもWindowsの時の絶望感・・・ 648 名前：デフォルトの名無しさん mailto:sage [2021/11/08(月) 16:32:31.04 ID:Qfm8QX8G.net] んなもん動くか！ とググったら https://qiita.com/zakky/items/68c4749889717c3cd849 おぅい！！ 649 名前：デフォルトの名無しさん mailto:sage [2021/11/08(月) 16:42:16.76 ID:NUVpgUuA.net] microでも小さいサービスならメモリ足りるやろ？ goだったら100MBメモリ食うこともありえないくらいやろ メモリリークでもしてるんじゃないの？ Windowsとか動かしたらそらきついだろうけど。 650 名前：デフォルトの名無しさん mailto:sage [2021/11/08(月) 17:40:06.67 ID:Qfm8QX8G.net] 動くか、と言ったのはWindowsの話 400MB確保できるみたいだから意外と使えるかも？ 651 名前：デフォルトの名無しさん mailto:sage [2021/11/08(月) 18:00:09.69 ID:NUVpgUuA.net] なんでそんなにWindowsを動かしたいんだ・・・。 652 名前：デフォルトの名無しさん mailto:sage [2021/11/09(火) 13:54:21.34 ID:dGlVH92+.net] >>640 pインスタンスでwindowsを動かすのは普通に多いよ 653 名前：デフォルトの名無しさん mailto:sage [2021/11/09(火) 17:10:56.19 ID:8qmTEk8+.net] いや、なんで？という疑問への答えじゃないよな ぶっちゃけLinuxでSSH接続専用にすれば済むから 654 名前：デフォルトの名無しさん mailto:sage [2021/11/09(火) 19:48:05.88 ID:+FOj3uk2.net] GUI系のアプリを動かすんだよ CAD系のシミュレータとか windowsにしか存在してないアプリが多い 655 名前：デフォルトの名無しさん [2021/11/09(火) 23:41:06.97 ID:5nP8kmAz.net] github.com/fogleman/gg が遅くてちょっと困った。 Webassemblyで普通にcanvasの関数をcallした方が速いなんて。 ebitenはdraw系の関数少ないからなぁ。 656 名前：デフォルトの名無しさん [2021/11/11(木) 09:52:59.41 ID:zPNWYi1t.net] Twelve Years of Go Russ Cox, for the Go team 10 November 2021 657 名前：デフォルトの名無しさん [2021/11/17(水) 23:16:51.89 ID:a+84vLf4.net] gotoの使用は許可されてる？ 658 名前：デフォルトの名無しさん mailto:sage [2021/11/18(木) 06:41:13.91 ID:eOo002y1.net] >>646 普通は使わないが何故か仕様にあるんだから許可されてるんだろ 659 名前：デフォルトの名無しさん [2021/11/18(木) 17:38:26.56 ID:kJKbHvZv.net] 深いループを抜けるときはgotoを使う 660 名前：デフォルトの名無しさん mailto:sage [2021/11/18(木) 21:15:03.90 ID:iWaFftPG.net] ラベルgotoは、gotoではあっても古い言語で禁忌されているgotoではありません。 ダイクストラのgoto文論争はBASICはもちろんですが、1968年に“Go To Statement Considered Harmful” （Go To 文は有害とみなされる）において行番号へ飛ぶような言語が多かったために起こった論争です。 C言語も古くからありましたが、こちらもあまり使われなくなりました。なによりもgoto以前に setjmp, longjmpという、関数の間でのジャンプ出来るようなC標準ライブラリが存在したために より強く禁忌されたといえるでしょう。のちにStructured ProgrammingからO-OProgrammingへ移り変わる につれて行番号は何もなく、文の構造の厳格性や動的ディスパッチなどが整備されたため、必要性が薄れました。 現在あるラベルgotoとは、ループの中に飛び込むgotoなどではなく、二重のループ中のbreakなどで 脱出経路を明確化するなど、例えばコンピュータサイエンスの分野ではHaskellにおいてはモナドを利用して 例外や非決定性計算行うなど、引数付きgotoとも呼ばれる。 661 名前：デフォルトの名無しさん mailto:sage [2021/11/19(金) 09:01:28.58 ID:Fh4InTPD.net] Inline指定出来ないので関数呼び出しのコスト低減くらいしか用途が思いつかない そこまでシビアな実装滅多に無いから基本的に使わない 662 名前：デフォルトの名無しさん mailto:sage [2021/11/19(金) 12:21:28.19 ID:WNpWqDaH.net] 確かに関数化すりゃブロック脱出もシンプルにreturnさせりゃいい となるとgotoは関数呼び出しによるオーバーヘッドの削減だけなのかな？ ナノ秒単位でも削減したいという余程のシビアな要件で使うって話になるけど、関数呼び出しごとにスタックのチェックが入るGoでそんな要件に意味ってあるの？とも思う 663 名前：デフォルトの名無しさん mailto:sage [2021/11/19(金) 12:34:26.60 ID:kQNnUQCo.net] というよりもアホ意識高いgoto異端審問官が、文句つけてくるので使わない。 664 名前：デフォルトの名無しさん mailto:sage [2021/11/19(金) 15:43:47.01 ID:oZVaazpx.net] おれにとっては、Golangでgoto使うのは、構文解析器みたいなのを書くときにたまにあるんだけど、共通の処理までジャンプしたいときとか、 for文とかをネストしたときに、いくつか上のブロックまでジャンプしたいときかなあ。これも構文解析したあとの評価器で使うこともある気がする ようするに最適化とかじゃなくて、ちょっとした大域脱出みたいなノリで使ってる Go本体のソースコードでもこんな感じgoto使ってるんじゃなかったっけ 665 名前：デフォルトの名無しさん mailto:sage [2021/11/20(土) 11:05:39.09 ID:GriTsYN5.net] 俺たちのGO！ 666 名前：デフォルトの名無しさん [2021/11/21(日) 07:26:46.41 ID:8Zd5Z9wI.net] IDEはどれがおすすめ？ 667 名前：デフォルトの名無しさん mailto:sage [2021/11/21(日) 07:39:21.64 ID:AMP8EKz2.net] 自分はVSCode 668 名前：デフォルトの名無しさん mailto:sage [2021/11/21(日) 23:14:16.37 ID:1+FhODzH.net] 私はEmacs 669 名前：デフォルトの名無しさん [2021/11/22(月) 06:12:39.00 ID:I9kdAR+e.net] VSCodeもemacsもIDEではないけどね 670 名前：デフォルトの名無しさん mailto:sage [2021/11/22(月) 07:05:20.26 ID:rahxNjIR.net] バージョン管理からテストまで環境内で完結してるのに仲間外れなのか 671 名前：デフォルトの名無しさん mailto:sage [2021/11/22(月) 19:08:36.54 ID:uiCHuC7N.net] emacsは"環境"だから、 emacs > IDE だよな ところでIDEの定義って何よ？ 高機能エディタと垣根がなくなってきたからそれらを区別する意味があるのかどうか 672 名前：デフォルトの名無しさん mailto:sage [2021/11/22(月) 19:28:29.86 ID:rahxNjIR.net] 統合開発環境だから、コンパイルからデバッグ、バージョン管理にデプロイまで揃ってるemacsとかVScodeを入れないとなると、いよいようろんな定義になる RADとかグラフィカルな開発環境とごっちゃになってるのでは？ 673 名前：デフォルトの名無しさん mailto:sage [2021/11/22(月) 19:36:29.51 ID:rahxNjIR.net] エディタ内でデバッガと密接に連携(ブレークポイント設置して値を参照とか)できれば統合してると言ってもいいと思うんだが 674 名前：デフォルトの名無しさん mailto:sage [2021/11/23(火) 10:50:24.50 ID:YlZvZbei.net] mapをrangeステートメントで処理すると毎回順番変わるのな 将来mapの実装を変えた時に要素の順番が変わっても大丈夫なようにあえてランダムにしてるらしい 最初知らなくて嵌った しかもランダムに返す仕様の方がパフォーマンスをよくしやすいらしい ensure better balancingって なるべく偏らないように要素を配置するみたいな意味か https://stackoverflow.com/questions/55925822/why-are-iterations-over-maps-random/55925880#55925880 675 名前：デフォルトの名無しさん mailto:sage [2021/11/23(火) 11:47:46.83 ID:RPYITf6H.net] > ランダムに返す仕様の方がパフォーマンスをよくしやすい いや流石にそんなことはないぞ 処理系の実装変更だけでなくマシン毎に結果が違うことも許容することで、パフォーマンス最適化の余地が広がるという意味だ 676 名前：デフォルトの名無しさん [2021/11/25(木) 20:43:12.75 ID:0woLMmPf.net] 11月TIOBEプログラミング言語人気ランキング、PHPの下落続く https://news.mynavi.jp/article/20211109-2181586/ 677 名前：デフォルトの名無しさん [2021/11/26(金) 17:11:22.22 ID:xw//vI58.net] Golangが一番書きやすい 678 名前：デフォルトの名無しさん mailto:sage [2021/11/26(金) 19:19:32.54 ID:TC631CUh.net] go と defer とチャネルが便利すぎるね チャネルのキャパシティは未だに悩む 679 名前：デフォルトの名無しさん mailto:sage [2021/11/26(金) 19:31:07.75 ID:jCnjnABk.net] チャネルはクソだろ Cでいうポインタ関連のミスによる死と同程度くらいにはデッドロックを起こしやすい極めて危険な仕組み 680 名前：デフォルトの名無しさん mailto:sage [2021/11/26(金) 19:33:40.57 ID:klqHYhKv.net] 勉強中でよくわかってないんだけど メインルーチンが死んだらゴルーチンもチャンネルも死ぬんじゃないの？ 681 名前：デフォルトの名無しさん mailto:sage [2021/11/26(金) 19:53:34.58 ID:TC631CUh.net] デッドロックは一番の可能性としてキャパシティを疑う 682 名前：デフォルトの名無しさん mailto:sage [2021/11/26(金) 21:43:15.55 ID:vur9wleR.net] どんな言語でもスレッドやルーチェンの１つが落ちて無事平穏な言語は少ない。Erlangぐらいかな落ちる前提なのは 683 名前：デフォルトの名無しさん mailto:sage [2021/11/26(金) 22:02:31.09 ID:v7cZYF1p.net] もう新しいデータ来ないのに 私待つわ…いつまでも待つわ…と待ち続けるコードを書けば 当然ながら詰まる 684 名前：デフォルトの名無しさん mailto:sage [2021/11/26(金) 22:32:30.29 ID:gRCMakca.net] アミン…大統領 685 名前：デフォルトの名無しさん mailto:sage [2021/11/26(金) 22:54:09.91 ID:b/zo5EjW.net] 未使用の変数がコンパイルエラーになるのは地味に良い 686 名前：デフォルトの名無しさん mailto:sage [2021/11/27(土) 15:33:06.29 ID:DHp3ezKZ.net] 俺もチャネルはどうかと思う ある意味スレッドより危険 687 名前：デフォルトの名無しさん mailto:sage [2021/11/27(土) 15:56:47.57 ID:wymfOW3B.net] 設計間違えたらデッドロックするのはどんな通信でも一緒じゃね？ チャネルを殊更に危険視するの？ 688 名前：デフォルトの名無しさん mailto:sage [2021/11/27(土) 16:07:17.64 ID:z8jcIZfA.net] >>676 デッドロックしやすい仕様なのは事実だし、危険だからといってその使用を回避できる標準的な代替手段が存在しない 他の言語ではだいたいpromise/future、fork-join、actorがあるからよほど変なことしなきゃデッドロックなんか滅多に起きないよ 689 名前：デフォルトの名無しさん mailto:sage [2021/11/27(土) 16:10:29.89 ID:EtwFQg7M.net] そうなんだ？　イケてないの？ Googleさんはなんでそんな方式を採用してしまったのやら 690 名前：デフォルトの名無しさん mailto:sage [2021/11/27(土) 16:43:12.87 ID:z8jcIZfA.net] >>678 デザインパターンみたいなものを極力廃して、小さな標準的なツールセットだけでモノ作れるようにするという思想は一貫している しかしスレッド関連のデザインパターンというのは基本的に死なないためにあえて制約を設けているのであって、 Goの思想が逆に敷居を高くする方向に作用してしまったということだ 691 名前：デフォルトの名無しさん mailto:sage [2021/11/27(土) 16:49:44.44 ID:kX7QbhiL.net] CSPモデルに沿った実装がしやすいとは聞く。 CSPモデルができていればそれがデッドロックを起こすかどうか静的に検証できるはず。 692 名前：デフォルトの名無しさん mailto:sage [2021/11/27(土) 16:50:07.92 ID:Xzfp/9Y9.net] ほえー、そうなんだ 実際のところ、他の人がgoroutineとか使ったやつを -race 付きで実行すると警告出まくるやつばっかだったよ Goの強みは並行処理だと思ってたのに、他の言語のことはよく知らんけどもそんな有様じゃ強みだなんて言えないなあ 693 名前：681 mailto:sage [2021/11/27(土) 16:53:59.99 ID:Xzfp/9Y9.net] なんかID変わっちゃってたけど、おれは >>678 ね >>679 に向けて返信した 694 名前：デフォルトの名無しさん mailto:sage [2021/11/27(土) 17:22:55.75 ID:1Qfj4fkw.net] CSPモデル ttp://www.usingcsp.com/cspbook.pdf 695 名前：681 mailto:sage [2021/11/27(土) 18:04:43.03 ID:Xzfp/9Y9.net] すまん、せっかくCSPを紹介してくれるなら、もっと初心者向けのやつない？ 興味はある 696 名前：デフォルトの名無しさん mailto:sage [2021/11/27(土) 18:14:49.72 ID:kX7QbhiL.net] これとか。 https://staff.aist.go.jp/y-isobe/topse/vic/slides/csp-isobe-2012-03.pdf 697 名前：デフォルトの名無しさん mailto:sage [2021/11/27(土) 18:28:08.91 ID:NTle55ol.net] >>678 ここに玉にディスりにくるRust坊、ほんと性格悪いな 698 名前：デフォルトの名無しさん mailto:sage [2021/11/27(土) 19:03:33.53 ID:NTle55ol.net] 設計が間違えてチャネルで無限ブロックするならタイムアウトをつけるべきだし、Rustもチャネルで 無限ブロックするしほかの多くの言語も（スレッド）チャネルの受信でブロックする チャネルとは違うがErlangメッセージパッシングだって似たようなもの 699 名前：デフォルトの名無しさん mailto:sage [2021/11/27(土) 19:14:15.48 ID:z8jcIZfA.net] >>687 そういうことを言ってるんじゃないのよ >>677にも書いたけど標準的な安全な代替手段が存在しないことが問題 700 名前：デフォルトの名無しさん mailto:sage [2021/11/27(土) 19:53:13.18 ID:wymfOW3B.net] Rustなんてスレッド実装が固まってから五年も経ってないお子ちゃま 701 名前：デフォルトの名無しさん mailto:sage [2021/11/27(土) 19:53:53.46 ID:DHp3ezKZ.net] スレッドとかだとバッドパーツが一通り手間揃ってて こういうのはやめましょうってのがほぼデザインパターン化されてるから コードレビューでつぶせたり 処理を追うとわかったりする 702 名前：デフォルトの名無しさん mailto:sage [2021/11/27(土) 19:54:52.94 ID:LVgG7qhW.net] >>683,685 CSPモデルのasync/awaitに対する優位性って何？ 見た目何もない気がするが。 (ちなJSではなくC#のスレッドプールに対するasync/await想定でよろしく) 703 名前：デフォルトの名無しさん mailto:sage [2021/11/27(土) 20:00:12.03 ID:kX7QbhiL.net] もともと危険なthread/mutexには安全なwrapperがあるのにgoのchannelにはそれが無いから、ってことかな？ 704 名前：デフォルトの名無しさん mailto:sage [2021/11/27(土) 20:12:14.69 ID:K1RL10E4.net] >>688 平行性のある現代的なプログラミング言語ではデットロックは言語仕様の問題ではなく、食事する哲学者の問題と 同じく制限された個数のチャネルで送られたデータが受け取られていないのに、送信できるようにはなりません。 これがレース競合を起こさないための標準的で安全な手段であり、グローバル変数や変数共有をgoroutine介して 同期ミューテックスもない操作すれば当然警告が出るでしょう。 そもそもgoroutineでのチャネルブロックはデットロックではなく、待機ブロックです。その証拠にSIGINTなどの シグナルでは待機ブロックでも抜けるはずです。本来のデットロックなら応答しないかゾンビになります もちろんスレッド（あるいは軽量スレッド）間でチャネルを介してのみデータを共有できるプログラミング言語も 存在しますが、goは親スコープにある変数などを操作できるように利便性のトレードオフ設計であり、より現実� 705 名前：Iで 効率的だとも言えるでしょう また制限された個数でないチャネルの場合は送信に受信側処理速度が追い付かない場合、キューイングされて 無限にメモリーが圧迫される危険性があります。 非同期系の言語で使用されるpromiseや、未来値のプレスホルダーを参照するfutureでデットロックが起きないのは 当たり前です。前者は非同期であり並列/並行ではありません、後者は終了時まで待って値を受け渡すだけです。 fork-joinは何が言いたいのかわかりません、actorプログラミングモデルや純関数言語ならその通りですが 共有したいデータが多くの言語でチャネルやパッシングを介してのみなので競合は起こらないでしょうが いつまで待っても到着しない受信側は、永遠に待ち続けるのは変わりません。 「そういう事をいってるんじゃない」 ま、こういう問題を一切合切、無難に解決してくれる標準的な手段を手続き言語に求めるのは分からなくも ないですが、最終的にデットロック（あるいは待機ブロックで無限待ち）したらどうするか記述するような フォールトトレラント処理が欲しいわけでもないのでしょうが、個数が限られている場合のレース競合対策の ルールなので言語的ではなく、哲学的にどうにもならないと思いますが [] [ここ壊れてます] 706 名前：デフォルトの名無しさん mailto:sage [2021/11/27(土) 20:52:19.87 ID:DHp3ezKZ.net] >>693 何も分かってないなら書き込むなよ 707 名前：デフォルトの名無しさん mailto:sage [2021/11/27(土) 21:01:18.61 ID:LVgG7qhW.net] >>693 それお前が今書いたん？ ググってもヒットしないが、そうとも思えないから原典があるのならそっちのURLくれ。 横だが「そういうことを言ってるんじゃないのよ」ってのは、単に、 生でスレッド処理を弄らせてデッドロックの危険を避ける色々な仕掛けを正しく準備しろ、というのなら、 フレームワーク等でその辺の仕掛けを全部用意してしまって、その上でジョブをキューイング出来るようにするだけの方が 処理性能も同じで手間がかからない分だけ合理的だろ、という話だよ。 Web系でSessionや認証周りは全部フレームワークに丸投げするべき、と言われているのと同じ。 スレッド周りでどうせ色々やらないといけないなら、最初からフレームワークに丸投げした方が合理的なんだよ。 だから、レイヤーが低い記述が出来るのなら、その手間に見合うだけの価値がないと意味無いんだけど、それがないでしょ、って話。 平行並列周りの研究をしてていじくり回したいだけの人＝そのプログラムがその時動けばいいだけの人 にとっては言語が直接サポートしてるのは便利だけど、 製品としてガッツリ動かす為には結局色々全部必要なら、職業プログラマにとってはまるで意味無いよね、という話。 708 名前：デフォルトの名無しさん mailto:sage [2021/11/27(土) 21:15:45.01 ID:w2+KtZN6.net] >>691 静的に検証ができるっとことだろうな 709 名前：デフォルトの名無しさん mailto:sage [2021/11/27(土) 21:26:58.69 ID:LVgG7qhW.net] >>696 何の検証？デッドロック？ async/awaitはデッドロックはしないぞ。 (永遠にジョブが終わらずに待たされてるように見えるだけ。メインスレッドは動き続けるし、GUIも動く) 710 名前：デフォルトの名無しさん mailto:sage [2021/11/27(土) 21:42:40.45 ID:bJFd+1Ko.net] 一生懸命にRust坊が荒らしてるｗｗ 711 名前：デフォルトの名無しさん mailto:sage [2021/11/27(土) 22:37:45.64 ID:Cem9Q3+A.net] いやこれはMSのC#おじさんだね、チャネルの話ならまだ良いがGolangの設計にありえないasync/awaitとフレームワークを交えながら意味不明なことを呟き続ける。 普通にデッドロックするしフレームワークってなんやねん（笑）Web系なんて共有すべきデータが無いんだからシコシコ糞コード書いてろよ？ おまえの競争相手はJavaとかPHPとかRailsだから、そっちに噛みついてこい、C#なのかRustなのかどうでも良いけど頭おかしいことは確か 712 名前：デフォルトの名無しさん mailto:sage [2021/11/27(土) 22:51:09.81 ID:w2+KtZN6.net] >>697 そういう意味ではモデルの記述力か。 async/awaitは動作モデルを単純化することで安全性を保証できるようになったけど 食事する哲学者問題みたいなものを記述することができない。 713 名前：デフォルトの名無しさん mailto:sage [2021/11/27(土) 22:58:09.67 ID:AWnsIzD4.net] async/awaitみたいな使い方ができないのはヤダヤダってことなんだろうな 714 名前：デフォルトの名無しさん mailto:sage [2021/11/27(土) 23:25:17.01 ID:Oiaj8YVV.net] >>688 どの手段も場合毎に安全では無いし、それ故に画一的な標準的手段にはなり得ないから、それだけバリエーションがあるんよ。 Goはそのあたり多様性をネグって「こういう場合はこういう事に気をつけようねぇ！！」という脳筋的解決を図ってるの。 愚直だけどシンプルよ。 715 名前：デフォルトの名無しさん mailto:sage [2021/11/27(土) 23:26:48.32 ID:Oiaj8YVV.net] Taskをスレッドプール使ってやりくりするより、はるかに早いんよな…goroutine。 716 名前：デフォルトの名無しさん mailto:sage [2021/11/27(土) 23:31:12.50 ID:B7MvCGlK.net] 若い人にC#じゃなくてGoにしましょう言われたんかな？可哀想だから代替えとしてこういうのもありますよ https://hackernoon.com/asyncawait-in-golang-an-introductory-guide-ol1e34sg https://github.com/Joker666/AsyncGoDemo https://github.com/StudioSol/async 717 名前：デフォルトの名無しさん mailto:sage [2021/11/27(土) 23:40:22.05 ID:jawpS72C.net] >>704 お、こういう情報の提供はありがたい。 718 名前：デフォルトの名無しさん mailto:sage [2021/11/28(日) 00:00:58.18 ID:s59YsBRT.net] むしろ定年間際な俺みたいなCで育った奴の方にウケてないのか？ 719 名前：681 mailto:sage [2021/11/28(日) 00:22:11.00 ID:Z9Xk/5kf.net] Go以外の並行処理のことはよくしらんけど、「Go言語による並行処理」を一通り読んでからは、並行処理でバグることへったよ 他の並行処理モデルだともっとうまいこといけるんか？ 720 名前：デフォルトの名無しさん mailto:sage [2021/11/28(日) 07:47:32.52 ID:s59YsBRT.net] 別の言語じゃ主にメモリを共有して排他処理して使ってる ガバガバだけどミスには寛容なのでわりかし安心ではある Goでもガバガバにキャパシティ増やしとけばそんなにデッドロックしないと思うんだけど デフォルトだと一個でもキューされてると次の送信がwaitになる優しくない仕様を問題視してるんじゃないかな？ 721 名前：デフォルトの名無しさん mailto:sage [2021/11/28(日) 08:51:48.67 ID:Abxhe3pm.net] >>700 > 食事する哲学者問題 これを記述出来たとして、何が嬉しいんだ？ 並列は結局のところ、処理能力の増大を目指してる。 シングルスレッドに無限大の処理能力があれば、誰も並列なんて使わない。 現実的にはこれはないから、様々な方策を用いて何とかするわけだ。 そこで、ジョブを他CPUに投げれれば事足りますね、で単純化したのがasync/awaitで、実際確かにこれで済む。 マルチスレッドの諸問題と解決策等、プログラミング界で経験値がたまった結果の、現段階の最適解だ。 これを実装してなくてどうする？と思うが。 スレッド周りの問題をいじくり回したい研究者には向いてるのだろうけど、それだけだよね。 やりたければ他言語でも生スレッドは使えるから、いくらでも出来るけど。 逆にGoroutineではチャネル接続タイプしか記述出来ないから、そこを越えた研究には向かないよ。 とはいえ現段階ではチャネル接続の優位性が覆る事はなさそうだが。 多分な、 ・チャネル接続にすればマルチスレッドの諸問題が解決するかも？ という見積もりが外れただけなのだと思うよ。だからGoはメジャーになり損ねた。 なおJSは逆に、 ・シングルスレッドに無限大の処理能力があれば、誰も並列なんて使わない。 　→ならシングルスレッドの処理能力を無限大にすればよくね？引っかかってるところ全部I/Oだろ でI/Oをすべて切り離して非同期にした結果、これが大当たりして、あらゆる所に蔓延ってる。 当時メジャーでなかったクロージャの利便性を知らしめたとか、GUIにはプロトタイプが向いてたとか、他にも色々あるけど、 根本の言語設計が素晴らしかったから結果的にでも大当たりしたのは事実だよ。 722 名前：デフォルトの名無しさん mailto:sage [2021/11/28(日) 09:40:53.84 ID:CHeWGBnC.net] >>708 というより、本来チャネルよりも適した抽象化がある場合でもチャネル使わなきゃいけないことが問題じゃないかな たとえばpromiseで一つの値を返せたらいいだけのケースでチャネル使っちゃうと、 そこに処理は単一の結果の生成をもって完了するというセマンティクスは全く残らないわけよ で誤って値を2回取り出そうとしたらデッドロックだ 723 名前：デフォルトの名無しさん mailto:sage [2021/11/28(日) 09:52:08.42 ID:zNq1hAJ3.net] ていうかgoでもロックとか サードパーティのロックフリーキューのライブラリは使えんじゃね？ しらんけど 724 名前：デフォルトの名無しさん mailto:sage [2021/11/28(日) 10:03:56.17 ID:Abxhe3pm.net] >>710 ちなみにPromiseも俺は不要だと思ってるんだけど、 Promiseが無いと書けない何かってあるか？ C#はPromise見えてたけど採用しなかったし、実際async/awaitで足りてる感じだし。 725 名前：デフォルトの名無しさん mailto:sage [2021/11/28(日) 10:08:04.10 ID:CHeWGBnC.net] >>712 async/awaitで使用されるTaskはpromiseの一種だよ 726 名前：デフォルトの名無しさん mailto:sage [2021/11/28(日) 10:23:44.01 ID:Abxhe3pm.net] >>713 それはJSerの言う「Promiseが有ったからこそのasyncだ」という言い訳だろ。 Promiseという界面を露出させなくても問題ないと踏んでasync/awaitだけにしたのがC#。 勿論それ以前にC#だと生スレッドも使えるから最悪何とでもなるという保険はあったにしても。 C#erも同種の言い訳、つまりthread→backgroundWorker→Task→asyncと進化したのであって、 これがなかったら無理だった、という事を言うけど、これもやっぱり無理筋で、 2000年時点で「技術的に」asyncが実装出来なかった理由は見あたらない。 結局、思いつけなかっただけだと思うんだよね。 実際、2000年当時のCPUでも今のasync/awaitのコードは動くだろうし、 今現在Task界面も露出する意味無いだろ。 2000年当時にC#がいきなりasync/await実装してデビューしてたら神だったと思うよ。 727 名前：デフォルトの名無しさん mailto:sage [2021/11/28(日) 10:37:05.48 ID:CHeWGBnC.net] >>714 async/await自体もpromiseの実装だよ https://ja.m.wikipedia.org/wiki/Future_%E3%83%91%E3%82%BF%E3%83%BC%E3%83%B3 なおasync/awaitで事足りるpromiseのユースケースにおいては、Goではチャネルなんか使わず普通にgoroutine内で同期処理すればいいので、今の話題とは無関係 728 名前：デフォルトの名無しさん mailto:sage [2021/11/28(日) 10:53:27.71 ID:Abxhe3pm.net] >>715 それはPromise中心主義的な考えであって、 実際async/awaitの理解にはPromiseの理解は不要だろ。 「そこで一旦止まって、非同期Jobが終わり次第、次を実行」で済むのだから。 実装でPromise型にするのも一つの手だけど、forkでも実装出来るのだし、(むしろforkの方が簡単） > async/await自体もpromiseの実装だよ これは買いかぶりすぎで、async/awaitとPromiseは直接の関係も必然性もないよ。 729 名前：デフォルトの名無しさん mailto:sage [2021/11/28(日) 11:07:43.63 ID:Abxhe3pm.net] >>715 そういえば脱線を嫌ってるのか？なら戻しておくと、 Goはgoroutineで並列平行をお気楽に書けるようにしたが、 並列は今のところasync/awaitで決まりなので、目論見は外れた。 平行は…async/awaitではなさそうだし、まあチャネルだろうし、goroutineかも？ 730 名前：デフォルトの名無しさん mailto:sage [2021/11/28(日) 11:15:38.54 ID:Abxhe3pm.net] >>715 716（脱線側）補足 × > async/await自体もpromiseの実装だよ ○ async/awaitの実装の一つがpromise async/awaitはただの記法であって、その実装にpromise方式も使える。 つまりasync/awaitの方が上位概念だよ。同一レイヤーではない。 731 名前：デフォルトの名無しさん mailto:sage [2021/11/28(日) 11:16:48.98 ID:7hiPfTRd.net] >>714 Taskなしのasync/awaitだけじゃ並列処理できないんじゃないの？ 732 名前：デフォルトの名無しさん mailto:sage [2021/11/28(日) 11:38:24.51 ID:Abxhe3pm.net] >>719 何で？ Jobを投げ込むのにTask型を使ってるだけで、要は関数のエントリポイントが有ればいいだけだし、実際JSはそうだろ。 > async function asyncCall() { > console.log('calling'); > const result = await resolveAfter2Seconds(); > console.log(result); > // expected output: "resolved" > } > asyncCall(); > https://developer.mozilla.org/ja/docs/Web/JavaScript/Reference/Statements/async_function async/awaitが保証してるのは、 ・async関数は非同期で実行される --- (A) ・awaitでメインスレッドは一旦処理が返る。その後、async関数が終わり次第続きを実行する。 であって、(A)をスレッドプールから実行するようにしたのがC#で、並列されるし、 そうしてないだけ、つまり非同期を同期的に書けるようにしただけなのがJSだろ。 だから逆に、JSでも(A)をWorkerスレッドに振るようにしたら並列するようになるだけだよ。 733 名前：デフォルトの名無しさん mailto:sage [2021/11/28(日) 11:56:27.00 ID:7hiPfTRd.net] awaitで待っている側はその間止まっているわけだから並行処理ではあっても並列処理じゃないでしょ。 まぁTask.WaitAllのように複数同時に投げられるようにするならそれでもいいだろうけど。 734 名前：デフォルトの名無しさん mailto:sage [2021/11/28(日) 12:21:57.96 ID:s59YsBRT.net] async/await ってPromiseの糖衣構文にしか見えなくて大いに疑問が(知らないだけ？ 糖衣構文で言語仕様を膨らませて、こんなに簡潔に書けるようになりました！とかもう子供かと 言語仕様が増えても出来ることが簡潔に書ける以外で変わらないんじゃ劣化してるだろ 簡潔にと言われるたびに信用を下げる 735 名前：デフォルトの名無しさん mailto:sage [2021/11/28(日) 12:23:22.96 ID:Abxhe3pm.net] >>721 それは君のawaitの理解が間違ってる。 書いたとおり、awaitで「メインスレッドは一旦処理が返る」から、GUIも反応するんだよ。 メインスレッドはasync/awaitでは止まらない。 awaitでイベントループ(メッセージポンプ)に返されるだけ。 その後asyncが終了したら、awaitの続きから実行される。 この実装の一つとして、Promiseがある。でも動かすだけならforkで実装した方が多分簡単。 メインスレッドは止まってないのだから、asyncジョブはいくらでも「順次」投げられる。 （同時に投げる必要はない） 並列平行したければ好きなだけ投げ込めばいいだけ。 736 名前：デフォルトの名無しさん mailto:sage [2021/11/28(日) 12:45:46.64 ID:s59YsBRT.net] >>721 俺の理解では awaitは非同期関数でのawait以降のセンテンスをthenメソッドの処理としてasyncを実行する thenのネストを平らにして、単に簡略に書けるだけの糖衣構文 737 名前：デフォルトの名無しさん mailto:sage [2021/11/28(日) 12:56:29.36 ID:s59YsBRT.net] >>724 まー、理解が怪しいんで間違ってたら指摘してくれ ともかくawaitじゃメインスレッドは停まらない、もしくはメインスレッドではawaitは呼べない(はずじゃなかったか？)、という程度の理解 738 名前：デフォルトの名無しさん mailto:sage [2021/11/28(日) 12:59:08.05 ID:Abxhe3pm.net] >>722 簡単� 739 名前：ﾍ正義だろ。 無駄に仕様が膨らんでいるのは、紆余曲折しすぎたからだ。 Promiseが便利だとされているのはPromise.all位で、つまりjoinだが、 今のasync/awaitはこれを直接的に解決する手段を提供してない。 だからここが何とかなれば、async/await以外は廃止方向だと思うぜ。今のままなら。 JSの場合はasync/awaitが見えてたのにPromise導入に踏み切った。 俺はあれは判断を間違えてると思うよ。 JSは仕様を廃止出来ないのだから、ムダ仕様を入れる度にオワコン化していくだけ。 逆に、バージョン管理してて仕様を廃止出来るC#は、実験場にも出来るし、今そうなってる感はあるけど、 本来ならもっと軽量級のGoやRubyで色々やるべきだったよね。 Goも登場時の2009にasync/await持ってればもっとメジャーになってたと思うよ。 goroutineも無いよりはましだけど、その程度でしかないから今こうなわけでさ。 [] [ここ壊れてます] 740 名前：デフォルトの名無しさん mailto:sage [2021/11/28(日) 12:59:20.84 ID:7hiPfTRd.net] >>723 イベントループの存在が前提なのかな。 async/awaitではawaitで待っているTaskが内部でまたawait待ちになった時に その制御を取得する手段がないから、そのイベントループ自体はasync/awaitとは 異なる機構で実現されてるってことかね。 741 名前：デフォルトの名無しさん mailto:sage [2021/11/28(日) 13:14:08.57 ID:xYHgZ8WY.net] >>724 >>725 idミスってるぞ

---

---

[ 続きを読む ] / [ 携帯版 ]

read.cgi ver5.27 [feat.BBS2 +1.6] / e.0.2 (02/09/03) / eucaly.net products.
担当:undef