[過去ﾛｸﾞ] Go language part 5 (1002ﾚｽ)
上下前次1-新
抽出解除 必死ﾁｪｯｶｰ(本家) (べ) 自ID ﾚｽ栞 あぼーん
このｽﾚｯﾄﾞは過去ﾛｸﾞ倉庫に格納されています｡
次ｽﾚ検索 歴削→次ｽﾚ 栞削→次ｽﾚ 過去ﾛｸﾞﾒﾆｭｰ
ﾘﾛｰﾄﾞ規制です｡10分ほどで解除するので､他のﾌﾞﾗｳｻﾞへ避難してください｡
598(2): デフォルトの名無しさん [sage] 2022/09/06(火) 16:56:04.53 ID:rOGll//o(1/2) AAS
>>593
その通りだな、安易に実装できるものを標準で欲しがる理論がわからんわ
多くの言語のfutureなんてデータの結果受信同期待ちが起こるだけだし、goのcontext.WithTimeoutは
他の言語では全く実装できていないfutureのプラス機能のようなもので、goはより進んでいると言える
一方promise的なもの、つまり複数のgoroutineを束ねて制御したい人は、欲しい人もいるかもしれないが
goで書いたpipeline処理は手動で書くからこそきめ細かい制御が出来るので、無作為にこれとこれを並列、
これとこれを非同期だけど同期的に実行にしたいとか、効率を考えたらこの流れを組み替えられることには
ほとんど意味もないね。
例えばJSでPromise.allとかすべてを非同期並列に実行して成功の可否で分岐したいなんて、同じ状態が
goroutineとチャネル待ち受けで出来てしまうわけで、それを仰々しいライブラリにする意味が分からん
599(1): デフォルトの名無しさん [] 2022/09/06(火) 17:02:41.68 ID:rOGll//o(2/2) AAS
上では良いことだけ書いたけどif err != nullはもうそろそろダルいので何とか手を打ってほしいわ
副作用のある関数ではgoの第二の戻り値がerrなのは、もはや言語仕様なので別言語でいう
Option/Result/Eitherみたいなものは必要ないにしても、?.のようなNull条件演算、合体演算
のようなErr条件演算が欲しい
上下前次1-新書関写板覧索設栞歴
ｽﾚ情報 赤ﾚｽ抽出 画像ﾚｽ抽出 歴の未読ｽﾚ AAｻﾑﾈｲﾙ
ぬこの手 ぬこTOP 0.038s