779(1): デフォルトの名無しさん [sage] 2020/10/31(土) 23:29:32 ID:NOhP3tKc(2/2) AAS
>>778
うん知ってる。
ついでに言うとstructが値渡しで、Cで言う . による高速化もつまみ食い出来るようになっている。
ただしこちらも主な使い方ではなく、実際に効果が出る小オブジェクト(確か16バイト以下）で限定使用することが推奨されてる。
その辺はC#は実用言語だから地味に整備してある。
unsafeもその一環でしかない。

だが結局のところ、その辺の小異に目をつぶればC/C++/C#/Java/Python/JavaScript等の現在の主力言語はどれもほぼ同じで、
C/C++だと直接ポインタを扱える、位の違いしかない。
それはつまらないとして、敢えて独自路線を行ったのがGoだが、ポインタ周りは大して独自でもなかった気がした。
Goじゃないと出来ない/他言語でやると凄く苦労する、てのはないよね？
（というかポインタ自体Cの時点で完成してて、その後は精々間違いを自動検出する方向にしか進化出来てない）

多分Goの売りはgoroutineとgenerateなのだと思う。
ただ俺にはgoroutineがそんなに便利とは思えなかったし、そもそもあれコルーチンではなく単なるスレッドだから名前間違えてるだろ、だ。
generateについてはCマクロをゴリゴリしたい奴には非常に有用なのだろうけど、そもそもそんな奴は多数派ではないし、俺もそうじゃない。
ただしAST木が標準で出せるというのはかなりインパクトはある。
とはいえ、AST木では低レベル過ぎて困るので、本当はもっと上のレベルが欲しいのが大半なんじゃないかと思う。

ちなみに最近の言語でも評価が固まってないのは例外周りで、これは各言語によってまるっきり違う。
Goはドベタにerrを値で返す、仕様としてはCモドキだが、現実的には一つの選択肢だとは思う。
格好良くはないが。

781(2): デフォルトの名無しさん [sage] 2020/11/01(日) 08:14:15 ID:0aiHjqpe(1/12) AAS
>>780
> goのスタックフレームつまり自動変数も他の言語とは隔絶
どこが？サイズだけならCは調整出来たと思ったけど

> そのため、数百万のgoroutineを作成できる
それは既に結論は出てる。
以下ブログ、俺が読んだ時とはだいぶ趣が異なるが、（当時は確か初期サイズ4KBだったはず）
外部ﾘﾝｸ:github.com
要は2KBでも十分大きすぎて、Nodeの方が断然まし、ってことになってる。

これは当たり前で、Linuxのkernel領域でのスタックサイズが128Bだったか256Bかに制限されているらしいから、
その気になればLinuxは256B/threadでスレッドを起動出来る。
そしてNodeはシングルスレッドだからスタック領域が余すところなく全部消費される。
これはGoではどうやっても出来ないことだ。
というよりJSのシングルスレッドアーキテクチャは最初からこのc10k問題解決を主眼にしてる。
だからその領域ではそれ用に作られたJSに勝てるはずもなく、実際そうだった、というだけ。

goroutineのサイズをケチってどうこう、って作戦は究極にはJSのシングルスレッドアーキテクチャに行き着く。
だからその方向ではNodeには勝てないのは仕様だよ。
そうじゃなくて、言語サポートがあるからスレッドがお気楽に使え、それがgoroutineです！って方が順当で、
実際そのブログの作者も喜んで使ってみたが、思ってたと違う、、、というのがそのブログだよ。

> そのため、数百万のgoroutineを作成できる
数百万のthreadなんて実際あり得ないし、管理も出来ない。
そこをgoroutineならお気楽に生成/消滅出来るので、これまで「面倒/管理が難しい」等でthread起動しなかったところを、
「これは別スレッドでも動く」というだけの理由でお気楽にすべてgoroutineで切り離して行けば一見超並列出来そうに見える。
ただ、実際それをやったらそこで遭遇している問題、つまりgoroutineは思っているほど軽くない、に遭遇してしまう。
現実的にはthreadなんて論理CPU数の2倍程度あればCPU処理だけなら埋まってしまうからそれ以上起動しても意味がない。
I/Oで引っかかった時のスタックサイズをケチりたいのなら、
JSのように非同期でシングルスレッドにする方が原理的に上だし、実際そうだった、というのがそのブログだ。