[過去ﾛｸﾞ] Go language part 3 (918ﾚｽ)
上下前次1-新
抽出解除 必死ﾁｪｯｶｰ(本家) (べ) 自ID ﾚｽ栞 あぼーん
このｽﾚｯﾄﾞは過去ﾛｸﾞ倉庫に格納されています｡
次ｽﾚ検索 歴削→次ｽﾚ 栞削→次ｽﾚ 過去ﾛｸﾞﾒﾆｭｰ
882(2): デフォルトの名無しさん [sage] 2020/11/04(水) 00:48:58 ID:thexrnOY(1/4) AAS
>>880880(1): デフォルトの名無しさん [] 2020/11/04(水) 00:08:44 ID:BNFfXKWA(1/4) AAS
>>862
cspは概念・モデリングっつう理解でだいたいいいと思うよ。
昔から並行処理システム関わった奴ならたいていは似たようなモデルは考えてる。
cspはそれを厳密に数学的に記述するって感じ。
極端なこと言えばメッセージでやり取りしましょう、だ。
っで、goはプログラミング言語としてgoroutineとchannelがあるから他の言語より並行処理向き。
go以外なら古くはadaやなんかもそう。タスクにランデブポートっつうのがある。
erlangも似たようなメッセージ機構はあるんじゃなかろうか。
本質的に並行処理ってのは非同期的な処理システムなわけだけど、
非同期ioとコールバック(やシンタックスシュガー)でやるより、独自に動く実行体が複数あってそれらがメッセージ通して協調動作するってシステムの方が好きだ。
それアクターモデルだろよ、と思ってwiki確認したら、CSPがモロに書いてあったわ。
ただ、アクターは浮かんでは消え、という印象があるが。
smalltalk信者等、通信したい奴は確かにいるようだが、それがイマイチ何になるのか明確でない。
あと、コード上で通信したいのならGoだが、アクターモデル自体は普通にオブジェクト指向で組めるし、
C++なら（あまりよろしくはないが） >> と << をオーバーロードしてそれっぽく見せることは可能だ。
実際その方がgoroutineより何倍も速く動く。
Erlangは俺も以下を半分くらい読んだ程度しか知らないが、
外部ﾘﾝｸ[html]:www.ymotongpoo.com
あれは実用本位で、理論側から出てきたものでは全然無い。
電話交換機筐体を複数並べてスケールアウトした時にも性能が低下しないように作られてる。
だから最初から共有RAMなんて禁止されてる。そして当然メッセージ交換だが、
最初から上記のような疎結合でのメッセージ交換を想定されてるから、
Goみたいな密結合を想定されているものとはちょっと違うが。
883: デフォルトの名無しさん [sage] 2020/11/04(水) 00:55:48 ID:thexrnOY(2/4) AAS
>>881881(2): デフォルトの名無しさん [] 2020/11/04(水) 00:15:06 ID:BNFfXKWA(2/4) AAS
>>876
まぁーやっぱ、gcってよくねーわ。
捨てる前提のプロトタイプにはgcあり言語もよいと思う、ほんで大部分の案件はそれで十分ってのもあっる。
げももっと性能を、、、てやると今なら c/c++/rust の3つしかナイショ。
ちなみに本家の方はコメントも付いてて、GoUserが吠えてる（事になってる。
ただあの程度で噛みつきと捕らえられるのも厳しい気はするが)
Rust試す前にGoのバージョン上げろよ、というのもそうだが、
キャッシュサーバー使えよ、というのは確かにな、とは思った。
887(4): デフォルトの名無しさん [sage] 2020/11/04(水) 08:59:07 ID:thexrnOY(3/4) AAS
>>886886(1): デフォルトの名無しさん [sage] 2020/11/04(水) 07:42:42 ID:a9nrTc1S(1) AAS
>>881
実際問題、ここ数年のGC言語で足を引っ張られた事はあんまりないけど。
そういう意味では参照カウンタ方式のPythonなんかは割と効率良いんじゃない？それこそスクリプト言語だけど。
言語としてのスループットを上げたければ、allocはまとめて、freeはもっともっとまとめてやって、必要そうだったらメモリのcompactionかけるほうがスループット上がると思うが。
>>882
Goのどこが密結合？
チャンネルは？
参照カウンタのGCとマーク&スイープのGCは意味合いが全然違う。
それを一緒くたにしてるようでは駄目だよ。
そこら辺がGoスゲーって言ってる奴のレベルが低いところだよ。
それ以外も君は間違いすぎていちいち指摘するのは諦めたけど、
多分もうちょっと勉強した方がいい。
Goは酷い言語でもないけど、凄い言語でもない。
860の本家にRustと冷静に比較しているコメントがあるから読んでくるといい。
900(3): デフォルトの名無しさん [sage] 2020/11/04(水) 22:39:50 ID:thexrnOY(4/4) AAS
>>889889(1): デフォルトの名無しさん [] 2020/11/04(水) 10:57:28 ID:BNFfXKWA(4/4) AAS
>>887
広義では参照カウンタもgcじゃん。
gcも色々改良されてるし未だに古典的なマークスイープgcのみってのはあまり無いんじゃろか。
だから案件の多いweb系とかアプリとかの上のレイヤーでgcが問題になるケースはあまり無い。
gcはそれより下のエンジンとかのシステムレイヤーで問題視されることが多い。
で、一応goはc/c++/rust同様のシステム言語のくくりで語られることもあるからその辺から叩かれたりするけど、そうじゃなくて上のレイヤーの言語として使えばいい感じの言語だと思う。
> 広義では参照カウンタもgcじゃん。
そう。俺も「参照カウンタのGC」とも言っている。
馬鹿は放置として、君も疑問のようだから回答しておくと、
参照カウンタ方式は「ユーザーが間違ってない」前提が必要で、「ユーザー補助」でしかない。
対してマーク＆スイープは「ユーザーが間違ってても」GCが為されるから、「システム保護」なんだよ。
だから役割が全然違う。少なくとも真面目に24時間365日動作させるつもりなら、単純に交換は出来ない。
これが結局何だかんだでマーク＆スイープから離れられない理由で、
JavaもC#もJSも、勿論Goもマーク＆スイープしてる。
勿論それが重いのはみんな分かってるから、色々工夫してるけど、最終的にはやるしかないから。
だから参照カウンタ方式のGCでマーク＆スイープと同様に「システム保護」を得る為には、
「ユーザーがどんな書き方をしても」解放されることが必要で、
例えば>>896のようなのが有ればいいけど、これで実装してる例ってあったっけ？
（なお循環参照の検出自体は簡単だが、適切に起動する為のイベントがないから、実装時に困るのはそこだと思うが）
> そうじゃなくて上のレイヤーの言語として使えばいい感じの言語だと思う。
そこは今どっかりとC#が根を下ろそうとしている。
C#は俺は良い言語だと思うけど、Javaに食われて死にそうなのがなあ、という見方だったが、
少なくとも俺の予想以上には大健闘していて、生き残るかもしれないなあ、とは思いつつある。
これまではC#もC++もWeb系が手薄だったけど、どっちもガチで整備し始めてるから、それが完了した時にどうなるかだね。
そしたら本当にGoを使う意味が全くなくなる。
逆にRustはCPU負荷無しで「システム保護」出来るわけだから、GC言語を皆殺しにかかってる。
そしてC並に速いのだから、確かに最終兵器ではあるんだよ。盛り上がる理由はそれ。
上下前次1-新書関写板覧索設栞歴
ｽﾚ情報 赤ﾚｽ抽出 画像ﾚｽ抽出 歴の未読ｽﾚ AAｻﾑﾈｲﾙ
ぬこの手 ぬこTOP 0.035s