> そして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から見れば卒倒しそうな仕様も、解の一つではあると見てる。