Go language part 4

[表示 : 全て最新50 1-99 101- 201- 301- 401- 501- 601- 701- 801- 901- 1001- 2ch.scのread.cgiへ]
Update time : 02/22 10:01 / Filesize : 319 KB / Number-of Response : 1020
[このスレッドの書き込みを削除する]
[＋板最近立ったスレ＆熱いスレ一覧 : ＋板最近立ったスレ／記者別一覧] [類似スレッド一覧]


↑キャッシュ検索、類似スレ動作を修正しました、ご迷惑をお掛けしました

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/
856 名前：デフォルトの名無しさん mailto:sage [2022/02/22(火) 21:28:03.19 ID:ZREIq5yi.net]: >>835
なるほど君が色々分かってないのは分かった。
が、まあ、これは後日だ。

>>836
その比較見てもGoが.NETに勝ってるようには見えないよ。
スループットは劣るが、レイテンシなら.NETの方が伸びないようにチューニングしてある。
そちらの主張するようにレイテンシの方が重要なら、.NETの方がいい。

GoとJSの比較のつもりなら、どうせならNANOexpressを使ってみては？
https://web-frameworks-benchmark.netlify.app/compare?f=fiber,aspnetcore,actix,nanoexpress
ほぼ全部のグラフでJSの方が上になってしまうが。
home見れば分かるけど、fiber(Goで最速)、.NET(C#で最速)、actix(Rustで最速）でexpress(JSでは27番目)は比較として酷いだろ。
知名度で選んだだけかもしれんけど。
nanoexpressが使えるレベルの仕上がりかどうかは知らんが。
857 名前：デフォルトの名無しさん mailto:sage [2022/02/22(火) 21:46:51.86 ID:ZREIq5yi.net]: >>832
> > 制約にひっかからないかぎり
> 動的ロード無し
> evalなし
> COM/WinRT相互サポート無し
> リフレクション無し
まあ普通に静的言語のノリで書いてたら大丈夫だとは思うが。

>>837
俺はサーバー系JSの総称としてNodeと言ってた。
フレームワークを正確に識別する気だったらすまん。

justだとNodeの10倍なら、819のベンチで他言語が6倍速になってるのと同様だから、それなりの値になるのだろう。
いずれにしても言語の特性なんてフレームワークの最適化の陰に隠れてほぼ見えないね。

>>839
just-jsは多分これ。
https://github.com/just-js/just
> A very small v8 javascript runtime for linux only
というわけでNodeの代わりだな。ただしドキュメントがないので実体は不明。
justというほぼ同じ名前の、ただしGitHub垢は別の物があるのだけど、これと組み合わせて使うのかな？
https://justjs.github.io/
858 名前：デフォルトの名無しさん mailto:sage [2022/02/22(火) 21:49:46.37 ID:5DTzEoeU.net]: 別に.netをディスってる訳では無いんだが、代理戦争みたいな真似する理由がわからん。

GoがWebフレームワークのベンチマーク弱い理由はだいたいこの記事にまとまってる。
https://zenn.dev/nobonobo/articles/e651c66a15aaed657d6e
同じ事したら他のフレームワークと同じかもう少し早い。

ヘイトに関してはだいたいこれじゃん。
https://zenn.dev/nobonobo/articles/74808a8d5e6f1e
859 名前：デフォルトの名無しさん mailto:sage [2022/02/22(火) 21:50:53.96 ID:5DTzEoeU.net]: >>843
ホントにやってみて言ってるか？ひっかかるぞ。
860 名前：デフォルトの名無しさん mailto:sage [2022/02/22(火) 22:01:34.94 ID:ZREIq5yi.net]: >>845
リフレクションを常用してるのなら、それは基本的にお前の組み方が悪い。
861 名前：デフォルトの名無しさん mailto:sage [2022/02/22(火) 22:03:10.10 ID:WirMN8li.net]: >>844
「GoがWebフレームワークのベンチマーク弱い理由」が書かれていない記事に見えるがリンク合ってる？
862 名前：デフォルトの名無しさん mailto:sage [2022/02/22(火) 22:43:58.08 ID:jMOKvXgm.net]: >>834
これ。Debugビルドでやって何の意味があるの？そりゃあ最適化されてなかったら遅いわ…
863 名前：デフォルトの名無しさん mailto:sage [2022/02/22(火) 23:07:19.97 ID:B2H8wIkZ.net]: >>844
> https://zenn.dev/nobonobo/articles/74808a8d5e6f1e
> Rob Pike氏はあらゆる既存のプログラミング言語が互いに発案した特徴を取り込みあって、
> あらゆる言語が同じような言語に向かっていることに異を唱え、そうではない言語を作ろうとして
> (略)
> Goのアイデンティティのひとつに「厳選された必要十分な機能セット」というものがあり、
> 過去ここを壊すような多くの提案には「No!」が突き付けられてきました。

Goはなんか言語としてのウリが弱くて
逆に言語としての機能不足を非難されたりするけど
ここにC++を持ってくると急に腑に落ちるな
ブヨブヨに肥大したC++の現状の惨状を見ると
そらロブの言いたいことも分かるってもんよ
Goに対する一部の批判はそら的外れってもんよ
864 名前：デフォルトの名無しさん mailto:sage [2022/02/22(火) 23:13:49.19 ID:S7d5HFwX.net]: かなり後発のRustが先発言語たちから厳選された機能を洗練して上手く採り入れていって
純粋に言語としての比較ではGoを抜き去って行った感がある
865 名前：デフォルトの名無しさん mailto:sage [2022/02/22(火) 23:17:51.21 ID:6QeruhOo.net]: 個人的に趣味でゲーム作ってて、
（仕事はPythonとかのスクリプト言語）
そのバックエンドに高速そうなGo使おうと思って勉強してるんだけど
そういうレベルの俺からするとRustはものすごく難しそうというか、厳しそうに思えてしまうんだよな
メモリリークって一番やりそうだもん
866 名前：デフォルトの名無しさん mailto:sage [2022/02/22(火) 23:25:51.36 ID:WirMN8li.net]: >>851
何か勘違いしてない？
RustはC言語と違って
使われなくなった瞬間に自動的にメモリ解放してくれる言語
867 名前：デフォルトの名無しさん mailto:sage [2022/02/23(水) 00:01:15.68 ID:LYKR6qmH.net]: >>846
リフレクション以外もひっかかる。
試してから言え。

>>847
APIの秒間リクエスト処理数比較などもそうです。HTTPヘッダパース遅延評価機能を持つものと持たないもののベンチマーク等ではヘッダへのアクセス不要な簡易負荷で比較しているような状況になりがちです。特にデータベースアクセスなどを伴わないような場合だとその性能差は大きな差として現れます。

実際、Goのサードパーティライブラリ「fasthttp」はHTTPヘッダパース遅延評価機能を持っており、この場合ベンチマーク結果の数値は最速実装にかなり近づきます。しかし、HTTPヘッダは実用の現場の場合、評価しないわけにはいかないので実用上の性能は標準のnet/httpと大差ないということが実際にあり得ます。
868 名前：デフォルトの名無しさん mailto:sage [2022/02/23(水) 00:49:45.29 ID:eS2QASPG.net]: >>852
ガベージコレクションが無いって事しか知らない
違うのか
ってかスレチかもすまん
869 名前：デフォルトの名無しさん mailto:sage [2022/02/23(水) 06:07:59.41 ID:hfe0Ou5T.net]: >>854
Rustは使われなくなったら即座に自動的にメモリを解放してくれるため
ガベージコレクションを必要とせず速い
870 名前：デフォルトの名無しさん mailto:sage [2022/02/23(水) 07:24:21.07 ID:0walZlbe.net]: >>842
nanoexpressなんて、HTTPもまともに実装してないウンコでドヤァってんじゃねーよハゲ(笑)しかも、star数3桁だぞｗ
https://www.techempower.comの不正だらけのベンチマークばっかり見てるから、(xxで最速）なんて恥ずかしい言葉が言える。
高機能なほかがサポートしてないフルスタックとHTTPの単純なGETだけ最速になるように調整(不正ではないが）したもの比べて、
中身を、全く見てないのに「なるほど君が色々分かってないのは分かった」なんてマウント取りたいだけだろお前？

普通に使用されてるもので選ぶのが当たり前、「nanoexpressが使えるレベルの仕上がりかどうかは知らんが」しらねーのかよハゲ！！
知らないのに語りすぎだろｗ

>>843
そのくせ次に出してくるのがjust-js/justかよｗｗｗ、just.cc, main.ccがJSに見える病ですか？just-jsのmarkdownにも書かれてるが
「non-async by default - can do blocking calls and not use the event loop」
おまえがさんざ言語の優位性として言ってるasyncすらデフォルトですらねーわｗｗ

なんでおまえ最速が好きなの？
「言語の特性なんてフレームワークの最適化の陰に隠れてほぼ見えない」何度も言ってるけど、明らかに高い同時並列接続はシングル
スレッドな言語では限界があり、レテンシーが極端に落ちるのどんなベンチマーク見てもその傾向。明らかに言語の傾向は出ています、
Rustがreq/secでスループットが「最も高い」という結果も、明らかに言語特性として高負荷でgcではないのでSTWが動かないという
言語の特性がキチンと出ています。
Goが非常に高い同時の並列接続数での、レテンシー速さが一部では、Rustよりも上回る場合があることが、ベンチマークで出ています。

「フレームワークの最適化の陰に隠れてほぼ見えない」見えないのではなく、おまえは見ることが出来ないだけ。だからjust-jsなんて
恥ずかし気もなく言い出せる。オープンソースなんだからコードぐらい追えよ？
871 名前：デフォルトの名無しさん mailto:sage [2022/02/23(水) 09:06:25.43 ID:7ZO0r/jE.net]: >>851
順当なら間違いなくJS/TS。
どのみちフロントエンドも必要だからJSは習熟するしかない。
それでバックエンドも出来るのだから、Python鯖が嫌ならJS鯖になる。

ただしJSは最速ではない。
(アーキは良いのでコンパイラが出てくれば最速になる可能性もあるが、5～10年は無いだろう）
だから順当には、JS鯖で負荷的に無理になったタイミングで移行を考えればいい。
そして個人レベルのゲーム鯖でこれが必要になる事はまずない。
もし仮に大当たりしてこうなっても、マネタイズがそれなりに出来ていれば、人を雇う事/外注も出来る。

もしコンピューターについて学びたいと思ってるのなら、順当にはCになる。
Rustを最初にやっても、色々意味が分からないはず。
一般的にはRustはC->C++->Rustと学ばないと良さを理解出来ないと言われていて、
Rustやるんだったら結局はCもやる事になるので、最初からCやっとけとなり、
「RustのおかげでRustよりもCを学ぶ連中の方が多くなってしまったではないか！！！！」とRust界隈で話題になってたのが2019だったと思う。
ただし最終的にRustを使うつもりならCの熟練者になる必要はない。ただ、知っておく必要はある。

この辺最近、こいつらはこの処理が何故重いのか全く理解出来てないんだな、と感じ
872 名前：る事が多い。 これはコンピューターが複雑化した事もあるが、コンピューターの物理面を知らないで済ませようとしてるからだ。 （論理的なプログラミングに留めている。それを目指したのがJavaでもあるのだが） だからベンチマークに頼らないといけなくなる。何故それが速いか遅いかを自分で判断出来る能力がないからだ。 だからこの辺、自分で判断出来る能力が欲しければCをやるべきだし、 とはいえ現実的にはフレームワークを使うわけで、フレームワークが最適化されてればそれで良し、駄目なら駄目、 と一生ベンチに頼るのもありだし、現実的にこれでも大した問題がないのも事実だろう。 この場合はCなんてやるだけ無駄、ってことになる。だからどういう能力が欲しいかを自分で考えるべきだね。 ちなみにRustもTSもNodeも無かった時代に同じ事を聞かれるとGoと答えただろう。 Go界隈の最大の問題はここで、最初に運良くブーストした？のに浸ってる。 今はもう違う事を認識出来てない。 []: [ここ壊れてます]
873 名前：デフォルトの名無しさん mailto:sage [2022/02/23(水) 09:13:45.39 ID:hfe0Ou5T.net]: >>857
なぜ不便なCを勧めるのか理解できない
Cをやるくらいなら自動的にメモリを解放してくれるRustが楽で良い
スクリプト言語と似た感じで便利にプログラミングできる点も良い
874 名前：デフォルトの名無しさん mailto:sage [2022/02/23(水) 09:22:59.07 ID:bUSsBe0W.net]: Cもなんだけど、TSなんか特に。
マルチコア使うのがめちゃくちゃ下手な言語を、どうしてGoの対抗馬に持ってこれるの？
それら全ての言語を使ってないのでは？

nodeはnodeで便利だがGoと代替にはならんよ。
RustはRustで早いけどGoの代替には簡単にはならない。
875 名前：デフォルトの名無しさん mailto:sage [2022/02/23(水) 09:27:29.73 ID:3VU0Qb68.net]: objective-c: objectiveが売りなんで頭にもってきたネーミング
c++: cのフリしつつ拡張するつもりの邪悪なネーミング
go: いちにーさんしーごーでシンプルにしーの後に躍り出る命名
876 名前：デフォルトの名無しさん mailto:sage [2022/02/23(水) 09:46:33.29 ID:7ZO0r/jE.net]: >>858
モロクソ書いてるだろ。3行しか読めない馬鹿か？

オレオレゲーム鯖立てるつもりならJS/TS、個人ゲーで負荷的に無理になることはまず無いし、フロントエンドでどのみち使うし。
コンピューターについて学ぶつもりならC、Rustを先にやったところでRustを使えるようにしかならない。
現段階でGoを選ぶ理由がない。Goを学ぶ事が目的ならどうぞだが。
877 名前：デフォルトの名無しさん mailto:sage [2022/02/23(水) 10:36:48.23 ID:EqZ7VJsi.net]: フロントエンドなら最近はWASMが増えてきて記述言語で一番適していて多数派がRustといった状況
もちろんサーバーサイドもRustで行ける
Goは巨大ランタイムのせいでWASMと相性がよくない
878 名前：デフォルトの名無しさん mailto:sage [2022/02/23(水) 11:07:50.59 ID:bUSsBe0W.net]: >>862
そもそもGoは外部と相互運用する事を前提としてない言語だと思う。
少し互換性は失われるけど、isomorphicにしたいならTinyGoかなぁ。
879 名前：デフォルトの名無しさん mailto:sage [2022/02/23(水) 11:12:09.17 ID:vCUIsgzX.net]: node-jsもjust-jsもJavaScriptの実行環境。just-jsでも
(async()=>{await Promise.all([...Array(10)].map(async(_,i)=>{just.print(i);}));})();
が普通に実行できる。並列かどうかは知らない。
880 名前：デフォルトの名無しさん mailto:sage [2022/02/23(水) 12:45:46.30 ID:gMbnXrXW.net]: JSである以上、asyncなんて書いてもコールバックであり並列でもなければ、平行ですらありません。というかほんの数年前のJS使いなら
setTimeout()と書いて非同期タイマー呼び出しぐらい理解してるはずなんだが？今では、Nodeなら、nextTick()だろうけど
普通に実行できるとか、そりゃ言語仕様としてGoogleが携わってるV8使ってんだから出来るでしょうよｗ
just-jsおじさんｗ
881 名前：デフォルトの名無しさん mailto:sage [2022/02/23(水) 13:09:37.82 ID:bUSsBe0W.net]: JavaScriptのアーキテクチャが良いと言うのもよくわからんよな。
シングルスレッドだし、別プロセスは前から立てれたが、別スレッドを満足に立てられるようになったのは最近。

epoll使ったイベントループの事を褒めるのであれば、それこそGoのselectの方が賢いんだし。
882 名前：デフォルトの名無しさん mailto:sage [2022/02/23(水) 14:41:59.08 ID:vCUIsgzX.net]: 一応書いておくけど何かをディスってるわけではないよ。訂正してるだけ。
V8はエンジン。言語仕様はES～。
>>856がnon-async by default - can do blocking calls and not use the event loopを引き合いに出していたので、asyncが使えることを示した。
並列になることを期待している可能性もあったが、コードを追って確認したわけではないので、単に「知らない」と書いた。
883 名前：デフォルトの名無しさん mailto:sage [2022/02/23(水) 15:37:31.02 ID:7ZO0r/jE.net]: >>866
JSが何故ここまで蔓延ってるのか理解出来ない奴がGoを使っているのは分かった。
844の記事にもあるが、「脳死」プログラマ向き言語がGoなのだろう。
>>828の
> Goは何も考えんでも
も同じ方向を示してる。

ただな、みんなよりマシな物を使いたがるんだから、広く使われている物にはそれなりの理由があるんだよ。
そういうのを考えたくない奴がGoを使ってて、その中で満足出来る人にとっては、小さく閉じた幸せな世界なのだろうけどさ。

>>867
> cat hello.js | just --
> non-async by default - can do blocking calls and not use the event loop
このjustってもしかして鯖ではなくコマンドラインから使う用？なら欲しいかも。
今はスクリプト業務でJSを使いたい場合、DevToolのコンソールで無理矢理やってるから。
(冷静に考えてみればNodeでも出来るはずだが、やろうとした事はなかったな…)
884 名前：デフォルトの名無しさん mailto:sage [2022/02/23(水) 15:51:46.27 ID:vCUIsgzX.net]: >>868
just-jsのjustコマンドはnodejsのnodeコマンドに相当
consoleオブジェクトがないなど癖が強いので、一般利用なら個人的にはnodeでいいと思う
885 名前：デフォルトの名無しさん mailto:sage [2022/02/23(水) 19:44:15.21 ID:bUSsBe0W.net]: >>868
はびこってるのか理解できないと言うのは誰かと間違ってないか？
俺はnodeはnodeでアリだがGoの分野とは相容れないと言ってるんだが。
考えないと早くならないcppやrustと対比させてるのであって、jsとは全く対比させてない。
886 名前：デフォルトの名無しさん mailto:sage [2022/02/23(水) 21:47:24.05 ID:EqZ7VJsi.net]: >>865
それはJavaScriptに対してあまりにも無知すぎる
async/await登場以前からJSは並行プログラミング言語
async/awaitはどの言語でも同じだがそれを同期して同期風に記述できる付加機能
ちなみにworkerによってJavaScriptは並列プログラミングも可能
887 名前：デフォルトの名無しさん mailto:sage [2022/02/24(木) 02:41:19.56 ID:aoL+Ya6Q.net]: >>871
上の「 (async()=>{await Promise.all()」がどこに並列があって、関係のないworkerに話が飛ぶんだｗ誤魔化しマウント野郎ｗ
ウッホウッホホ、ドラミングｗ
おまえのご自慢のnanoexpressとかjust-jsのどこにworkerが使われてるんだ？
888 名前：デフォルトの名無しさん mailto:sage [2022/02/24(木) 02:56:09.99 ID:aoL+Ya6Q.net]: >>868
使ったことないのに言い出す奴ｗｗｗ
「JSが何故ここまで蔓延ってるのか」C#おじさんの全方位敵対ｗ
889 名前：デフォルトの名無しさん mailto:sage [2022/02/24(木) 03:05:18.77 ID:QeQ2VGy/.net]: nanoとかjustとか全く知らなくて
JSについては普通にブラウザ上とNode.jsしか使っていないが

>>865
> JSである以上、asyncなんて書いてもコールバックであり並列でもなければ、平行ですらありません。

これは明らかにウソ
JavaScriptは基本的に全て並行プログラミングであって並行に動作する
しかもJSの場合は暗黙的に自動並行開始という特徴がある
例えばGoならgo、Rustならspwanしないと並行開始されないが
JSは非同期関数(＝名前にSyncと付いていないもの)を使った時点でスケジューラに登録され並行開始
これはコールバック使用でもPromise使用でも同じでもちろんasync/await使用でも同じ
Web関連の並行性について話をするなら上記の初歩的な知識は必須な基本事項
890 名前：デフォルトの名無しさん mailto:sage [2022/02/24(木) 03:12:11.21 ID:gyy9N0gw.net]: 並行か？ioか無いとスレット取りっぱなしでラ？
891 名前：デフォルトの名無しさん mailto:sage [2022/02/24(木) 03:15:40.31 ID:yGsnJUen.net]: あっそ、じゃあGoスレじゃなくNodeスレで一人語ってくださいね？言語以前に人としてのマナーを学びましょう
892 名前：デフォルトの名無しさん mailto:sage [2022/02/24(木) 03:22:14.88 ID:9O+r6lMK.net]: >>874
Goの適用範囲のメインがウェブ周辺なのにも関わらずそういう基本的な知識すらないやつ時々いるよな
あと他の言語を知らずしてGoの良い点も悪い点も語れないしな
893 名前：デフォルトの名無しさん mailto:sage [2022/02/24(木) 03:28:06.36 ID:z0JbsGq8.net]: >>875
並行と並列の違いも理解できてないから、あんまり相手にしてもしょうがないよ。Goも知らないっぽい・・・
Goはgo呼び出ししなくてもメインルーチェンがgoroutineだし
894 名前：デフォルトの名無しさん mailto:sage [2022/02/24(木) 03:28:15.25 ID:gyy9N0gw.net]: Goのメイン、Webでは無いだろ。
自分の分野がWebだからハンマー釘になってるのでは？
895 名前：デフォルトの名無しさん mailto:sage [2022/02/24(木) 03:29:04.26 ID:gyy9N0gw.net]: >>878
そうよね…なんか凄く脱力感あるわ…。
この文脈でTSを推す理由が全くわからん。
896 名前：デフォルトの名無しさん mailto:sage [2022/02/24(木) 03:36:49.68 ID:QeQ2VGy/.net]: >>878
君が理解出来ていないのではないか
JavaScriptはWorker使わない限り全て並行であり並列ではない
もちろんWorkerを使えば並列も可
まさかと思うがGoではどうなのかも理解できていなかったりする？

>>880
TSなんて書き込みをしたこともないのでそれは別人だぜ
897 名前：デフォルトの名無しさん mailto:sage [2022/02/24(木) 03:41:58.08 ID:dTNpqM+n.net]: 内容ゼロの真逆のことを言い出した…
Goのメインはパイプラインデータ処理のバッチ系のほうが大きいと思うね、確かにメニーコアをあまり無駄なく活用するからwebも使えるけど
898 名前：デフォルトの名無しさん mailto:sage [2022/02/24(木) 03:45:18.78 ID:9O+r6lMK.net]: 自分と異なる意見を書いてるやつは敵であり、敵はそいつ一人
という思い込みパターンは5chではよくあるな
899 名前：デフォルトの名無しさん mailto:sage [2022/02/24(木) 03:48:08.63 ID:6w5SyGQZ.net]: ID:QeQ2VGy/
「JavaScriptは基本的に全て並行プログラミングであって並行に動作する」
「JavaScriptはWorker使わない限り全て並行であり並列ではない」

(笑)解離性同一性障害かなんなのか、当てるスレ。もうさjavascriptもgoもrustも関係ないなあ
900 名前：デフォルトの名無しさん mailto:sage [2022/02/24(木) 03:50:57.70 ID:QeQ2VGy/.net]: >>884
どちらも正しいが何を言いたい？
JavaScriptは基本的に全て並行であって並列ではない
Workerという後から追加された機能を使ったときのみ並列動作が可能
901 名前：デフォルトの名無しさん mailto:sage [2022/02/24(木) 03:54:14.80 ID:9O+r6lMK.net]: おそらくだけど>>884氏は並行と並列の違いをわかっていないために誤読
さらに暴走して解離性なんちゃら言い出しただけかと
902 名前：デフォルトの名無しさん mailto:sage [2022/02/24(木) 05:26:36.76 ID:cGpWV2sd.net]: はい、ここでトリックです。(goをこよなく愛する方々スレ汚しごめんなさい)

以下動かすとnode.jsでもjust.jsでもブラウザでも約100msになります。
(async()=>{
// justのときは↓のコメント外す
// const console = {log: (arg)=>just.print(arg)};
// const setTimeout = just.setTimeout;
const sleep = ms => new Promise((f)=> setTimeout(f, ms));
const start = Date.now();
const p1 = sleep(100); // タスク1
const p2 = sleep(100); // タスク2
await p1;
await p2;
console.log('end:' + String(Date.now() - start));
})();
もしタスク1とタスク2を逐次実行するとしたら、約200msでないといけません。
タスク1とタスク2を並行に実行したので、約100msなわけです。
903 名前：デフォルトの名無しさん mailto:sage [2022/02/24(木) 07:44:45.85 ID:7j5xGGNI.net]: >>887
jsは自前でsleepしてないから妥当すぎてなんとも
シングルスレッドな言語で自前でsleepしてたらイベントも受けとれんわ
時間が来るまで処理のスイッチがなされないだけ
904 名前：デフォルトの名無しさん mailto:sage [2022/02/24(木) 08:26:03.01 ID:gyy9N0gw.net]: >>881
そうだね。そのWorkerがクソ重いって言ったぞ。
worker跨ぐ並行並列の話では？C#のasync awaitは。

Goはworkerを立てずともなってる。
905 名前：デフォルトの名無しさん mailto:sage [2022/02/24(木) 08:27:43.23 ID:gyy9N0gw.net]: >>887
sleepではなく切れ目無くCPUをガンガンに使う処理入れようか。
906 名前：デフォルトの名無しさん mailto:sage [2022/02/24(木) 08:40:42.53 ID:7t2RQWHZ.net]: >>861
Rust界隈は>>858みたいなバカ多いから……いわゆるゴールデンハンマー。

Rustはもっと学習メソッドと設計思想の解説を強化すべきだと思うわ。一番厄介な所有権についても、実行速度とメモリ安全を両立させるためにどういう管理をしているのか説明すればわかりやすいのに。
907 名前：デフォルトの名無しさん mailto:sage [2022/02/24(木) 08:47:04.56 ID:r4yoOnDZ.net]: sleep自慢なわけです。C#とasyncから始まった今ここに集まってくる奴らは、道具を眺めて優れた何かを作ってない口だけ
自分で作ってもいない日本刀の刀身眺めてニヤニヤしてる気持ち悪いマニアと一緒
908 名前：デフォルトの名無しさん mailto:sage [2022/02/24(木) 08:59:42.43 ID:9O+r6lMK.net]: >>890
スケジューラの類いを作ってことあるプログラマーならば
sleepとは時間が来るまでそのタスクが寝るだけだあって
その間に他のタスクが動くことくらいわかりそうなものだが理解できないのか？

>>888
sleepなどのタイマー類はスケジューリングランタイムが提供すべきものであって自作するものではないぞ
909 名前：デフォルトの名無しさん mailto:sage [2022/02/24(木) 10:19:55.02 ID:gyy9N0gw.net]: >>893
そもそもsetTimeoutで完全にCPUを明け渡してて何が「並行」なんよ。
910 名前：デフォルトの名無しさん mailto:sage [2022/02/24(木) 10:36:22.27 ID:QeQ2VGy/.net]: その>>887が作った例でsetTimeoutでは不満で裏で具体的に動くもので示して欲しいなら
>> const sleep = ms => new Promise((f)=> setTimeout(f, ms));
>> const p1 = sleep(100);

この部分を代わりに公開テストURLの遅延オプション(秒単位)を使って
const sleep = (sec) => {
fetch(`https://httpbin.org/delay/${sec}`);
};
const p1 = sleep(5);
これで順次なら5秒+5秒=10秒かかるところが並行に動いて5秒ちょっとで動くことがわかる

>>891
Rustも難しくない
上記と同じ例ならその部分はこれで動く
let sleep = |sec| {
spawn(fetch(format!("https://httpbin.org/delay/{sec}")))
};
明示的にspawn()する必要がある点以外はJavaScriptと同じ
ちなみにformat!はsprintf相当のフォーマッティングで変数sec部分を展開
どちらも作成されたsleep関数はPromise/Futureを返していてそれに対してawaitできる
911 名前：デフォルトの名無しさん mailto:sage [2022/02/24(木) 12:43:57.22 ID:PkL2tYJv.net]: >>869
ありがとう。
手元のNode環境で公式ドキュメントのサンプルコードで試したら普通に動いたわ。（当たり前だが）
俺が勝手に鯖専用と勘違いしていただけで、最初からそう作ってあるんだな。

>>870
ん？870＝828≠866と理解してるから、誰かと勘違いしているわけではないぞ。
ただまあ、それだと考えたくない奴がGoを使うという見解には事には同意という事か。

> 考えないと早くならないcppやrustと対比させてるのであって
禿(＝ストロウストラップ、C++の始祖の巨人）曰く、「C++はプログラマを育てる言語だ」
その理由は簡単で、「考える」からだよ。
C++はあらゆる事が出来る言語であり、思いつく事は何でも試せる。
だからこそ最速の地位を保っているわけだが、
基本的に安全装置なんて付いてないため（まあC++はそれでも付けようと努力してる方だが）
失敗する時は派手に失敗する。
そしてこの、色々試して、成功したり、失敗する過程で、プログラマは成長していく。

Goが脳死で出来るのは脳死してる奴にはメリットだけど、考えないと(慣れはするが)成長はしないので、
成長したいプログラマはGoには居ないし、Goのプログラマは成長もしてない。
多分俺が感じるGo界隈の異様さはここなのだろう。ギークさが足りない。
まあ俺がGoやる事はほぼ無いからいいんだが。
912 名前：デフォルトの名無しさん mailto:sage [2022/02/24(木) 12:44:19.14 ID:PkL2tYJv.net]: Goはアーキが良くない。中途半端なんだよ。Erlangを考えるなら、
Goはループを廃止して全部goroutineにし、基本map/reduceでmap側をgoroutineにし、
依存性のありなしだけを記述、つまり依存部分はチャネルで接続、
独立部分はgoroutineでランタイム内のスケジューラで状況を見て自動的にループに変更、
とかだと面白かったかもしれん。これなら脳死でひたすらgoroutineに切り出しで済むから。
実際はこれをやったらgoroutineが重すぎて余計に遅くなるから
どの程度goroutineにするか「考えないと」いけないわけでさ。
(この顛末をモロに書いてたのが810で俺が探してたブログ(改めて探したけどやっぱり無いが))
ただ実態はGoランライムが(OSのスケジューラと同様に)
チャネル、スタック、エントリ関数ポインタを持つGoroutine型のオブジェクトを大量に用意して
イベントドリブンで動かしているだけだから、チャネルとスタックの『衣』の部分だけどうしても重くなる。
だから普通に他言語でイベントドリブンで書かれたら絶対にその分負けるわけで、この辺もアーキの良くない部分だよ。
「最速を目指す気はない！」ってのが答えなんだろうけどさ。
ただ、簡単に書ける割には速いってのならJS/TSになってしまうし。
913 名前：デフォルトの名無しさん mailto:sage [2022/02/24(木) 12:45:07.89 ID:PkL2tYJv.net]: 「考えて」判断するなら、コンピューターについて学ばなければいけない。
考える気がないから、学ぶ必要もないし知る気もない。
論理的には正しいし、実際問題として動けばいいのならこれで問題ない。
けど、なんだかね。まあ俺が文句を言う筋もないが。

他言語：オレオレ流でも曲がりなりにもいいコードを書こうとはしてる(結果はさておき)
Go信者：Goで書けば全て落着、と信じてる

だから俺ら他言語の連中は基本的にキョロキョロしてる。
「○○では△△が出来るらしいぞ」「それっていいのか？」「いやあ…」と大体空回りしてるけど、
これは自由の代償として受け止めるしかない。
ここをGoの連中は「そんなの面倒だ。Goで書けば全て問題ないんだ」と信じ切れる奴が集まっているのだろう。
そういう連中もいて、そういう言語も必要なのも事実だろう。
ただ、プラットフォームと心中する気ならC#の方が100倍マシだけどな。
元々はLinuxで使えないという問題はあったが、一応解決された（とはいえ現実的にどうなのかは知らんが）

「No is temporary, Yes is forever.」(844のブログ)はその通りなのだが、結果的には少しタイミングが早かった。
2000年代前半はオブジェクト指向＋マルチスレッド全盛だったから、Goはこれらの問題を解決するようには作ってある。
問題はその後非同期が主流になってしまった点で（まあこれも今後変わるかもだが）
goroutine is foreverであれば、非同期が主流の状況が続く限り埋没する未来しかない。
登場時の問題は解決出来てるが、仕様を追加する気がないのだから、それ以降の問題は何ら解決出来ない、
という当然の状態ではあるのだが。
この点C#は変節に変節を重ね、筋が良かったとは言いがたいが、その時の便利機能を取り込み続けた結果、
「今一番生産性が高い」の地位は何だかんだで保持してる。
914 名前：デフォルトの名無しさん mailto:sage [2022/02/24(木) 12:48:03.88 ID:4cQqvqtW.net]: ひたすら独り語り
915 名前：デフォルトの名無しさん mailto:sage [2022/02/24(木) 12:50:56.09 ID:gyy9N0gw.net]: 自分にある引き出しでしか喋ってないのな。
Go書いたこと結局無さそう。

TS早くないってば。
916 名前：デフォルトの名無しさん mailto:sage [2022/02/24(木) 12:53:50.71 ID:rd5PFIsb.net]: 結局最後は速さにこだわりはじめてRustにすればよかったって流れなんだよな
917 名前：デフォルトの名無しさん mailto:sage [2022/02/24(木) 13:24:03.51 ID:QeQ2VGy/.net]: >>901
たしかに速さ目当てでRustにも手を出したが
言語としての機能が豊富でGoよりもプログラミングが快適ということに気付いた
918 名前：デフォルトの名無しさん mailto:sage [2022/02/24(木) 23:55:59.28 ID:PkL2tYJv.net]: 色々考えて大体整理が付いたので、ついでにつらつらと。

Goは多分文系プログラマには一定の需要がある。残念ながら多分滅びもしない。

例の「2番じゃいけないんですか？」で、
理系：「2番なのは結果であって、1番を目指さないと2番にも成れないよ」と反発したものだが、
文系：「2番目指せば2番に成れるだろ」と思っているからこその話であり、
競争を放棄した連中にとっては確かに良い塩梅ではある。

Cでいいけど、Cでは辛い、という人の為に、
Go = C + GC + String + 最低限のクラス
という事なら、確かにそこそこ使い勝手が良い。
ただし最先端のプログラミングに触れる事はないので、本人が選ぶのは自由だが、若い奴に勧めるのは悪だろう。
ただもう最先端なんて追いたくない、ロートルで良いんだ、Cでほぼ満足だ、という層には、
betterCとしては使い勝手が良い。C++はGCが無いので。

そして進化をしない事を選択した結果、最先端プログラミングをしたい奴は去り、
変わらない事が良い事だとする連中だけが残った。
だから今後とも変わらず、それが良しとされる。
合うかどうかは性格の問題だろうね。俺は無理だが。

>>894
「シングルスレッド」というキーワードに惑わされてJSを理解出来ないのなら、今のC#と同じだと考えていい。
今のC#のasyncでI/Oを切り出せばJSになるし、
JSのasyncでCPUバウンドのジョブをworkerに投げればC#になる。
JSは「メインスレッドがシングルスレッド」というだけで、I/Oはマルチスレッドで動いてる。
819のベンチではMultithreadのNodeはGoの1.5倍速出てるが、clusterというコマンドでCPU数だけインスタンスを立ててるだけ。
リクエストが干渉しないのならこれで問題ないのも事実。
スクリプト言語の癖に奇妙な程速いのは、元のアーキが良いからでもある。だからC#にモロパクされてる。
そしてC#が整備したasync文法をJSがモロパクしたわけだが。
919 名前：デフォルトの名無しさん mailto:sage [2022/02/25(金) 04:57:49.84 ID:aDhOSI3t.net]: その長い主張はまとめるとこういう主張？
言語機能が貧弱なGoは普通のプログラマーにとっては使いづらいだけの存在だけど
豊富な機能や複雑な機能を使いこなせない劣ったプログラマーにとっては需要がある
920 名前：デフォルトの名無しさん mailto:sage [2022/02/25(金) 05:03:43.53 ID:3Y4Z8gJm.net]: rust良いんだけど特定の種類のプログラム
例えば赤黒木とか二重リンクリストみたいなポインタを操作しまくるようなプログラムは明らかに向いてないんだよな
921 名前：デフォルトの名無しさん mailto:sage [2022/02/25(金) 08:15:32.32 ID:TaGUkQP3.net]: >>905
unsafe使いまくるから、野良ライブラリに任せないで標準ライブラリ用意して欲しいよな。
922 名前：デフォルトの名無しさん mailto:sage [2022/02/25(金) 08:30:45.32 ID:u7rOKKj6.net]: >>906
それは標準ライブラリの位置付けに誤解がある
Rustでは最小限のものしか標準ライブラリに入れない方針を明確にしている
だから各用途ごとの重要なライブラリは全て外部にある
例えばasync/awaitやFutureの枠組みは言語仕様と標準ライブラリにあるが
そのための非同期ランタイムは外部にある

あとunsafeの認識は大丈夫と思うが念のため
unsafeは内部に閉じ込めて安全な公開インタフェースを持つ型(type)やモジュールを作るために存在している
だから標準ライブラリも内部はunsafeだらけだが公開インタフェースを用いる限り安全が保証されるといった具合い
どのような安全なインタフェース体系にするかは用途ごとに異なるためそれぞれに適したライブラリを選ぶか自作すればよい
923 名前：デフォルトの名無しさん mailto:sage [2022/02/25(金) 08:39:36.17 ID:ifNOEbaN.net]: >>903
文系理系の切り方も謎だけど、
「適切なところに適切な道具を持ってくる」というのはエンジニアリングの基本。
誰彼構わずF1マシンに乗っても工数だけかかる。銀の弾丸は無い。

JSのasyncはworkerには投げられない。Promiseベースのworkerへの割り振りは単純にはならない(できない)。
async/awaitをなんとかしようとすると例外のためにスタックを持ち回る必要がある。
そしてclusterはマルチプロセス。

もしかしてnodeもエアプなの？
924 名前：デフォルトの名無しさん mailto:sage [2022/02/25(金) 08:47:26.78 ID:apxGtOuK.net]: >>907
その方針がRustのダメなところだという話だよ。goは一応"Build fast, reliable, and efficient software at scale"というコンセプトからはあんまり外れていない。
Rustはメモリ安全性が最大のコンセプトなのに、メモリ安全性から外れる部分をカバーしない方針はコンセプトと矛盾している。
925 名前：デフォルトの名無しさん mailto:sage [2022/02/25(金) 08:55:53.55 ID:u7rOKKj6.net]: >>909
何が問題なのかその文章からはわからないから明確に述べてほしい
RustはC++の方針の失敗を反面教師として上手く機能している
Goの良さはもちろん承知しているがRust視点から見ればGoは言語機能が貧弱なのに巨大なランタイムでGCもあり互いに真逆の立ち位置にいるわけだから
926 名前：デフォルトの名無しさん mailto:sage [2022/02/25(金) 10:29:26.05 ID:JmFlgtI0.net]: >>904
最新のプログラミングをしたい/学びたい層にはGoは駄目だが、
昨今の他言語は常に肥大化しているので、仕様の更新を潔く諦め、
(15年前のプログラミングパラダイムで良ければ、)
『ちょうどいいプログラミング言語』であるGoには一定の需要はあり続けるはず。

なら10年ごとに「ちょうどいいプログラミング言語シリーズ」として改訂していって欲しいところだが。

> 豊富な機能や複雑な機能を使いこなせない劣ったプログラマー
これはわざとだろうがちょっと悪意が酷すぎる。
というか最近の若い奴はどうやら「全機能を使う事＝使いこなす＝有能」と捉えてる感があるが、これは違う。
プログラミング言語はあくまでアプリケーションを作る道具なのだから、
自分が欲しい機能があればそれで十分で、それ以上は必要ないんだよ。
927 名前：デフォルトの名無しさん mailto:sage [2022/02/25(金) 10:30:28.78 ID:JmFlgtI0.net]: >>908
言語の思想として「2番で良いですよね」があるんだよGoには。（結果的かもしれんが）
俺としては、というか、多分アンチ勢は
「1番を目指した上で1番に成れないのは仕方ないが、1番を目ざしもしないのは駄目だ」という感覚なんだよ。
これが科学分野で競争してる連中の普通の感覚だから。
この感覚がない＝科学分野で競争を強いられてない＝文系、というわけ。

実際レンホー発言の時もそうだったが、学術会議の任命問題でも大概酷かったろ。
その前にコロナ禍で「今の日本でも科学的な物の見方を出来る奴はこんなに少ないのか」とは驚いたが。

この「1番を目指さない」が性格に合うかだよ。
｢1番を目指したい｣連中にとってはGoは武器としては貧弱すぎる。

> JSのasyncはworkerには投げられない
Workerに投げた時点でasyncだろ。接続はonmessageなんだから。
async文法を使えという話ではなく、プログラミングパラダイムとしての非同期(async)だよ。

> async/awaitをなんとかしようとすると例外のためにスタックを持ち回る必要がある。
これについては考えてない。というか、C#はそうしてるけど、あれ意味あるかね？
そもそも俺はtry-catch自体あまりいい仕組みとは思ってない。
大体においてJSではtry-catchが非同期の先になってしまうので不便だし、
リトライする気がなければ放置でも大した問題にならないし。
むしろC#がそこまでしてtry-catchを強引に持ってきた事に驚いた。
(リソース返却のためなら非同期先でcatchでよく、
リトライのためなら終了イベントでフラグ管理して丸々リトライでよいので。《どうせほぼリトライなんてしないように作るわけだし》)
まあ俺はtry-catchに関しては消極派で、Go方式でもまあいいよ程度なので、Promise以前の素のJSのtry-catchでも十分満足してる。
だからバリバリのtry-catch派とは話が噛み合わないかも。
928 名前：デフォルトの名無しさん mailto:sage [2022/02/25(金) 11:17:47.06 ID:9DGl33if.net]: >>912
こういうわかってそうで全くわかってないレスは疲れるわ
929 名前：デフォルトの名無しさん mailto:sage [2022/02/25(金) 11:47:16.86 ID:ydtDuSNe.net]: >>910
「Rustがメモリ安全をコンセプトとするなら、(メモリ安全から外れる)unsafeが必要になる事態を放置するべきではない」ということだよ。
最小ライブラリとかはあくまで開発方針で、コンセプトの根幹となるメモリ安全を犠牲にしてまで優先する話じゃないということ。優先順位付けが間違っている。
まぁ、スレ違いだからこれ以上続けないけど、そういうのを棚に上げてgoを攻撃するのはダサいと思うわ。
930 名前：デフォルトの名無しさん mailto:sage [2022/02/25(金) 11:57:21.98 ID:ifNOEbaN.net]: >>912
2番で良いも何も無くて、まず「全てにおいて1番というシンプルな解は無い」なんよ。
だから「Rustが1番、Goが2番、でも書きやすいからGoを使う」という発想がおかしい。
「この案件にはGoが1番良い」という発想でGoを選定するんよ。
科学分野での競争を強いられた結果、道具が先鋭化しただけでしょ。十分に1番を目指してるよ。

プログラミングのパラダイムとしてのasyncであれば、goは同期関数のように書いてもほぼ全ての行に対してasync/awaitだよ。それがgoroutineなんよ。mainもgoroutineだからね。
それをN:Mスレッドで回すの。

try-catchが全てにおいて良いかと言うとそうでもないから、goは多値で返したんよ。
そうではない言語であればtry-catchは必要だと思うよ。
そしてasync/await・Promise以前のtry-catchは使い物になりません。
931 名前：デフォルトの名無しさん mailto:sage [2022/02/25(金) 12:04:36.06 ID:u7rOKKj6.net]: >>914
それはunsafeを理解していない
unsafeを悪だと勝手に思い込んでいるようだがそれは違っていてunsafeは必要不可欠なもの
まず言語に関係なく「unsafeな操作無しではほとんどの構造を書けないもしくは効率的に書けない」という当たり前の事実がある
そこでRustは「型やモジュールの内部にunsafeを閉じ込めて安全なインタフェースだけを外に出す」という戦略で出来た言語

したがって標準ライブラリか外部ライブラリかに関係なく両方とも
・それらが提供する型やモジュールの内部はunsafeが存在する(もちろんゼロの場合もある)
・それらが提供する型やモジュールの外部インタフェースは安全である(ことが求められる)
932 名前：全てがこの原則で作られている 一方で従来の言語C/C++ではunsafeな操作がプログラム全体に散在してしまい安全性を保証できなかった []: [ここ壊れてます]
933 名前：デフォルトの名無しさん mailto:sage [2022/02/25(金) 12:10:17.45 ID:aDhOSI3t.net]: >>912
RustはGoと異なり非同期タスクをスタックレスで実現している上に
RustはGoと同じくtry-catchを採用していないね
934 名前：デフォルトの名無しさん mailto:sage [2022/02/25(金) 12:34:23.12 ID:ydtDuSNe.net]: >>916
だからスレ違いと言ってるだろ。
しかも「メモリ安全から外れるunsafeが必要になる事態を放置している」の反論になってないし(標準ライブラリで赤黒木とか二重リンクリストを持っている方が結果的にメモリ安全にしやすいのは変わらない)。
これ以上やるならRustスレにコメしてくれ。
935 名前：デフォルトの名無しさん mailto:sage [2022/02/25(金) 13:28:20.21 ID:aDhOSI3t.net]: >>918
それは君の理解不足
unsafeな操作はプログラミングをする際に絶対避けることはできないけど
それをできる限り小さな狭い範囲に閉じ込め、かつ、その外に影響をもたらさないように設計しよう、というのが根幹
次に、二重リンクリストも二分木もRustの標準ライブラリにある
もし万が一その仕様が気に入らないなら他のクレートを探すか自作すればよい
どこに不満があるのかすら君は言うことさえ出来ずに君はイチャモンを付けているだけ
936 名前：デフォルトの名無しさん mailto:sage [2022/02/25(金) 13:54:38.00 ID:kxjR7eze.net]: >>919
go関係なさすぎ
937 名前：デフォルトの名無しさん mailto:sage [2022/02/25(金) 14:00:53.92 ID:9DGl33if.net]: >>919
完全に同意
938 名前：デフォルトの名無しさん mailto:sage [2022/02/25(金) 16:05:49.05 ID:kxjR7eze.net]: >>919
転送しました
https://mevius.5ch.net/test/read.cgi/tech/1644596656/91
939 名前：デフォルトの名無しさん mailto:sage [2022/02/25(金) 16:13:12.03 ID:iu2arc+w.net]: Rustスレでいつもホラ吹いてて隔離されてるやつだからさ
Go vs Rustみたいな隔離スレ立ててかまいたいやつだけが相手してやるといい
940 名前：デフォルトの名無しさん mailto:sage [2022/02/25(金) 16:57:45.37 ID:u7rOKKj6.net]: >>919
同意
その点を彼は全く理解できてないんだよ
そして彼は>>914でも「unsafeが必要になる事態を放置するべきではない」とか意味不明な主張をしてる
941 名前：デフォルトの名無しさん mailto:sage [2022/02/25(金) 17:20:54.95 ID:kxjR7eze.net]: >>923-924
Rustスレでやれ
942 名前：デフォルトの名無しさん mailto:sage [2022/02/25(金) 17:48:16.43 ID:MtnpFyFt.net]: せっかく対処法教えてやったのに
ちなみにそいついつも一人二役で自分のレスに安価付けるからw
943 名前：デフォルトの名無しさん mailto:sage [2022/02/25(金) 21:14:02.35 ID:aDhOSI3t.net]: >>925
俺が>>919で書いたことはRustも書くプログラマーにとっては基本的な常識なのでRustスレにおいては異論すら出ないため無意味だぜ
その基本的な常識を理解せずに間違ったRust批判をこのGoスレでする人がいたから説明したまで
944 名前：デフォルトの名無しさん mailto:sage [2022/02/25(金) 21:35:23.89 ID:dqMip1aQ.net]: このおじさん勢いあるスレならどこにでも湧くな
945 名前：デフォルトの名無しさん mailto:sage [2022/02/25(金) 21:47:06.20 ID:3Y4Z8gJm.net]: こんなおじさん昔はいなかったのにどこから湧いてきたんだろう
946 名前：デフォルトの名無しさん mailto:sage [2022/02/25(金) 21:57:26.52 ID:cRacAjKI.net]: 退職してすること無くて暇なんじゃね？
947 名前：デフォルトの名無しさん mailto:sage [2022/02/25(金) 22:05:54.67 ID:LgZQhCZj.net]: 観察者効果で生まれた
948 名前：デフォルトの名無しさん mailto:sage [2022/02/25(金) 22:10:44.84 ID:31pfTetO.net]: そのおじさん昔からいるぞ
昔はコテハンも使ってたが相手にされなくなったてやめたみたい
Ruby君と並ぶ有名人
949 名前：デフォルトの名無しさん mailto:sage [2022/02/25(金) 22:50:23.56 ID:9DGl33if.net]: >>925
RustスレはRustそのものの議論をするスレだから他言語との比較はやらないだろ
↓こっちのスレの方に行ってもらったほうがいいと思う。
次世代言語23 Go Nim Rust Swift Kotlin TypeScript
https://mevius.5ch.net/test/read.cgi/tech/1638086359/

もしくは↓このスレがあるんだったら
C vs C++ vs Rust Part.3

golang vs Rust Part.1
みたいなスレを作るとか
950 名前：デフォルトの名無しさん mailto:sage [2022/02/25(金) 22:52:44.27 ID:S5tvR1Yl.net]: Rust vs その他
みたいなスレにまとめてくれ
951 名前：デフォルトの名無しさん mailto:sage [2022/02/26(土) 01:11:35.81 ID:kpnhrKVl.net]: >>915
> だから「Rustが1番、Goが2番、でも書きやすいからGoを使う」という発想がおかしい。
この発想は俺は別におかしいとは思ってない。
例えばアメリカでは「Pythonで書け」と言われるらしいが、これは、
「Pythonは糞だが誰でも読める。前任者がいなくなっても後任者がすぐ見つかる」からであり、
自分個人で完結する物以外は言語特性や好みだけで選べるものでもない。
だからWeb系なら「とりあえずJS/TSで書け」となるのが妥当、という話はすでに788でした通り。
が、まあ、これはさておき、

> 「この案件にはGoが1番良い」という発想でGoを選定するんよ。
だからこれは何なんだよ？という話だろ。Web系ではない、というか、
TS/Node/Rustが出てきた時点でWeb系に最適な解ではなくなったというのは792,857で言ったとおり。

> プログラミングのパラダイムとしてのasyncであれば、
> goは同期関数のように書いてもほぼ全ての行に対してasync/awaitだよ。それがgoroutineなんよ。
これは言いすぎだが、goroutineでasyncの代替になるのは事実だ。
ただ、そういう書き方って基本的にしてないでしょ。
多くの人はマルチスレッドだと思って書いてるし、Goの公式ドキュメントもそうだったと思ったが。
(goroutineは非同期を実現するための物です！！！なんて謳ってたっけ？)

マルチスレッド：同期関数を実行するスレッドが沢山。
　単に高火力を必要とするならスレッドを複数起動して既にあるコードをぶち込めばOK。
非同期：非同期ジョブは『どの順で完了しても』問題なく動くように書く必要があり、
　また、非同期ジョブの実行順/完了順の指定も出来ない。
　（だから数珠繋ぎにするしかなく、コールバック地獄だPromiseだ、という話になる）

だから非同期の場合は根本的にマルチスレッドとはプログラミングを変える必要があって、
具体的にはイベントドリブンで書く事になる。だからJSにはmainがない。
ところがGUIもイベントドリブンで書くので、元々GUI担当のJSとは相性がいい。
（というか、だから当時は異端でしかない「非同期」を採用したのかもしれないが）
952 名前：デフォルトの名無しさん mailto:sage [2022/02/26(土) 01:11:53.09 ID:kpnhrKVl.net]: 逆にmainがあるのは、
mainから入って、高火力が必要ならスレッド起動で同じコードを走行させる、という
マルチスレッドのパラダイムに適した構造だ。
だからmainがある言語、例えばCでGUIを書くと悲惨なコードになる。元々イベントドリブン向きに出来てないからだ。
Goも同じで、基本的にはfork/joinを完結にgoroutineで出来るようにしてるだけで、それはマルチスレッド向けだよ。

つっても非同期スタイルで書けば書けるのも事実だけどな。
819のベンチでGoはAsynchronousTCPとなってるが、これはそういう事なのかね？
なおNode(multithread)に1.5倍も負けてるのは、多分ランタイムの問題だよ。
JSは非同期専用のランタイムであり、それに対してマルチスレッド向けのランタイムに非同期コードを載せて非同期にしたくらいでは並べない。
というか、静的コンパイル言語がJITとはいえ動的言語に大差で負けてる事自体があり得ない事で、
これは「同じ土俵で戦えていない」事を意味する。一つはランタイムで、本来は、
・精々マシンスレッドと同程度～数倍程度のgoroutine用
・マシンスレッドの100-1000倍以上程度のgoroutine用
・非同期コード用
とチューニングや内部構造を変えたランタイムを用意すべきだよ。
資産はコードであり、ランタイムは交換すればいいだけなので、やればいいだけだと思うのだけど。（もうやってるかもしれないが）

あとついでに言うと、ランタイムはやっぱりC/C++で書くべきだよ。境界チェックを遅くなる言い訳にするのなら特に。
Go/Rust共に、「これでCのコードはなくなりました！えっへん！」ってな事をやってたと思ったが、
ランタイムが遅いようでは勝負にならないからね。
「GoをメンテするためにはGoだけ知っていれば十分で、Cを知っている必要はない」ってのはコミュニティの宗教として重要なのは分かるけども、
実用性を考えたら、ランタイムなんて糞速い事が重要であって、何言語だっていいでしょ。
この辺、スクリプト言語はDSLだとわきまえてて、ランタイムを自言語で書こうとかいう無駄な事をやってない。
953 名前：デフォルトの名無しさん mailto:sage [2022/02/26(土) 01:13:02.46 ID:kpnhrKVl.net]: > そしてasync/await・Promise以前のtry-catchは使い物になりません。
これは言いすぎ。try-catchはろくでもないが、無いよりはましだし、同期でシングルデータならまあ問題ない。
だからGoもtry-catchでも良かったはずだが、採用してないところを見ると、
「多くの場合はtry-catchがgoroutineを跨いで使い物にならない」と思ったのだろう。
ゆうてもGo流の多値返しはCよりはまし程度で、それ以上でもないが。

ただ、try-catchがgoroutineを跨ぐ想定なら、
メインスレッドが仕事を起動し、各goroutineで子細の処理をこなす、マルチスレッドの構造を想定している。
非同期なら、メインスレッドはイベントループだけを担い、手が空いたgoroutineにその都度ジョブを発給する事になるけども、
この場合はジョブの起動はgoroutine内からで、try-catchは完全に機能する。
JSの場合はI/Oを非同期にする事を義務づけらてるからtry-catch内にI/Oが入った時点で意味を為さないし、大体このパターンだが、
Goの場合はI/Oも同期で書けるのだから、全く問題ない。
だからやっぱり元々の想定はマルチスレッドで、文法的には非同期も特に苦労せずに書ける、ってことだと思うのだけど。
(JS的な全面的非同期を想定していた場合は、try-catchを不採用にする理由がない。当時でも既にtry-catchが主流だった）

>>917
> RustはGoと同じくtry-catchを採用していないね
これ、今見たところPanic方式らしいが、もしかしてGo由来？

try-catchは好きな人は大好きのようだが、俺にはどうにもあれがいいとは思えない。
個人的には、リソース返却ならC#のusingが正解で、
リトライなら、大体元データが壊れてて無理で諦めるのでPanicで問題ない。（エラー通知だけ出来れば十分）
だからtry-catchは非同期では使えない過去の異物として消滅して欲しかったのだけど、
C#がasyncでも無理矢理try-catch出来るようにしたのでちょっと驚いてる。
そこまでしてtry-catchしたくもないし、する内容もないんですけど、ってね。
ある意味JSの「catchなんてしなくても何も問題ないです」というJavaから見れば卒倒しそうな仕様も、解の一つではあると見てる。
954 名前：デフォルトの名無しさん mailto:sage [2022/02/26(土) 06:42:38.06 ID:BX4iLvdt.net]: >>937
JavaScriptの非同期呼び出しでも普通は無視せずPromiseにcatch付けて捕獲するぜ
例: async_func_foo.catch(err => console.log(err))
あとRustの非同期呼び出しもResultが帰ってくるからエラーを捕獲できる
955 名前：デフォルトの名無しさん mailto:sage [2022/02/26(土) 07:29:58.26 ID:xkMoRRzB.net]: Goを叩く為にJavaScriptを使ってるだけで、JavaScriptの理解度かなり浅いなこのおじさん。
しかしこんなおじさんがずっと暴れてんのか、全然議論できないじゃん。対策としてはワッチョイ導入くらいしか無いだろうね。
956 名前：デフォルトの名無しさん mailto:sage [2022/02/26(土) 08:20:49.61 ID:W5JOGvZg.net]: 長い文章ダラダラ書く人ってプログラマーの素質ないよ
文章を短く簡潔に書ける人ってプログラムも同様に書ける
957 名前：デフォルトの名無しさん mailto:sage [2022/02/26(土) 08:45:19.95 ID:kpnhrKVl.net]: >>938
> 例: async_func_foo.catch(err => console.log(err))
これは字が赤いか黒いかの違いしかないけどな。

まあ俺はtry-catch消極派だから、Go/Rust方式で問題なく、C#の仕様はオーバースペック過ぎるけど、
Goの場合はJSとは違ってtry-catchはそれなりに機能するはずだから、不満持ってる奴もそれなりにいるはずだけど。
（そういう連中は既に去ってる気もするが）
958 名前：デフォルトの名無しさん mailto:sage [2022/02/26(土) 09:09:48.94 ID:yRlIqUsp.net]: 発想が違う、どの案件でも、その案件にとって1番だから使う、と言う言葉が伝わってないのか？
俺も十分、言外の言葉は理解できないタイプだが、流石に通じると思うんだが。

書きやすい、読みやすいからこれを選定した、と言うのは「1番」でしょ。

基本的にそういう書き方してると言うか、自然に書くとそうなる。これはドキュメントに書いてあっただろ。

非同期とマルチスレッドを分けて考えろよ…。

実際にはnodeもそうだけど、C#のTaskなんかに関してもめちゃくちゃ解像度甘いのでは？
959 名前：デフォルトの名無しさん mailto:sage [2022/02/26(土) 09:10:48.16 ID:yRlIqUsp.net]: goだと、非同期スタイルで書けるとかでなくて、ブロッキング関数、同期関数を書いたとしてもgoroutine間では適切にスイッチングされて、他の言語で言うawaitがかかってるんよ。常に低コストで。
それはN:M軽量スレッドだからなし得ることなので、他の言語ができてない以上何とも比べづらい。
960 名前：デフォルトの名無しさん mailto:sage [2022/02/26(土) 09:11:12.66 ID:yRlIqUsp.net]: オール想像で喋ってるよな、こいつ。
961 名前：デフォルトの名無しさん mailto:sage [2022/02/26(土) 09:42:59.75 ID:Cq56y6gH.net]: >>939
ワッチョイは浪人生の自演が捗るだけ
962 名前：デフォルトの名無しさん mailto:sage [2022/02/26(土) 09:45:22.81 ID:Zjg02ogZ.net]: ローニンでワッチョイ消してるやつ正規表現で弾けばええやん
963 名前：デフォルトの名無しさん mailto:sage [2022/02/26(土) 09:55:57.50 ID:UdeBSueS.net]: 自演するのにワッチョイ消すバカはおらんやろ
964 名前：デフォルトの名無しさん mailto:sage [2022/02/26(土) 10:07:05.87 ID:xkMoRRzB.net]: 荒らしの手間が増えるだけで十分価値がある
965 名前：デフォルトの名無しさん mailto:sage [2022/02/26(土) 10:19:30.57 ID:kpnhrKVl.net]: >>943
> ブロッキング関数、同期関数を書いたとしてもgoroutine間では適切にスイッチングされて、他の言語で言うawaitがかかってるんよ。
これは普通はマルチスレッドと言う。Thread/goroutineを複数（マルチ）起動して引っかかったらスイッチングさせるだけなのだから。
そして大概の言語はこれを自然に書けるようになってる。

> それはN:M軽量スレッドだからなし得ることなので、他の言語ができてない以上
これが嘘、というか誤解。他言語でもいくらでもスレッドを起動する事は出来る。（が余計に重くなるので普通はやらない）
goroutineもGo信者が言う程軽くもないのでいくらでも起動していいわけではない。(現実的には)

これを脳死でgoroutineはコストゼロ、だからgoroutineに切り出す事がプログラマの仕事である、と解釈できれば美しいのだが、
これを実際に試して「思ってたよりも全然パフォーマンスが出ねぇ、これならNodeの方が速ぇ…」となった顛末を書いてたのが何度も言ってるブログ。
これは言語と言うよりはランタイムの問題だけど。
966 名前：デフォルトの名無しさん mailto:sage [2022/02/26(土) 11:28:52.99 ID:nWK21oqu.net]: JSのPromiseは非同期の扱いとしてはかなり好き
967 名前：デフォルトの名無しさん mailto:sage [2022/02/26(土) 12:15:41.10 ID:pDCyYMqI.net]: >>949
N:Mのグリーンスレッドであって単なるマルチスレッドじゃない。
単に引っかかったら切り替えるんでなくてスティーリングまでやるのは他の言語の言語標準機能にはErlangぐらいにしかない。

どこが嘘なんよ。
コストゼロでは無いが、いわゆるスレッドよりは遥かに軽いぞ。
968 名前：デフォルトの名無しさん mailto:sage [2022/02/26(土) 12:16:18.51 ID:pDCyYMqI.net]: 総じて知らんだけでは？
969 名前：デフォルトの名無しさん mailto:sage [2022/02/26(土) 12:35:54.23 ID:Zen8kEK8.net]: わからせようとするのが無駄だって何で気づかないかな
970 名前：デフォルトの名無しさん mailto:sage [2022/02/26(土) 12:41:19.24 ID:D1V+AmSx.net]: >>940
論理構成がしっかりしてて読みやすければ長文でもいいんだけどね
このおじさんはそこが壊滅的だから明らかに素質ないわな
971 名前：デフォルトの名無しさん mailto:sage [2022/02/26(土) 12:50:12.55 ID:xkMoRRzB.net]: 抽象化できず同じ事何回も書く傾向にあるから、凄いコード書きそう
972 名前：デフォルトの名無しさん mailto:sage [2022/02/26(土) 12:58:01.48 ID:862GBE0V.net]: >>955
というか、
短い=良い
もしくは
simple=beautiful
というセンスが欠落している。
あんな汚い長文ぞっとするわw
まあ.{50}でNGにしてるけど
973 名前：デフォルトの名無しさん mailto:sage [2022/02/26(土) 13:27:19.11 ID:fRC8OZTs.net]: Goの(疑似スレッド＋)goroutineのパフォーマンス計測っていいやつないの？
↓見つけたやつ
Goroutines Are Not Significantly Smaller Than Threads
https://matklad.github.io//2021/03/12/goroutines-are-not-significantly-smaller-than-threads.html
974 名前：デフォルトの名無しさん mailto:sage [2022/02/26(土) 13:41:54.09 ID:CoGWNwI7.net]: Goってぶっちゃけ言語機能とか割とどうでもよくて、
・ビルドやデプロイや運用がシンプル
・本家の開発体制が保守的で、長期的に安定したサポートが期待できる
という点がメリット
極力作りっぱなしで放置したい類のものに向いてると思うんだよね
Goしかできない奴やGo大好きで使ってる奴もまずいないだろうし、こんなもん執拗に叩いて何がしたいの
975 名前：デフォルトの名無しさん mailto:sage [2022/02/26(土) 13:51:01.17 ID:bMt+E6tQ.net]: CLIツールはともかく一番使われてるWeb APIは放置したいものとは対極だろう
976 名前：デフォルトの名無しさん mailto:sage [2022/02/26(土) 14:05:08.22 ID:nWQ4XblH.net]: APIはむしろどっちかというと放置したい系じゃね？
フロントと表裏一体みたいなのもあるけど、そういうのにGoはあまり採用されないでしょ
977 名前：デフォルトの名無しさん mailto:sage [2022/02/26(土) 14:21:48.69 ID:yRlIqUsp.net]: 確かにそうだな。わかろうとしないし、伝わらない気がしてきた。
Rust最高とRustスレで言っててくれれば良いか。

>>958
これはあるよね。
1つ前のバージョンどころか、それなりに昔のGoのプログラムですら修正せずにコンパイルできる。
978 名前：デフォルトの名無しさん mailto:sage [2022/02/26(土) 16:17:55.72 ID:kpnhrKVl.net]: >>951
やってないのはやる必要がないから。
他言語も馬鹿ではないので、改善の努力はしてるし、いい点があったら平気でパクってる。

(Goはgreenthreadで全て解決！と謳っているわけではないけども、そうだとしたら）
そのアイデアは面白かったが、現実的ではなかった。
（ただしこれはランタイムの問題だから改善の余地はあるはず）

非同期はコードがうざくなるのは事実だが、async文法でほぼ払拭された。
だからみんなパクってる。

まあ完全にループだし、材料枯渇でここら辺で終わりかな。
そりゃ信者の念仏を何度聞いても翻意する事はないよ。俺は文系ではないし。
こちらの見解では説明出来ないデータが出て来たら、分析して、考えを修正するけど。

>>957
virtualの40MBを単純に合算したら、今は4倍軽くて、4k/goroutine時代は2.5倍軽かったという事か。
フットプリントだけの比較ではあるが。
だから極めて単純に言えば、他言語のスレッドでジョブを4つずつ束ねて処理する運用をすれば、
フットプリントでは並んで、速度は余分なスケジューラが入ってない分勝てる事になる。
979 名前：デフォルトの名無しさん mailto:sage [2022/02/26(土) 17:32:36.09 ID:nY3OEggH.net]: >>960
そりゃWebのフロントエンドに比べりゃなんだって放置したい系になるだろ
Webの場合はバックエンドでもWebフレームワークをサポートバージョンに維持する必要があるから
長くても3〜5年すればコードを変更することになる
980 名前：デフォルトの名無しさん mailto:sage [2022/02/26(土) 17:33:24.82 ID:117KIGn2.net]: >>958
言語機能は本当に20世紀に設計された言語なのかと
疑いたくなるね
ほぼGCがあるCを書いてる感覚に近い
C書けない人が書ける言語じゃないと思う
981 名前：デフォルトの名無しさん mailto:sage [2022/02/26(土) 18:00:31.99 ID:yRlIqUsp.net]: >>962
はい、じゃあ言質も取れたのでRustスレに戻って下さいね
982 名前：デフォルトの名無しさん mailto:sage [2022/02/26(土) 18:06:45.33 ID:yRlIqUsp.net]: >>963
そうか？コアAPIに関してはあんまり手を入れないけどな。
Webフレームワーク次第なAPIってどんなの？
983 名前：デフォルトの名無しさん mailto:sage [2022/02/26(土) 18:16:48.89 ID:nWQ4XblH.net]: >>966
SPAのすぐ裏でUIの要件に合わせて作るようなやつのことじゃね？
そういうのはそもそもGoを採用しないと>>960で書いた通りだ
984 名前：デフォルトの名無しさん mailto:sage [2022/02/26(土) 19:00:50.19 ID:yRlIqUsp.net]: >>967
なるほど。BFF的なやつ。
たしかにGoで書くまでもないし、ノンコーディングもあるよね。
985 名前：デフォルトの名無しさん mailto:sage [2022/02/26(土) 19:13:38.66 ID:nWK21oqu.net]: 正直なんだかんだ言って、学習コストに対しての性能パフォーマンスが異様に高いというところがGoの魅力
言語仕様がコンパクトだからミスしにくい(気がする)のも良い
チャネルに容量があることを忘れるうっかりさん以外には

得意な機能は限られててGUIとかは苦手だけど、そんなもんC#やらに任せとけばいいや
986 名前：デフォルトの名無しさん mailto:sage [2022/02/26(土) 19:41:27.25 ID:cxVkNmoR.net]: Goの魅力はケン・トンプソンなんよ

https://en.wikipedia.org/wiki/Ken_Thompson#2000s
> When the three of us [Thompson, Rob Pike, and Robert Griesemer] got started, it was pure research.
> The three of us got together and decided that we hated C++. [laughter] ... [Returning to Go,]
> we started off with the idea that all three of us had to be talked into every feature in the language,
> so there was no extraneous garbage put into the language for any reason.

彼が"we hated C++"つって作っただからそらもうみんな嬉しいやろ
987 名前：デフォルトの名無しさん mailto:sage [2022/02/26(土) 19:44:13.98 ID:fRC8OZTs.net]: 結局>>957よりいいパフォーマンス計測ってないのかー
個人的感想としては。。。
パフォーマンスについて特筆すべき利点はない
原理的にスレッドプールを使った他言語のコードと同程度の性能が出る
機能的な利点はグリーンスレッドを言語で持っており、自動でOSスレッドと使い分けられる点(記述量低＆必要メモリ低)
逆に欠点はスケジュールをコントロールする方法がGOMAXPROCS以外ない点ってところかな
988 名前：デフォルトの名無しさん mailto:sage [2022/02/26(土) 20:07:50.21 ID:nWK21oqu.net]: >>971
優先度がないのはちょっぴり残念ではある
…ないよね？
989 名前：デフォルトの名無しさん mailto:sage [2022/02/26(土) 20:31:14.25 ID:kpnhrKVl.net]: >>969
> 学習コストに対しての性能パフォーマンスが異様に高い
Cの方が高いけどな。Goよりも小さい仕様で速い。
あとC#もGUIはゴミだぞ。それ以外がいいからunityを制覇してるが。
990 名前：デフォルトの名無しさん mailto:sage [2022/02/26(土) 21:20:48.95 ID:4mZJSMD8.net]: >>943
>> それはN:M軽量スレッドだからなし得ることなので、他の言語ができてない以上何とも比べづらい。

RustもM:Nモデルだよ
Goと同じく複数の非同期タスクを複数のOSスレッドに割り当て
しかもGoとは異なりスタックレスなのでGoよりも軽量タスクを実現しているよ

>>951
>> スティーリングまでやるのは他の言語の言語標準機能にはErlangぐらいにしかない。

RustもGoと同じM:Nモデルでワークスティーリングもしているよ
Rustでは以下のランタイムを選ぶことができるよ
・1:1モデル (＝M:Mモデル、OSスレッドそのまま利用)
・M:1モデル (シングルOSスレッドで並行マルチタスク)
・M:Nモデル[スレッドプール方式]
・M:Nモデル[ワークスティーリング方式]
991 名前：デフォルトの名無しさん mailto:sage [2022/02/26(土) 21:35:40.76 ID:yRlIqUsp.net]: >>974
それは処理系標準？それとも準標準？
992 名前：デフォルトの名無しさん mailto:sage [2022/02/26(土) 21:58:06.53 ID:kpnhrKVl.net]: >>974
それ以下と定義が同じだと、一般的には「ワークスティーリング方式」を「スレッドプール」と呼称するよ。（だからC#のもこれのはずだけど）
https://tech-blog.optim.co.jp/entry/2019/11/08/163000
Rustで何故あえて方言にしているのかは知らん。
というかワークスティーリングじゃない方のメリットなんてない気がするんだが。
993 名前：デフォルトの名無しさん mailto:sage [2022/02/26(土) 21:58:10.74 ID:nPeFYJEF.net]: >RustもGoと同じM:Nモデルでワークスティーリングもしているよ

VMじゃないのにどうやって実現してるのかな
994 名前：デフォルトの名無しさん mailto:sage [2022/02/26(土) 21:59:12.46 ID:4mZJSMD8.net]: >>975
RustはGoと真逆で標準ライブラリとは最小限のものに限る位置付けなので
標準ライブラリには非同期ランタイムを作るための枠組みだけが存在していてランタイム自体は無しだよ
これは全ての分野について同じ方針でRustでは標準＋準標準(デファクトスタンダード)を使ってプログラミングをするよ
995 名前：デフォルトの名無しさん mailto:sage [2022/02/26(土) 22:13:34.76 ID:4mZJSMD8.net]: >>976
そこは一般的は話としてまずOSスレッド毎にキューと持つかグローバルにキューを持って割り振るかの2大方式があるよ
それぞれに利点と欠点があってそこは省略するけど
GoもRustもそのハイブリッド方式となっていて普段はスレッド毎にキューを持って各OSスレッドが独立に効率よく処理だね
そしてGoもRustもグローバルにも管理して暇なOSスレッドが生じるとそこへ割り振る(OSスレッドから見るとスティール)するよ
詳細はここで書ききれないほどもう少し複雑だから省略してる点はそれぞれの解説サイトなどを見てね
996 名前：デフォルトの名無しさん mailto:sage [2022/02/26(土) 22:54:22.46 ID:kpnhrKVl.net]: >>979
Goと同じなら805のリンクの内容と同じだからああそうですか程度。
資料が古いがC#のは以下で確認した。同様にハイブリッドでスティーリングもあり。
（ただ.NET6.0とかだともう変わってそうだが）
https://ufcpp.net/study/csharp/misc_task.html
基本グローバルキューで、ただし優先順位はローカルキュー＞スティーリング＞グローバルキューになってる。
この構造はまあ納得。

> GoもRustもそのハイブリッド方式となっていて普段はスレッド毎にキューを持って各OSスレッドが独立に効率よく処理だね
> そしてGoもRustもグローバルにも管理して暇なOSスレッドが生じるとそこへ割り振る(OSスレッドから見るとスティール)するよ
無駄に複雑で余計に遅くなると思うけどね。.NETの方が単純ですっきりしてていい。
グローバルキューから取り出す時の競合を気にしてるのなら、
Goみたいに100,000goroutineとか目指す場合は分かるけど、Rustは基本そうじゃないだろうから、チューニングミスだと思うけど。
997 名前：デフォルトの名無しさん mailto:sage [2022/02/26(土) 23:02:07.46 ID:Gc6jVciw.net]: Goは別に最速を目指している言語じゃないからね
もし何かのベンチマークが最速になってしまったら逆に驚くよ
そのベンチ間違ってるだろ、って。
998 名前：デフォルトの名無しさん mailto:sage [2022/02/26(土) 23:40:35.78 ID:BX4iLvdt.net]: >>977
VMじゃないと起きる問題点は何？
いずれにせよC/C++/RustはVMでもOSでも記述できるのだからそこに不可能は無い

>>980
言語に関係なくシステムスレッド間のグローバルな操作はデータ競合回避など一定のコストがかかる
だから可能な限り個別にシステムスレッドが動くようにしつつアイドルが出ないよう最小限のグローバル操作
この部分はよほど上位で制約のある仕様としていないならば全ての言語で同じ
999 名前：デフォルトの名無しさん mailto:sage [2022/02/26(土) 23:48:39.58 ID:yRlIqUsp.net]: >>978
これがなぁ…。過渡期は混ぜるな危険で困らない？そこが不安。
Rustも良いとは思うんだけど、爪切るのにハサミ使ってる気分になる。
1000 名前：デフォルトの名無しさん mailto:sage [2022/02/26(土) 23:59:29.99 ID:kpnhrKVl.net]: >>982
それはハードによる。
x86はハードウェアでキャッシュコヒーレンシを取ってくれるので実は共有RAMでもコストは安い。
.NETがローカルキューからの取り出しでFIFOとFILOで競合が減るから、というのはそういう事。
Goの場合はARMを見てるのか、MacがARMに乗り換える布石だったのか、
以前からやたら「共有RAMは遅いから使わない」としてきてるが、
ぶっちゃけx86の場合は
（書き込み頻度と量によるが、タスクの起動＝関数ポインタ１つと引数のポインタ程度なら）
OSを利用したチャネル接続よりも共有RAMの方が実は速い。
ここら辺を理解してない奴がグダグダやってるからチューニングし切れてないのだと思うよ。
1001 名前：デフォルトの名無しさん mailto:sage [2022/02/26(土) 23:59:34.35 ID:4mZJSMD8.net]: >>980
>> Goみたいに100,000goroutineとか目指す場合は分かるけど、Rustは基本そうじゃないだろうから、

Rustの非同期タスクはGoroutineよりも更に軽くて
Goとは異なりスタックレスなので付加メモリ消費も非同期ランタイムの管理データ分の1タスクあたり64bytesで済みますよ
そしてグローバルキュー競合コストの件は>>982のように同じですね
1002 名前：デフォルトの名無しさん mailto:sage [2022/02/27(日) 00:02:30.74 ID:2GGoVw4G.net]: >>982
問題があると言っているわけじゃなくて、VMやOSじゃなければプリエンプションできないからどうやっているのかなと。
1003 名前：デフォルトの名無しさん mailto:sage [2022/02/27(日) 00:03:38.38 ID:uWHjNeVw.net]: >>973
Cはお爺ちゃんだから…
Cからの乗り換えコストっていう視点でどうかひとつ

あ、でも実装系別の頭おかしくなるコンパイルオプションやらバウンダリやらのメモリモデル考えると、Goのほうが実質勝ってないか学習コスト？
1004 名前：デフォルトの名無しさん mailto:sage [2022/02/27(日) 00:11:21.81 ID:uWHjNeVw.net]: >>973
ちなみに速さやらサイズでは当然にCとかの圧勝だろ普通に
関数呼び出しごとにオーバーヘッドのかかるGoが単純な速度で勝てる道理はない
1005 名前：デフォルトの名無しさん mailto:sage [2022/02/27(日) 00:23:35.14 ID:uWHjNeVw.net]: >>973
C#というか.Netのwpfは好き
一般的な手法じゃないだろうけど、MVVMのVM部分を単体テストできて(ディスパッチャ細工してメインスレッドで走らせる) []; [ここ壊れてます]
1007 名前：デフォルトの名無しさん mailto:sage [2022/02/27(日) 00:44:59.79 ID:PVy06kKY.net]: >>985
> Goとは異なりスタックレスなので
やたらこれを強調しているが、goでもgoroutineにローカルキュー（＝関数ポインタの配列）を用意して、順に食わせれば、
各タスク毎にスタックを用意する必要なんて無くて、普通にエミュレーション出来るよ。
(ただしGo信者的にはこれは負けだからやらないとも思うが）

ただこの場合、各タスクが止まらない前提ならこれでいいが、
止めて切り替える分には一般的にはスタック領域が必要になる。
(自動変数を全部ヒープ上に確保すればスタック無しでもいいが、これは遅くなるので多分やってないと思う)
ユーザーが確保しなくていいだけで、実際はランタイムかコンパイラが確保してくれてるだけじゃないか？
1008 名前：デフォルトの名無しさん mailto:sage [2022/02/27(日) 00:50:50.94 ID:PVy06kKY.net]: >>988
> 関数呼び出しごとにオーバーヘッドのかかるGo
かからないような気がするが、自信はない。かかる理由って何？
1009 名前：デフォルトの名無しさん mailto:sage [2022/02/27(日) 02:41:36.05 ID:uWHjNeVw.net]: >>991
Goは関数呼び出しごとにスタックをチェックして、不足してたなら拡大するから
関数ごとの静的な自動変数サイズと比較してるだけだと思うけど、そういう処理のおかげで初期スタックサイズを抑えてる
https://postd.cc/performance-without-the-event-loop/
1010 名前：デフォルトの名無しさん mailto:sage [2022/02/27(日) 02:47:33.19 ID:uWHjNeVw.net]: >>991
「十分な空間がない場合、ランタイムはヒープに対して大きなスタックセグメントを割り当て、現在のスタックの内容を新しいセグメントにコピーし、古いセグメントを解放し、それから関数呼び出しを再開します。」
1011 名前：デフォルトの名無しさん mailto:sage [2022/02/27(日) 03:00:02.25 ID:uWHjNeVw.net]: >>991
毎回拡張する訳じゃないけどそのためのチェックは毎回走るんで、単にサブルーチンを呼ぶだけの他言語よりは余分な仕事をしている
おそらくチェックは必要な回数だけだとは思う(ループ内での呼び出しとかの最適化は考えてないとは思わないから)
1012 名前：デフォルトの名無しさん mailto:sage [2022/02/27(日) 06:52:35.32 ID:+yReYAPt.net]: compiler explorer(https://godbolt.org/)で、goコンパイル結果を普通のamd64用のアセンブラ見ること出来ないの？(Plan9でなく)
1013 名前：デフォルトの名無しさん mailto:sage [2022/02/27(日) 07:42:28.85 ID:uWHjNeVw.net]: 次スレ建ててくる
1014 名前：デフォルトの名無しさん mailto:sage [2022/02/27(日) 07:44:00.44 ID:uWHjNeVw.net]: Go language part 5
https://mevius.5ch.net/test/read.cgi/tech/1645915400/
1015 名前：デフォルトの名無しさん mailto:sage [2022/02/27(日) 07:56:25.05 ID:nXG/aSfD.net]: >>990
Rustの非同期タスクは内部的には単純な状態マシンとなり何度も再入可能なコルーチンと同じ状況になります
その中の変数はRustのクロージャがその環境の変数をキャプチャするのと同じだからもちろんメモリを確保します
だからスタックレスで何度も呼べるクロージャみたいな状況でスタック自体はプロセス全体で1本のままとなります
もちろんその非同期タスクから他の非同期でない普通の関数を呼べば通常と同じくスタックが伸びて使われていきます
一方でその非同期タスクから他の非同期な関数を呼ぶとその非同期タスクから一旦離脱してスケジューラーへ戻ります
最初に書いたように「単純な状態マシンとなり何度も再入可能なコルーチン」となっているので再び再開できます
以上がスタックレスなのにRustの非同期タスクがメモリの許す限り多く動くことができる仕組みです
1016 名前：デフォルトの名無しさん mailto:sage [2022/02/27(日) 08:07:16.26 ID:c9v4owXb.net]: ワッチョイ無しかー(´・ω・｀)
1017 名前：デフォルトの名無しさん mailto:sage [2022/02/27(日) 08:16:41.16 ID:+yReYAPt.net]: goroutineとC++標準ライブラリのスレッドを比較するために>>957のmain.rsのC++版だけ作ってみた(ループは一桁減らした)
$ cat main.cc
#include <thread>
#include <chrono>
#include <vector>
using namespace std;
using namespace std::chrono;
int main() {
vector<unique_ptr<thread>> threads;
for (uint32_t i = 0; i < 1000; ++i) {
threads.emplace_back(
make_unique<thread>([=]{
uint64_t bad_hash = (i * 2654435761) % 200000;
this_thread::sleep_for(microseconds(bad_hash));
for (uint32_t _ = 0; _ < 1000; ++_) {
this_thread::sleep_for(10ms);
}
})
);
}
for (auto const& t: threads) {
t->join();
}
return 0;
}
$ g++ -O3 -pthread main.cc -o main && ./t ./main
real 11.04s
user 0.93s
sys 2.95s
rss 11328k
$
結果はmain.rsとほぼ同じで、やはりスレッド起動コストがデカく、rssもデカい
1018 名前：1001 [Over 1000 Thread.net]: このスレッドは１０００を超えました。
新しいスレッドを立ててください。
life time: 468日 4時間 2分 1秒
1019 名前：過去ログ ★ [[過去ログ]]: ■ このスレッドは過去ログ倉庫に格納されています

[ 新着レスの取得/表示 (agate) ] / [ 携帯版 ]

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