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/ 752 名前：デフォルトの名無しさん mailto:sage [2021/11/28(日) 14:37:47.26 ID:VtXew58l.net] >>737 この説明でわからなければ、どーせメリットもわかんないだろうから「めんどくさいコード書くな」で終わるでしょw 実際に使ってる自分のリポジトリ晒すのもアホだし、Zennの記事はっとくわ。 https://zenn.dev/uzimaru0000/scraps/b4445cfed8f42f 753 名前：デフォルトの名無しさん mailto:sage [2021/11/28(日) 14:39:55.58 ID:VtXew58l.net] こんなんも便利よね。 https://qiita.com/jkr_2255/items/628f0507456eb841497c 754 名前：デフォルトの名無しさん mailto:sage [2021/11/28(日) 14:44:16.89 ID:cigmxKA5.net] async/await(だけ)では面倒で、Promiseと可換だからこそ便利だ、と言ってるんよ。 C#でも皆に臨まれてTask Likeな自作クラスが作れるようになったわけだが、いかんせん大袈裟な作りがいる。 755 名前：デフォルトの名無しさん mailto:sage [2021/11/28(日) 18:42:46.20 ID:Abxhe3pm.net] >>739-741 うん、分からんね。ただ君の説 > Promiseと可換だからこそ便利だ についてはC#はそうなってないからじきに結果は出るだろう。 とはいえヘルスバーグは知っててPromiseは不要だと判断したのだし、俺もそう思えるのだけど。 (ヘルスバーグについてはインタビューがあったはずだがググっても出てこない） 一応各URL内容に対し回答しておくと、 > await click().then(click).then(click) については、 await click(); await click(); await click(); で、すさまじく馬鹿っぽい事以外の問題点はない。 > 遅れてのセット…Promise#thenはresolve前でもresolve後でも問題なく動く についてはまあそうなんだけど、これはどちらかというとonload系イベントの問題で、 この方法でも根っこの部分、つまり最初のPromiseを設定する時点で既に onload 済みなら発行されない問題が解決出来ておらず、 結局ユーザー側が onload 済みかチェックする、または絶対に onload 未発行の時点で実行する必要がある。 だから onload 系のイベントが最初から全部 Promise だったら綺麗に解決してたのだろうけど、実際そうじゃないので言うほど利益がない。 Promiseが残るか自前でonload発行をチェックしたフラグが残るか程度だ。 > 複数の条件…Promise.allで取れる これはその通りなのだけど、馬鹿っぽくてよければ同様に await 縦積み、 await sumefuncA(); await sumefuncB(); await sumefuncC(); で行ける。(C#はこれでいけるはず。JSはもしかしたら駄目かも） 756 名前：デフォルトの名無しさん mailto:sage [2021/11/28(日) 19:04:46.48 ID:Abxhe3pm.net] 742最後補足＆訂正 JSの場合も縦積みは出来るが書き方が違うようだ。 (というかC#も間違えていたので書き直すと） await someAsyncFuncA; await someAsyncFuncB; await someAsyncFuncC; となる。以下は https://developer.mozilla.org/ja/docs/Web/JavaScript/Reference/Statements/async_function より。(720で貼り損なったので) async function concurrentStart() { console.log('==CONCURRENT START with await=='); const slow = resolveAfter2Seconds() // ただちにタイマーを起動 const fast = resolveAfter1Second() // ただちにタイマーを起動 // 1. これは即時実行される console.log(await slow) // 2. これは 1. の 2 秒後に実行される console.log(await fast) // 3. fast はすでに解決しているので、これは 1. の 2 秒後 (2.の直後) に実行される } 757 名前：デフォルトの名無しさん mailto:sage [2021/11/28(日) 20:06:47.00 ID:s59YsBRT.net] 推してる癖に間違えるくらい千差万別なのね 758 名前：デフォルトの名無しさん mailto:sage [2021/11/28(日) 20:25:18.89 ID:Abxhe3pm.net] >>744 間違えたのは俺の問題であって、C#もJSもawaitの書き方は同じ。 https://developer.mozilla.org/ja/docs/Web/JavaScript/Reference/Statements/async_function https://docs.microsoft.com/ja-jp/dotnet/csharp/programming-guide/concepts/async/task-asynchronous-programming-model 759 名前：デフォルトの名無しさん mailto:sage [2021/11/28(日) 20:31:19.41 ID:AhuL0Pkx.net] >>710 一回だけ使うはずなのを二回以上使うと不具合があるのが問題とか言い出したら 副作用のある関数の呼び出しも問題ってことになるよな 「単一の結果の生成をもって完了するというセマンティクス」というのもないし 760 名前：デフォルトの名無しさん mailto:sage [2021/11/28(日) 20:36:54.41 ID:Xc/smr1I.net] まあゴル同士で複雑なハンドシェイク的な値のやり取りはしない方が良いね 少なくとも俺はバッドパーツ認定してる 結果をkey-value storeに吐くとかそういう使い方しかしてない 761 名前：デフォルトの名無しさん mailto:sage [2021/11/28(日) 22:35:18.85 ID:igoyS+tp.net] >>746 そうだね 副作用があって2回呼び出したら死ぬ関数より、冪等な関数の方が望ましいよね だから単一の結果を生成するだけの処理にchannelを使うのはクソだよね 762 名前：デフォルトの名無しさん mailto:sage [2021/11/28(日) 23:26:53.57 ID:m82RP4Nz.net] >>748 副作用のある関数もクソということになるだろうって話だがな 呼び出すべきじゃないところで誤って呼び出すと不具合があるから問題だと言い出すんだから 763 名前：デフォルトの名無しさん mailto:sage [2021/11/29(月) 00:36:52.64 ID:M92LX90q.net] C#おじさんの大暴れ回 764 名前：デフォルトの名無しさん mailto:sage [2021/11/29(月) 02:15:08.24 ID:JPr9HHY7.net] >>742 C#もそうなりましたが…。 https://qiita.com/inasync/items/6417933e258b53b5bbd3 こっちでは似たような事やってるね。 https://www.buildinsider.net/column/iwanaga-nobuyuki/009 あんまり知らんだけでは？ 765 名前：デフォルトの名無しさん mailto:sage [2021/11/29(月) 09:11:23.82 ID:kiCwAGEX.net] >>749 それはその通りで、一般論として、副作用のない関数より副作用のある関数のほうが相対的にはクソだろ？ 本来副作用の必要がない場合でも常に副作用のある関数として実装しなければならないとしたら、本来例えば半分程度で済むはずが全てクソ関数になっちゃうじゃん それがchannel 766 名前：デフォルトの名無しさん mailto:sage [2021/11/29(月) 11:31:15.42 ID:Ulxk0pae.net] まあGoの設計思想的としてはそもそも非同期関数を作っちゃいけないんだろうな 常に非同期で使用することが明らかな場合でもchannelを引数に取るような関数をパッケージ外に公開するような設計はすべきじゃなくて、 普通に同期関数にしといて使う側で必要に応じてgoroutine使えということなんだろう 767 名前：デフォルトの名無しさん mailto:sage [2021/11/29(月) 12:15:00.68 ID:ofvG7nI/.net] え？goroutineにチャネル渡さなけりゃクロージャで渡すしかないから共通関数にできんし ちょっと何を言ってるのか分かりませんね 768 名前：デフォルトの名無しさん mailto:sage [2021/11/29(月) 12:15:45.71 ID:ofvG7nI/.net] 外部関数 769 名前：デフォルトの名無しさん mailto:sage [2021/11/29(月) 12:23:12.94 ID:ofvG7nI/.net] ツアーでもチャネル渡すコーディングしてるよ https://go-tour-jp.appspot.com/concurrency/2 770 名前：デフォルトの名無しさん mailto:sage [2021/11/29(月) 12:35:27.53 ID:O0SZji1w.net] tourはあくまで機能の紹介だろ。 hello worldを実務で書くか？ channelの何が気に食わんの？デッドロックするところ？ 別に後続の関数投げても良いんだぞ。 771 名前：デフォルトの名無しさん mailto:sage [2021/11/29(月) 12:39:01.25 ID:g6qk7DwE.net] >>754 >>753 が言ってるのはライブラリの公開関数の話で、753のコメント通りでしょ goroutine使えば同期関数を簡単に非同期にできるから、ライブラリの高階関数は同期にせよ、っていう思想っぽい 標準ライブラリにもチャネルを受け渡しするやつはあるのかもしれないけど、少なくとも俺はしらない 772 名前：デフォルトの名無しさん mailto:sage [2021/11/29(月) 12:46:47.06 ID:ofvG7nI/.net] 標準のライブラリは低レベル機能しか持たせてないじゃん だからといって、非同期に使うことは好ましくないという設計思想だとかかなり無理があるだろ ツアーは基本的な使い方のサンプルなんだから、基本的に非同期で動かす関数を書くにはチャネルを渡しましょう！と大々的に宣言してる証拠じゃないのか？ 773 名前：デフォルトの名無しさん mailto:sage [2021/11/29(月) 13:18:56.71 ID:rw4mU1bL.net] まだやってた 774 名前：デフォルトの名無しさん mailto:sage [2021/11/29(月) 13:51:14.56 ID:DbScqZpC.net] 好きだよね〜 775 名前：デフォルトの名無しさん mailto:sage [2021/11/29(月) 14:19:10.41 ID:O40DgaQc.net] >>752 >本来副作用の必要がない場合でも常に副作用のある関数として実装しなければならないとしたら そんなのがどこから出てきたんだか。 呼び出すべきじゃないところで誤って呼び出すと不具合があるからクソだと言い出すなら 入出力とか、副作用を持つ関数もクソということになるって話だがな 戻り値を変数に入れて置けば良いだけなのにそれを出来ずに 2回呼び出すと不具合が起こると文句を言ってるんだよな 776 名前：デフォルトの名無しさん mailto:sage [2021/11/29(月) 16:44:46.78 ID:M92LX90q.net] チャネルが理解できないC#おじさんがID変えて自己弁護しながら暴れてるだけ >>752 「副作用のない関数より副作用のある関数のほうが相対的にはクソ」 一般的には手続き型言語であればサイドエフェクトがある関数が普通で、純関数言語のようなほとんど副作用の 無い関数などはI/O処理などでビックロックなどで誤魔化してるに過ぎない。 >>753 そもそもGoは全部が非同期・並列だから逆。メインでさえgoroutineの１つで、デフォルトでGOMAXPROCS 「channelを引数に取るような関数をパッケージ外に公開するような設計はすべきじゃなく」これも逆です。 structには本来はchannelやcontextを含めるべきではなく、引数に取ることが推奨されている >>759 「標準のライブラリは低レベル機能しか持たせてない」最近の言語は、標準のライブラリという重大なクソを 薄く小さくするのが流行り、なぜなら稚拙な標準のライブラリをリリースしてしまい、後からもっと効率的で 理論に裏付けされたライブラリが出てくる。そしてクソな標準が互換性のために直せない。薄くて小さい ライブラリは速く、メンテナンスも容易で、依存性も少ない。 逆に、標準のライブラリに重厚長大を求めるのは何かが間違ってる。チャネルを渡すことを使う事を禁忌したい 気持ちが奥底にあるから「証拠」なんて言葉が出てくる。Tourなどのパイプライン処理とかを見ればチャネルを 受け渡すことの効率性と高い非依存が良くわかる。aync系の言語でやろうとしたらミューテックスでロックして 処理の終わりでwaitしてなど極めて並列度が低く、依存性が高く、ゴミのような自己満足が広がる だから遅くて成果物はデカい 777 名前：デフォルトの名無しさん [2021/11/29(月) 19:32:28.88 ID:TPDpg4yk.net] まぁまぁ、顔真っ赤にして投稿するのやめよ？落ち着こうな 778 名前：デフォルトの名無しさん mailto:sage [2021/11/29(月) 20:00:58.25 ID:rw4mU1bL.net] 昨日からなにが言いたいのかさっぱり 自分でも頭おかしくなってるんだろうか 779 名前：デフォルトの名無しさん mailto:sage [2021/12/20(月) 18:58:52.11 ID:S0D0uK3y.net] Go 1.18 Beta 1 is available, with generics, 14 December 2021 780 名前：デフォルトの名無しさん mailto:sage [2022/01/07(金) 00:14:05.77 ID:l4f7h5d/.net] ちょっとかじってみたニワカの感想なんだけど Go言語ってBetter Cって感じだな。 781 名前：デフォルトの名無しさん mailto:sage [2022/01/07(金) 00:38:05.83 ID:j/jugqL+.net] >>763 チャネルを渡すことに積極的な>>759に、真っ赤になってチャネル渡すコーディングを語ってて草 782 名前：デフォルトの名無しさん [2022/02/06(日) 12:21:06.60 ID:SQRLIZAc.net] GoのジェネリックがGo 1.18 Beta 1でデビュー https://www.infoq.com/jp/news/2022/01/go-generics-beta/ func SumIntsOrFloats[K comparable, V int64 | float64](m map[K]V) V type Number interface { int64 | float64 } 783 名前：デフォルトの名無しさん mailto:sage [2022/02/07(月) 09:14:37.90 ID:YCtDYJO4.net] お前らが煩いから… 784 名前：デフォルトの名無しさん mailto:sage [2022/02/19(土) 10:13:03.12 ID:AG6SdX6W.net] 最近goよりrustが気になってきた コンパイラ型の早いモダンな言語ということで安易にgoやってたけど rustにすべきだったか 785 名前：デフォルトの名無しさん mailto:sage [2022/02/19(土) 11:35:19.56 ID:R5yjbcGL.net] rustは学習時間がかかる 786 名前：デフォルトの名無しさん mailto:sage [2022/02/19(土) 13:51:37.16 ID:u5oa6W2x.net] 利用範囲というか得意範囲が違うから興味はない まして癖が強いんで覚えなきゃならんことが多すぎる 出始めのJavaより癖が強くないかあれは 今は皆が馴染んだけどJavaのIO周りとか、解らねぇ！という声が多かった記憶 だから少なくとも10年は待つのが正解 787 名前：デフォルトの名無しさん mailto:sage [2022/02/19(土) 15:23:37.32 ID:AlOKsuc0.net] >>771 用途が違うんだから、両方やればよろし 788 名前：デフォルトの名無しさん mailto:sage [2022/02/19(土) 16:39:42.26 ID:lVeS0ElI.net] Goは向いている適用範囲が狭い 他の言語も併用せざるをえない 789 名前：デフォルトの名無しさん mailto:sage [2022/02/19(土) 19:00:07.51 ID:ZkbC0IWU.net] それでいいんだよ 790 名前：デフォルトの名無しさん mailto:sage [2022/02/19(土) 23:50:48.59 ID:xGD28DxW.net] Go 1.18 Release Candidate 1 is released 2022/02/18 2:04:17 (昨日) https://groups.google.com/g/golang-announce/c/QHL1fTc352o/m/5sE6moURBwAJ 791 名前：デフォルトの名無しさん mailto:sage [2022/02/20(日) 11:21:21.17 ID:VbAVfRtD.net] > 早いモダンな言語 速くもないしモダンでもない 792 名前：デフォルトの名無しさん mailto:sage [2022/02/20(日) 12:17:41.07 ID:1fyiha6j.net] 1.18 finalは3月に持ち越しか 793 名前：デフォルトの名無しさん mailto:sage [2022/02/20(日) 12:35:50.50 ID:coxlbRTF.net] 単体のマシンで並列処理をひたすらに行うという涙ぐましい用途特化よね 無駄金がありゃ分散化してロードバランサ使ってしのぐと思う 794 名前：デフォルトの名無しさん mailto:sage [2022/02/20(日) 13:24:25.85 ID:QnKhevyf.net] Goは並列処理が書きやすい簡単な静的型付け言語って感じよな Goの文法はモダンとはとても言えないけど、わりと早いビルド、gitとの連携、fmt、とかもろもろのエコシステムを総じて言えばモダンと呼べそうではある 逆に、例えばD言語は文法が良いのにエコシステムがウンコだったから人気出なかったんだと思う 795 名前：デフォルトの名無しさん mailto:sage [2022/02/20(日) 15:45:27.00 ID:coxlbRTF.net] 分散しないでも程よく性能が出るって点から、ネットワーク関係の組み込み機器(ルータとか)に向いてるような気もする(気がするだけ)んだけど、特に席巻してるとも聞かないから使われてないのかな 796 名前：デフォルトの名無しさん mailto:sage [2022/02/20(日) 15:47:35.30 ID:coxlbRTF.net] busybox的な作りならメモリも圧迫しないだろという考え 797 名前：デフォルトの名無しさん mailto:sage [2022/02/20(日) 18:28:36.22 ID:VbAVfRtD.net] >>782 ルータの中身なんてlinuxでCだろ 組み込みはCPUパワーと消費電力に厳しいのでC以外に現実的に解がない 逆に言えば、C以外で組んだ時には価格と消費電力でその商品に訴求力が無くなる Cでは実現不可能な程のファームウェアアップデートの頻度が必要な商品もないだろ 798 名前：デフォルトの名無しさん mailto:sage [2022/02/20(日) 18:35:18.72 ID:Y1MJvTk4.net] Google的には組み込み向けはFlutter/Dart 799 名前：デフォルトの名無しさん mailto:sage [2022/02/20(日) 18:37:32.10 ID:VbAVfRtD.net] >>781 goroutineが正解だと間違えた失敗言語だろ このチャレンジ自体は良い事だが、正解はasyncだった 複雑になりすぎたC++を嫌い、またWeb系での最速を求めた連中はRustに行った 型を知らなかったWeb系の馬鹿共には丁度良かったが、そいつらはTSに行った ast木がデフォで出るのは面白いが、あれはプログラマ的にはレベルが低すぎて使えない（自前で正規表現でやるよりはまし程度でしかない） ならいっそのことあれこれやりまくる実験言語にしてもいいとは思うが、仕様の追加は他言語と比べても遅い 現在新規でGoをやる意味はないから、あとは廃れるだけだろ 800 名前：デフォルトの名無しさん [2022/02/20(日) 20:11:46.12 ID:uXMwiVcI.net] web系のバックエンドである程度速度求める層には使われてくんじゃないかな。楽だもん。 個人的にはnull安全じゃない点でもういいやって感じだけど。 801 名前：デフォルトの名無しさん mailto:sage [2022/02/20(日) 21:46:42.94 ID:VbAVfRtD.net] >>787 > ある程度速度求める層 これは基本的にない。 速度が問題になると分かっていて、チームがRustを使える場合、100%Rustを選択する。 Rustが使えない場合、今現在の第一選択肢はTSだろ。 そこそこ速いし、最悪はJSエンジニアを流用可能だし、全く新規に教育するにしてもフロントエンドでも使えるし。 Web系の現場でGoをわざわざ教育する意味はない。 （飽和した市場においては）商品は尖ってないといけないとよく言われるが、Goは今現在尖ってないんだよ。 速度が欲しくてガッツリ組みたければC#でもいいし、実際にASP.NETのシェアは7.9%でPHPに次ぐ第2位だ。(なおGoは0.0007%、Rustはそれ以下） https://w3techs.com/technologies/overview/programming_language TSよりはGoが速いのも事実ではあるが、 https://atmarkit.itmedia.co.jp/ait/articles/1909/13/news133.html googleがrubyを切った時のようにチーム内で言語を統一するなら、今ならJSかTSになる。Goはあり得ない。 今現在もシェアが低い＝使える奴が少ないのだから、このままだと数多のマイナー言語と同様にポシャって終わり。 バックエンドで速度を求める際、最速はRustだけど、これが嫌ならC#で、ここで終わってしまう。 C#の駄目な点は仕様が重量級で勉強するのが大変な事位で、速度も安全性も生産性もGo以上だから。 Goは、速度がある程度必要だが最速である必要はなく、RustやC#は絶対に勉強したくない層向けになるが、これは現実的に無い。 802 名前：デフォルトの名無しさん [2022/02/20(日) 22:04:59.75 ID:uXMwiVcI.net] >>788 なるほどね。 803 名前：デフォルトの名無しさん mailto:sage [2022/02/20(日) 22:33:50.88 ID:uSEnVnLU.net] >>788 JS/TSの人材がNode/Denoでサーバーサイドもいけるからね そしてそれでは性能面リソース面で満足できないならRustが記述しやすくていい 804 名前：デフォルトの名無しさん mailto:sage [2022/02/20(日) 22:37:24.33 ID:x/Ldx69r.net] Rustが使えない場合で、かつ速度が必要な場合にTS使う訳無いだろ。 C#はわかるが。 マルチコアに弱すぎるわ。 C#ではなくGo選ぶケースってのはGoならではのメリットがあるシーンが多い。 805 名前：デフォルトの名無しさん mailto:sage [2022/02/20(日) 23:21:45.49 ID:VbAVfRtD.net] >>791 > Goならではのメリット だからそれは何？って話だろ。 C#で駄目でGoってのは学習コストくらいだが、学習コストが問題ならWeb系ならTS/JSで決まりだよ。 Goはgoroutineかgo generateが大当たりすれば良かったが、そうでない以上、C#に勝てる仕様がない。 現在シェアでボロ負けしてて光る仕様もなければ、このまま沈没以外にない。 Rustを考えれば分かりやすいが、シェアでボロ負けしててもC#に速度で勝てるし、 安全性も一応最高を目指してるから、選ぶ理由はあるだろ。 GoはRustが出てきた時に身の振り方を考えなければならなかったんだよ。 806 名前：デフォルトの名無しさん mailto:sage [2022/02/20(日) 23:56:31.79 ID:KcoG54wC.net] >>792 そのGoroutineだよ。観測範囲狭いのでは…？ C#のasync awaitとスレッドプールは詰まる。 807 名前：デフォルトの名無しさん mailto:sage [2022/02/21(月) 00:13:42.23 ID:lBTJyZA6.net] >>793 asyncな関数を呼べばスケジューラに戻るわけだから 長時間ループで計算のみを続けることでもない限り詰まることはないでしょ 808 名前：デフォルトの名無しさん mailto:sage [2022/02/21(月) 00:16:41.00 ID:GbKjQqyn.net] >>793 詰まるって何が？ これ？なら仕様を知らないだけだね https://oita.oika.me/2016/02/18/task-and-threadpool/ まあいずれにしても、C#で問題があれば、速攻対策されるよ 809 名前：デフォルトの名無しさん mailto:sage [2022/02/21(月) 00:26:24.14 ID:GbKjQqyn.net] あとこんなんも出てきた https://www.rox-note.tech/?p=30 まあスレッドプールはそういう設計なのだから、デフォで問題ない使い方をしないのなら自前で設定してやらないと駄目だね。 でもスレッドプールはプールであって、goroutineみたいにスレッド占有（スタック保持）ではないので、 動いてないスレッドはプールに返されて結果的にCPUは最速で動くはずだけど。 810 名前：デフォルトの名無しさん mailto:sage [2022/02/21(月) 01:57:33.27 ID:889Qm57n.net] 長時間、膨大なタスクを動かしたいんだよ。 811 名前：デフォルトの名無しさん mailto:sage [2022/02/21(月) 01:57:59.42 ID:889Qm57n.net] Go使う前はErlang使ってた案件。 812 名前：デフォルトの名無しさん mailto:sage [2022/02/21(月) 02:23:44.32 ID:YbXysJZO.net] C#ってサーバというかバックエンドで使えるのか 知らなかった 813 名前：デフォルトの名無しさん mailto:sage [2022/02/21(月) 03:00:09.00 ID:lBTJyZA6.net] >>797 膨大なタスクでも途中で何らか入出力すればスケジューラに戻るからタスクが切り替わる 入出力ゼロならばそれは延々と算術計算するだけなのだから別スレッド立ち上げればよい 814 名前：デフォルトの名無しさん [2022/02/21(月) 03:32:12.85 ID:zbwL0D6l.net] goroutineが理解できないC#おじさんがのC#のasyncで騒いでるだけ こいつは数多くの言語が採用してるchannelの原理も理解できない。 815 名前：デフォルトの名無しさん mailto:sage [2022/02/21(月) 08:43:31.09 ID:889Qm57n.net] >>800 スレッドだと必要な数が多すぎて回らない。 シミュレーションの類やってる。 あとバッチで集計処理していくとかも作ってるけど、これも一億行百万ファイルとかが対象。 816 名前：デフォルトの名無しさん mailto:sage [2022/02/21(月) 08:44:21.18 ID:889Qm57n.net] >>801 なるほど。説明しても理解できてないから無駄だし、 理解する気が無いのか。 817 名前：デフォルトの名無しさん mailto:sage [2022/02/21(月) 17:01:09.43 ID:GbKjQqyn.net] >>802 まず、論理CPU数よりも多いスレッドを立ち上げても余計に遅くなる。 だから長時間膨大なタスクの結果を最速で得るためには、 論理CPU数と同じスレッド数で順に処理する事であり、 当たり前だがC#も含めてスレッドプールはこういう設計になる。 膨大なジョブを論理CPU数よりも多いgoroutineでカバーするのは、一般論としては組み方が悪い。 それで速くなる事はないから。 一般的にはその場合はスレッドではなくただのデータオブジェクトとし、論理CPU数と同じスレッド数で回す。 例えば有限要素法のシミュレーションを行う場合、当然データは100万個とかになるが、 CPUが10個なら10分割して、内部は完全に独立して回し、 他CPU担当と隣接してるノードは致し方ないので通信し、CPU10個で協調させながら回す。 これをgoroutine100万個として組むのがGoの思想なのかもしれないが、速くはならないね。 ただし、プログラムは簡単にはなる。 Erlangはだいぶ思想が違う。 あれはスケールアウト時のパフォーマンス低下を回避するために疎結合にしたもので、 実際スケールアウトしてもほぼ性能低下がないのでひたすら物理で殴れるらしいが、 それならErlangでいいよね、でしかない。 尖るってのは、「○○でも出来る」ではなくて、「○○じゃないと出来ない」の事。 Goにはこれがない。 なおC#、.NET4.0の64bit環境では32767個のスレッドが上限らしい。 https://stackoverflow.com/questions/145312/maximum-number-of-threads-in-a-net-app 一般的には、こんなにスレッドが必要な時点で組み方がおかしい、となる。（上記の通り） > 一億行百万ファイル 普通は10CPUなら10分割して1,000万行10万ファイル*10ジョブにして投入、 レイテンシがバラつくようなら例えばさらに10分割で100万行1万ファイル*100ジョブにする。 これを1,000,000 goroutineで回すメリットは何？ 818 名前：デフォルトの名無しさん mailto:sage [2022/02/21(月) 17:23:04.30 ID:889Qm57n.net] >>804 その考え方が古いでしょ。goroutineは軽量スレッドで実質async await+スレッドプールだよ。 https://zenn.dev/hsaki/books/golang-concurrency/viewer/gointernal >>804 チャンネルでfan in/fan outしてる。 819 名前：デフォルトの名無しさん mailto:sage [2022/02/21(月) 17:48:23.98 ID:LC1rF3os.net] >>801 それは例として厳しいかな C#については全く知らないが 例えばRustではchannelの送受信もasync環境ではasyncとなる つまりgoroutineのようにchannel送受信だけを永遠にする長時間タスクがあってもタスクは切り替わる だからそういう例でも大丈夫 おそらくC#でも同じ状況ではないかと推測 820 名前：デフォルトの名無しさん mailto:sage [2022/02/21(月) 18:21:27.64 ID:YbXysJZO.net] goにおけるチャンネルって、概念的には別スレッドのI/Oにデータ渡して発火させる感じだよね 最大スレッド数は開いているチャンネル数以上になることはないし、 メインスレッドには関係ない async/awaitで詰まるってのはawaitが文字通りメインスレッドで待つからって話ではなく？ 821 名前：デフォルトの名無しさん mailto:sage [2022/02/21(月) 18:35:22.44 ID:VpybQnqn.net] goroutineも実質スレッドプールなのは事実だね async/awaitはawaitの区切りでしか中断できないのに対してgoroutineはGoのユーザーコードならどこでも中断できるので、どちらがより詰まりにくいかといえばGoかもしれない とはいえGoもシステムコールの中断はできないから、現実には差は出ないだろうね 822 名前：デフォルトの名無しさん mailto:sage [2022/02/21(月) 18:56:08.62 ID:shT+MRih.net] >>804 Erlangは「スケールアウト時のパフォーマンス低下を回避するために疎結合にしたもの」じゃないよ。プロセスが落ちることを前提にしたもので パフォーマンスなんて考えてないというのは言い過ぎだが、フォールトトレラントでプロセスが落ちるから沢山のプロセスが起動できるようにした ものであり、スケールアウトによる性能の保持はその結果に過ぎない。 「一億行・百万ファイル」このように初めから総数が分かっていれば分割できますが、総数が分かっていない場合には、「一行・10 823 名前：億ファイル」 かもしれない。この時に「絶え間なく処理結果が欲しい」ような場合だとスレッドを張り付けた処理は、分割された連続処理群が終わるまで 待たねばなりません。GoやErlangだとこのような処理の次に続く処理があった場合、パイプライン処理として処理します。 [] [ここ壊れてます] 824 名前：デフォルトの名無しさん mailto:sage [2022/02/21(月) 19:20:21.68 ID:GbKjQqyn.net] >>805 > その考え方が古いでしょ これがGo界隈のキモさだよね。自分らが先進的だと勘違いしてる。 なら、何故その先進的な言語がここまで無視されてるのか考えるべきだよ。 シェアで見たら、誰も使ってない言語だよGoなんてさ。 なおRustはポリコレを持ち込んだ馬鹿がいて同様にウザがられているが。 C#のスレッドは論理CPU数を越える起動用には最適化されてないはず。 だからそういう使い方をするためにはスタックサイズをいじらないといけない。 出来たはずだがやり方は知らん。 ただしそれやっても速くはならないよ。（Goもこの点は同じ） > goroutineは軽量スレッド これも嘘で、今探しても出てこないが、ラズパイ環境でゴミだったからNodeに戻ったというブログが有ったはず。 512MBのRAMで4kB/goroutineでは十分な量のgoroutineを起動できず、(なお今は2KB/goroutineも選べるんだっけ？) Nodeでシングルスレッドで処理した方が断然速かったというもの。 Go信者はgoroutineのコストがゼロだと仮定しているが、まったくそうじゃない。 メモリも食うし、空間が別なんだからキャッシュの張替えも発生する。 (Cが地味に速いのはキャッシュにひたすらヒットするから、というのもある） > チャンネルでfan in/fan outしてる。 意味分からんが、ハードウェアのゲートみたいに各チャネルが複数の入力/出力を持っててネットワークが割と複雑だって事か？ ただこの場合はイベントドリブンで組むことになってて、一応それが一番速いはず。 ハードウェアのゲートを１対１でgoroutineにすることはプログラムとしては記述出来るが、 1億ゲートとかだから4kB/goroutineではオーバースペック過ぎて無駄だ。 ゲートシミュレーションなら精々64Byte/goroutineとかじゃないと駄目だ。だけどこれは無理だろ。 (4kBに縛られてるのはCPUのページサイズに因っているから) 825 名前：デフォルトの名無しさん mailto:sage [2022/02/21(月) 19:28:42.96 ID:shT+MRih.net] >>804 それに「Goにはこれがない。 なおC#、.NET4.0の64bit環境では32767個のスレッドが上限らしい。」という中途半端な知識表現に ついても一般的なOSではスレッドの上限は16bitの域を出ないで少ないのは当たり前で、それはスレッドがあまりにもOSにとっては 重すぎるから。(メモリやコンテキストスイッチなど払う代償が大きい） Erlangはだいぶ思想が違うのはその通りだけど、GoはErlangほどではないが、小さいコストで多数の軽量スレッドを用意したもので あり、これが何のために「Erlangで良いよね？」にならなかったのかといえば、背景にあるのは多数コアを搭載した近年のハードウェアを 生かし切れていない言語が溢れていたから じゃあGoの役割はなんなのと言えば、Erlangはプロセスがネットワーク分散を簡単にできるが（その分遅め）、Goはコンパクトな 1つのマシンの中で上記のようなパイプライン処理をコンパクトに「なるべく早く」出来るよう考えられた。 826 名前：デフォルトの名無しさん mailto:sage [2022/02/21(月) 20:10:22.24 ID:shT+MRih.net] >>810 あんたのほうがキモイけど、C#の先進性なんて何があるの？俺スゲーのシンタックスシュガーだけでしょ？C#がスタックサイズなんて 弄るのはJavaと同じで基本がClassであり、さらには意味不明な意識高いバカが再帰処理などでメモリーが足りなくなるからです。 シングルスレッド言語とマルチスレッドでメモリ量を比べて起動できないなんて意味ありますか？当然作り方次第でご自慢のC#も 同じになるはずですし、RustやCでも同じことが起こりえますが？逆に言えばGoであってもgoroutine数を少なめにして、スレッドで アフィニティを設定して使用するCPUをPinningしてやればほぼシングルスレッドと同じ状態を維持できるはずです 「Go信者はgoroutineのコストがゼロだと仮定」これもダウトです、Goを始めたばかりの人だけです。こんなことを言っているのはｗ 膨大な配列を処理するときにCPUのコア数にきっちり分割して、間にコンテキストスイッチなどを挟まないほうが速いのは当たり前で 鬼の首を取ったように書かなくても多くの人はわかります。だが、Goの開発目的はそうではありません。同様に、Erlangのように プロセスが落ちる前提で高い耐故障性を前提にするためでもありません。 また今はデフォルトは2kのスタックであり、「4kBに縛られてるのはCPUのページサイズに因っているから」とか、どこの知識なのか逆に 問いたいぐらいです。世の中いろいろなCPUアーキテクチャがありますが？現に多くのCPUは4kですが、s390は2kです 最速を求めるのであればGoもC#でもRustでもなく、ランタイムチェックのないCやアセンブラで書いてなさい。またCが速いのは 「キャッシュにひたすらヒットするから」ではありません。ランタイムチェックが無いからです、近年のマイクロベンチマークを１回でも 見たことありますか？近年のCPUのキャッシュサイズはMB級あるのを知っていますか？ 827 名前：デフォルトの名無しさん mailto:sage [2022/02/21(月) 20:13:57.83 ID:889Qm57n.net] >>810 お前読んでるか？ 828 名前：デフォルトの名無しさん mailto:sage [2022/02/21(月) 20:27:03.44 ID:/1Q8PAGZ.net] Goのランタイムのフットプリントはかなりでかいし、GCだけでなくそういうコストも許容できる贅沢な環境で、手抜きをして並列処理を書ける言語だよ ようするに、RustやCで書くのはめんどいしメモリ食われてもいいけど楽してM:Nスケジューラ使いたい、みたいなときには適してる、っていえる言語ではないかと 非同期シングルスレッドしか使わない、っていうんならいろんな言語が選択肢に入りそう 829 名前：デフォルトの名無しさん mailto:sage [2022/02/21(月) 20:29:37.24 ID:LC1rF3os.net] >>812 >「Go信者はgoroutineのコストがゼロだと仮定」これもダウトです これ確かにGoroutineがコスト高いことを知らない人たちが意外に多い 例えばRustのタスクなんかはGoroutineに比べたら本当にコストゼロ スタックレスであるし素朴な状態マシンとしてコルーチンとして機能するだけ だからGoroutineよりリソース的にも軽いし起動も軽いし 巨大なランタイムを必要とするGoと違って非常にシンプル 830 名前：デフォルトの名無しさん mailto:sage [2022/02/21(月) 20:46:25.71 ID:GbKjQqyn.net] >>809 いやErlangは電話交換機用に開発された言語で、メタル回線時代だから最初から物理で殴る前提だ。 （収容数が増えたらラックを増やすしかない） プロセスどうのこうのはOSの話だ。ただしErlangが生まれた80年代はそこまで綺麗に分離してなくて、 ErlangのランタイムがOS扱いだったのだろうけど。 フォールトトレラント性も多分最初から考えられていたのだとは思う。 > 「一行・10億ファイル」 論理CPU数を数万倍越えるジョブがあると分かっているのなら、纏めればいいだけの話。 単に1ジョブ毎に放り込むのではなく、100ジョブ纏めて取ってきてから放り込めばいい。 原理的にはgoroutine*100と同じ速度が出る。 831 名前：デフォルトの名無しさん mailto:sage [2022/02/21(月) 20:54:53.07 ID:GbKjQqyn.net] >>811 > 一般的なOSではスレッドの上限は16bitの域を出ないで少ないのは当たり前 そうじゃなくて、そういう風に作ってないだけ。 つまり、現行のOSでは、スレッドはそこまで使わない前提、そういう風には使わない前提だ。 > 小さいコストで多数の軽量スレッドを用意したものであり、 これをどう見るかだが、本来ならそれ用のOSを作らないといけないんだよ。 ただし実際はGoのランタイムでどうにかなる（=ハードウェアサポート無しでいい）から そういう動きもないのだろうけど。 > Erlangはプロセスがネットワーク分散を簡単にできるが（その分遅め）、 > Goはコンパクトな1つのマシンの中で これはその通り。Erlangは疎結合にしすぎてて、近年のハードウェア向きではない。 とはいえGoもまた行きすぎだよ。 論理CPU数を遙かに越える数のgoroutineを起動しても、速くはならない。 (ただ、コードは簡単に書けるだろうけど) 832 名前：デフォルトの名無しさん mailto:sage [2022/02/21(月) 21:16:05.40 ID:GbKjQqyn.net] >>812 一応言っておくが、俺はC#書いてないぞ。 > C#の先進性なんて何があるの？ いや色々ありまくりだろ。asyncもlinqもそれ以外も色々有ったと思うけど。 今現在メジャー言語で一番先頭走ってるのはC#だろ。 それぞれの機能は他マイナー言語で既にあった物を取り込んだだけなのかもしれんけど。 > C#がスタックサイズなんて弄る 基本いじらないけどね。 デフォで2Mのはずで、少々アホな再帰をやったところで埋まらない。 > シングルスレッド言語とマルチスレッドでメモリ量を比べて起動できないなんて意味ありますか？ これは書き方が悪かったか？ 要はラズパイみたいに貧弱なハードウェアだとGoは機能せず、Nodeの方が速いというだけの話。 goroutineで楽して速いってのは贅沢なハードウェアありきの話。 なおJSはCPUをひたすら突っ走らせる構造にすることをプログラマに強制するから、 その分CPUは無駄なく動く(スタックとかが小さくて済む)ので 同一ハードウェアだと他言語でシングルスレッドにするよりは原理的に速いけど。 (実際は動的言語の分遅いが、TSコンパイラとかが出てくれば面白くなるとは思う） > s390は2kです ほう、メインフレームのはそうなんだ。初めて知ったよ。 ただ知ってるつもりなら、現行で普通に使われてるCPU、例えばx86なりARM等で4kじゃない奴を挙げてみろよ。 ないと思うぜ。 > 「キャッシュにひたすらヒットするから」ではありません。ランタイムチェックが無いからです 違うぞ。ランタイムチェックがないのも要因の一つで、RustやJavaの連中の言い訳になってるが、 それだとCとC++でCの方が速い理由を説明出来ないだろ。 833 名前：デフォルトの名無しさん mailto:sage [2022/02/21(月) 21:18:38.69 ID:NEAxhla5.net] で、Rust vs GoだとConcurrencyどっちがすごいんよ？ https://deepu.tech/concurrency-in-modern-languages-final/ https://i.imgur.com/JGoa8Xe.png これだとRustがさいつよらしいけど 834 名前：デフォルトの名無しさん mailto:sage [2022/02/21(月) 21:25:14.63 ID:/1Q8PAGZ.net] そら最速を求めるならクソデカランタイムが仕込まれてるGoが勝てるわけがない 835 名前：デフォルトの名無しさん mailto:sage [2022/02/21(月) 21:25:40.43 ID:GbKjQqyn.net] >>813 ああすまん、リンクは完全に失念してた。 で、読んだが、何だ？知ってたような内容しか書いてないが。 わざわざ指摘してくるのだから、fan in/fan out の説明があるのかと期待したが。 836 名前：デフォルトの名無しさん mailto:sage [2022/02/21(月) 21:51:34.63 ID:889Qm57n.net] 書きやすさ&ビルドのしやすさ、なんてのも実務的には大切。 ザクッと書いてクロスでコンパイルして大量のサーバに撒く、がめちゃくちゃ楽だよ。 837 名前：デフォルトの名無しさん mailto:sage [2022/02/21(月) 21:52:17.85 ID:889Qm57n.net] >>821 実際、軽量スレッドな事は知らなかったじゃん。 知ってたような事が書いてたけど誤解してたの？間抜けだな。 838 名前：デフォルトの名無しさん mailto:sage [2022/02/21(月) 21:56:26.38 ID:NpsKB2au.net] >>819 フレームワークを使うともっと速くなるみたいで、最初はRust負けててactix使ったら勝ったらしい フレームワークのベンチならこっちにある https://www.techempower.com/benchmarks/ フレームワークを使わないケースだと、同じような実装にする努力の跡は見えるが、結果が言語単品の性能を表しているのか標準ライブラリの質を表しているのか、はたまた測り方なのか、何を表しているのかは知らない 839 名前：デフォルトの名無しさん mailto:sage [2022/02/21(月) 22:05:32.26 ID:GbKjQqyn.net] >>823 いや知っててあの内容だが？ それで納得出来ないのならそれでいいが、 goroutineは軽くはないし、ゼロコストでは全然無いよ。 840 名前：デフォルトの名無しさん mailto:sage [2022/02/21(月) 22:10:46.33 ID:jpP0Lzmf.net] >>819 サンプルコード見たけど酷いな 言語そのものの速度を比較するためのものとは思えない 典型的スクリプトキディのおじさんだ 841 名前：デフォルトの名無しさん mailto:sage [2022/02/21(月) 22:19:17.65 ID:GbKjQqyn.net] >>819 本文は全部読んだ。(コードまでは見てない) まずグラフがどうかだが、これを信じるなら、 Rusr/Java/Goは妥当、異様なのはJS(multi-threaded)の速さだよ。 詳細は本文に書いてあるけど、色々苦労してる。 問題はGo(HTTP)がぶっちぎりに速かったので、これは何だ？って事で、 どうやらライブラリの最適化に因るらしく、 わざわざ他言語でも最適化ライブラリを持ってきて比較し直してる。 で、Rustの方がGoの倍速く、JavaはRustと同程度（微妙に速いが）とかなってる。 ただこれ見る限り、CPU時間とかバラバラだし、 最適化ライブラリを用いたらRust/Java/Goどれも6倍になってるので、 言語の差よりもライブラリの最適化の方が断然重要って事になる。 本人は言語の実力の差をベンチマークしたかったのだろうけど、 ライブラリの最適化で6倍も変わる状況で言語での差をあぶり出すのは難しい。 本人が結論に書いてある事はまあ同意。なお、 > The community consensus when it comes to concurrency performance is quite split. > For example, both Rust and Go communities claim to be the best in concurrency performance. 842 名前：デフォルトの名無しさん mailto:sage [2022/02/21(月) 22:26:10.00 ID:889Qm57n.net] Goは何も考えんでも、公式の実装がハズレ無いのでオーダーさえ考えて実装してれば間違いは無い。 まぁ、そもそもオーダーの計算を失敗しがちなmapとかflatMap無いからな。全部ループ。 そのおかげでめちゃくちゃキャッシュにきれいに載るというのもある。 思ってるより早いよ。 843 名前：デフォルトの名無しさん mailto:sage [2022/02/21(月) 23:09:18.19 ID:NpsKB2au.net] まあ一応書いておくと、最適化云々言ってるけど、標準ライブラリのコンパイルオプションを変えたのでなく、標準ライブラリをactixで書き換えただけな ■標準ライブラリ版(遅い) https://github.com/deepu105/concurrency-benchmarks/blob/nosleep/rustws/src/main.rs https://github.com/deepu105/concurrency-benchmarks/blob/nosleep/rustws/src/lib.rs ■actix版(クソ速い) https://github.com/deepu105/concurrency-benchmarks/blob/nosleep/rust_actixweb/src/main.rs 844 名前：デフォルトの名無しさん mailto:sage [2022/02/21(月) 23:34:23.82 ID:58fVbJqw.net] >>819 .NET他環境の半分程度の性能しか出ないのかよ C#おじさんのご高説はなんだったの？戯言？ 845 名前：デフォルトの名無しさん mailto:sage [2022/02/22(火) 00:01:25.72 ID:ZREIq5yi.net] >>830 Goも同程度に遅いけどな。 と言うかこれはUndertow(Java)がずば抜けて速いんだよ。これは本人も書いてるとおり。 本来は Rust(ネイティブ、ランタイム無し) Go(ネイティブ、ランタイムあり） Java/C#(VM) の順になって然りで、VMと同レベルになってしまってるGoは遅すぎ。 C#は一応ネイティブにする方法はあるらしい。 VMからネイティブにすれば本来は1.5〜2倍速程度は期待出来る。 https://docs.microsoft.com/ja-jp/windows/uwp/dotnet-native/ 現在これが現実的に使えるものなのかは知らん。 ただまあ、同速しか出ないのなら、Goを選択する理由はないだろ。 まともな頭ならC#を選択する。 サーバーシェアだけでも10,000倍違うし、しかもC#の主戦場はunityであって ASP.NETなんて連中からするとオマケかもしれない状況でこれだ。 ただしC#は重量級であって、日曜大工でやろうというものではないが。 846 名前：デフォルトの名無しさん mailto:sage [2022/02/22(火) 00:59:20.84 ID:5DTzEoeU.net] >>831 C#のAOTはこのケースにはあんまりきかないない。 なおそこてはなくてこっち。 https://github.com/dotnet/runtimelab/blob/feature/NativeAOT/docs/using-nativeaot/README.md 刺さるときはめちゃくちゃ刺さる。制約にひっかからないかぎりよく使うよ。 ただこれでもダメならGo書いた方が楽。 Goらしいコードが書けてないのでは？と言う印象だな。 C#の主戦場はUnityは言い過ぎでは？ お前業務システムエアプ勢か？ 847 名前：デフォルトの名無しさん mailto:sage [2022/02/22(火) 01:39:15.30 ID:RKLGE56l.net] >>831 コネクション増える程.NETの性能悪化してgoとの差開いてるだろ 都合の悪い所は見えなくなるのか？ 848 名前：デフォルトの名無しさん mailto:sage [2022/02/22(火) 02:23:56.90 ID:UcWMEN5O.net] >>819 なんでこれdotnetはDebugビルドで実行してるの？？ 849 名前：デフォルトの名無しさん mailto:sage [2022/02/22(火) 10:13:55.17 ID:Ixlcctuc.net] >>818 「ランタイムチェックがないのも要因の一つで、RustやJavaの連中の言い訳になってるが、 それだとCとC++でCの方が速い理由を説明出来ないだろ。 」 おまえ酷い言い訳ばっかだな？ C#のLinqなんて正にシンタックスシュガーだろ。2MBもスタックとってる糞言語やってて口だけ饒舌でよく恥ずかしくないね？ 「貧弱なハードウェアだとGoは機能せず」そんなことはありません、ラズパイのようなハードウェアを使ってGoogleはkubeクラスターと似た機能をN1クラスタで 使ってGoやRustで使用しています、ハードウェア使用効率の良くないNodeでなんか（ほとんど）使用していません。 Nodeが早いのはV8が速い（=Cで書かれている）からであり、「JSはCPUをひたすら突っ走らせる構造にすることをプログラマに強制」などと いう嘘出鱈目で相手の反応を誤魔化すためではありません。JSが言語特性として速い訳ではありません。どう見ても言語に型が本来は無い 言語に速くなる要素があると考えられますか？TSが型を持った言語だとしてもしょせんはJSへのトランスレーターです。 さらにJSの次に使用されているwasmはページサイズは64Kでありx86なりARM等であっても2kに比べたら非常に大きなメモリー管理をされています。 あなたの言う4k/2kでもデカい64Bじゃないとと比べると実に1000倍です。「挙げてみろよ。 ないと思うぜ。」こういう態度があなたを周りの人から 敬遠される１つの要素です。自分で調べもせず、コードで計測したこともなく、伝聞で偉そうな態度は馬鹿にされる要素の１つでしょう また「CとC++でCの方が速い理由を説明出来ない」これがキャッシュのおかげにして説明できないのはあなたがプログラムをほとんど書いたことが 無いからです。配列などの連続するデータをループ処理するときに、if文などのCMP命令が1つ挟まれば、プログラムは低速化します。ループ１回に 付きCPU命令1つで済む処理では、if判定するために2つ以上になるため、多くは2倍程度低速化します。 これは、GoやRustなどは、範囲外にアクセスしてないか常にRange Bounds checkingで行っています。unsafeコードでも外せません。決して キャッシュおかげでも、あなたの足りない語彙のせいでもありません。 850 名前：デフォルトの名無しさん mailto:sage [2022/02/22(火) 11:00:46.11 ID:Ixlcctuc.net] >>827 >>831 また多くのweb系のベンチマークの使用にされているRequest/Secは速さの指標の１つですが、本来は現実的にユーザーに利益のある レテンシー速度のほうが近年は重要視されます。Javaや比較的昔からあるメジャー言語が速くみえるのは、歴史を積み重ねて最適化が 施されているからです。決して言語特性として速い訳でありませんし、Request/secを主眼とした速さの議論は、海外でも馬鹿にされます RustがRequest/secで多く処理できるのはベンチマークなどの超高負荷環境においてgcが走らないからです。現実的にいえばそのような 環境で運用するのではなく、分散させてサーバーを複数立てるのが本来望ましい。上にあげられたような条件も見えない画像で判断する のではなく、重要なのは99%タイルにおける高並列において応答のレテンシーが数秒以内に収まり、なおかつRequest/secが出せることで あり、50%の応答速度が最悪、20秒になってしまうような使い物にならないものを比べるべくもありません https://web-frameworks-benchmark.netlify.app/compare?f=fiber,aspnetcore,express,actix 851 名前：デフォルトの名無しさん mailto:sage [2022/02/22(火) 12:57:29.93 ID:G6nBeheJ.net] 一応訂正しておくよ。以前書いたフレームのベンチでも https://www.techempower.com/benchmarks/#section=data-r20&hw=ph&test=plaintext このベンチが一番近いはずだが、nodejsは決して速くない。 js勢だとjustが速い。 852 名前：デフォルトの名無しさん mailto:sage [2022/02/22(火) 20:04:57.30 ID:B2H8wIkZ.net] > Goらしいコードが書けてないのでは？と言う印象だな。 ある程度書いてないとらしさみたいなもんは分からんわな どんな言語でも よってここに天下一武道会を開催する 各言語のらしさの粋をあつめたコードで Concurrencyの雌雄を決したい

---

---

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

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