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/
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ミスってるぞ
742 名前：デフォルトの名無しさん mailto:sage [2021/11/28(日) 13:18:18.69 ID:Abxhe3pm.net]: >>727
そうだね。少なくともC#もJSもそう。ランタイムがある前提。

要は、asyncジョブが終わった時にメインスレッドをたたき起こす仕組みが必要なだけ。
GUIの場合はメインスレッドはイベントループを回ってるから、そこにイベントとして与えるのが一番簡単だし、そうしてるはず。
コンソールアプリだとイベントループはないので、ランタイム側にメインスレッドをたたき起こす仕組みを付加しないといけない。
けど、goでもこれはやれば出来るだけの話だよね。
743 名前：デフォルトの名無しさん mailto:sage [2021/11/28(日) 13:26:20.41 ID:3qnAFeGl.net]: >>716
違うよ。
全然別の部分からresolveされるPromiseをawaitするっていう、コールバック関数をasync/awaitに変換する事ができたりする。
可換なんよ。
744 名前：デフォルトの名無しさん mailto:sage [2021/11/28(日) 13:28:24.24 ID:Z9Xk/5kf.net]: async/awaitが使われていると、コードのいろんな箇所がどんどんノンブロッキングになっていく傾向がある気がしていて、
多くの人にとってかなり使い心地が良いんだろうな、と思ってる

俺はチャネルとgoroutine好きだけど、よく考えるとみんなうまく使えてないんだよなあ・・・
745 名前：デフォルトの名無しさん mailto:sage [2021/11/28(日) 13:32:08.20 ID:p4O5g5oI.net]: > 俺はチャネルとgoroutine好きだけど、よく考えるとみんなうまく使えてないんだよなあ・・・

太田道灌
746 名前：デフォルトの名無しさん mailto:sage [2021/11/28(日) 13:35:20.14 ID:Abxhe3pm.net]: >>730
出来るのは分かるが、使い道がないんだよ。

俺もPromiseは要は予約を積んでるだけなので無限に動的に積んで色々出来るか？と思った事はあった。
async/awaitはその点ハードコードだからそのルーチンしか処理しないし、狭い範囲で確定的だ。
ただな、Promiseに動的にいろんな場所からPromiseを積み重ねないといけないような状況はないんだ。
単にasync/awaitでまっすぐ書くだけで十分なんだよ。
747 名前：デフォルトの名無しさん mailto:sage [2021/11/28(日) 13:37:04.91 ID:xYHgZ8WY.net]: ダメだ完全に発狂しとる
748 名前：デフォルトの名無しさん mailto:sage [2021/11/28(日) 13:39:44.17 ID:Abxhe3pm.net]: >>731
> 俺はチャネルとgoroutine好きだけど、よく考えるとみんなうまく使えてないんだよなあ・・・
ならお前が上手く使ってる例を布教すればいいだけ。
それが凄く有用で、現行のasync/awaitやPromiseでは実現出来ないものであれば、
Goスゲーって事になるだけ。

JSも2005にXHRが再発見されるまではオモチャ扱いだったし、ワンチャンはあるぞ。
749 名前：デフォルトの名無しさん mailto:sage [2021/11/28(日) 14:03:02.10 ID:cigmxKA5.net]: >>733
めちゃくちゃ使うよ。

既にメモ化されたデータがあればそれを使う、そこに無ければ動的にイベントハンドラー仕掛けておいて、一定時間内にそのイベントが発火したならそのイベントの引数を返すが、発火しなければrejectする、みたいな。

async/awaitしか使わない、CPUをきちんと解放しろ、と言う話なら、Goならランタイムが自動的にやるので気にせず同期型のように書いて良いぞ。
750 名前：デフォルトの名無しさん mailto:sage [2021/11/28(日) 14:08:56.82 ID:Abxhe3pm.net]: >>736
よく分からんからコードで頼む。
君のコードでなくてもいいし、誰かのGitHubでもいいので。

要はその、Promiseでは簡単に出来るが、async/awaitでは無理（または複雑になる)、っていうコードを。
751 名前：デフォルトの名無しさん mailto:sage [2021/11/28(日) 14:10:43.62 ID:Z9Xk/5kf.net]: >>735
おれの知識はほぼほぼ「Go言語による並行処理」だから、これを読め、で終わってしまう・・・
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の雌雄を決したい
853 名前：デフォルトの名無しさん [2022/02/22(火) 20:10:03.17 ID:Y6BYhUSt.net]: >>837
nodejsはフレームワークとは言えんような。
justはnodeインストールしてなくても動くのかい？
854 名前：デフォルトの名無しさん mailto:sage [2022/02/22(火) 20:45:10.67 ID:WirMN8li.net]: >>838
まずはぜひGoらしいコードを叩き台として出して
855 名前：デフォルトの名無しさん mailto:sage [2022/02/22(火) 20:59:43.80 ID:G6nBeheJ.net]: 自分で手を動かせ
誰かに何かを「やってもらう」ところじゃねーんだよ
自分でできないやつは書き込むな
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