Go language part 5

1 ：デフォルトの名無しさん：2022/02/27(日) 07:43:20.04 ID:uWHjNeVw.net

Goについて扱うスレッドです。
GoはGoogleによって開発された言語です。

公式
https://golang.org

公式ドキュメント
https://golang.org/doc/

公式外パッケージドキュメント
https://godoc.org

ブラウザ上で試し書き
https://play.golang.org


※前スレ
Go language part 4
https://mevius.5ch.net/test/read.cgi/tech/1605467680/

757 ：デフォルトの名無しさん：2024/02/14(水) 13:09:52.21 ID:gybktDWa.net

mux使ってないけど、なんかあったん？

758 ：749：2024/02/14(水) 20:05:40.85 ID:73JEoiws.net

米国年収でも、Rubyは、Go/Rust/Elixir の3大言語を超えた！

2022 -> 2023

Ruby : 9.3 -> 9.9 万ドル
Elixir : 9.3 -> 9.6
Go : 8.9 -> 9.3
Rust : 8.7 -> 8.7

多くの言語 : 6.5〜7 -> 7.3〜7.8

PHP : 5 -> 5.9
Dart : 4.4 -> 5.6

759 ：デフォルトの名無しさん：2024/04/03(水) 16:01:02.02 ID:eNgZCM35.net

>>754
GoogleはGoにしたいのか、Rustにしたいのか

760 ：デフォルトの名無しさん：2024/04/03(水) 16:23:26.97 ID:V8E7QtS4.net

したいって現状用途が全然違うのに

761 ：デフォルトの名無しさん：2024/04/03(水) 16:40:24.82 ID:eNgZCM35.net

>>760
確かに現状用途が異なる。GoがWeb、Rustがシステム記述
しかし、本来はGoもRustと同じところを狙っていたのではないかと

762 ：デフォルトの名無しさん：2024/04/03(水) 16:51:21.63 ID:V8E7QtS4.net

goとrustじゃあ全然言語機能違いすぎるよ
goは言語自体くそシンプルでだからバックエンドのマイクロサービスみたいな
小さなサービス自体を実装するのに使われてる(用途)
goでそれ以上のことをやると死にかけると思う

GoとRustはC#とJavaみたいなにたもんじゃないと思う

763 ：デフォルトの名無しさん：2024/04/03(水) 17:00:55.33 ID:V8E7QtS4.net

逆にRustでバックエンドのWebサービス実装する
フレームワークあるけどコンパイル時間長すぎて
Webとか時間の流れ速い分野ではこれはこれで地獄だし

GoとRustは色々比較して別物だからな
用途も現状すみわけられてると思う

764 ：デフォルトの名無しさん：2024/04/03(水) 17:16:01.43 ID:V8E7QtS4.net

本来についてはどうなんだろうね
Goはシステム記述を最初から狙ってたの?
システム記述がどこを指すのかにもよるけど

765 ：デフォルトの名無しさん：2024/04/03(水) 17:37:49.09 ID:iMBIpEa8.net

でも実際GoogleはGoで書かれたものもRustに移行してる
生産性は同程度だけど不具合の数が圧倒的に少なくなったらしくかなり前向きっぽい

766 ：デフォルトの名無しさん：2024/04/03(水) 19:14:38.98 ID:IrOohhoZ.net

RustはC/C++の代替言語なわけで結局メモリ管理のための記述が必要な低級言語なんだよ〜
ガベージコレクションの無い低級言語なんか触りたくないぽよぉ〜、Goしか勝たん！

767 ：デフォルトの名無しさん：2024/04/03(水) 19:19:11.96 ID:SPeUFyxp.net

シンプルな言語機能でコードの保守性を高めることがGo言語の目的で、それはRustと真逆のような

768 ：デフォルトの名無しさん：2024/04/03(水) 19:21:07.80 ID:i4V1+m9a.net

Rustが人気な理由は
完全にメモリ自動解放しかも必ず安全
を実現しつつC言語と同等の速さで動く点

769 ：デフォルトの名無しさん：2024/04/04(木) 22:12:02.80 ID:vlvoJs2w.net

つかメモリ管理が～とか中級者まででしょ
普通の頭があれば25歳までに卒業してるわ

770 ：デフォルトの名無しさん：2024/04/04(木) 23:05:06.38 ID:G0cwdLmq.net

javaがウケたのもcがウケたのも
シンプルだったからなんやろねえ
実際のプログラミングってのはどうしたってクソみたいな
状態の山、依存の山みたいなもんに取り組んでいくわけで
余計な複雑さを持ち込まないでほしいってのは現場のリアルな声だと思う

もちろんgoも、それをわかってて、それを押さえてる

771 ：デフォルトの名無しさん：2024/04/04(木) 23:26:31.09 ID:Chhm4gg1.net

>>770
Cが受けたのは他が糞だったから。勿論Cの完成度は超高いにしても。
あとその当時はCPUが非力すぎて軽くないと話にならなかった。
Javaが受けたのはCで鬼門だったポインタを廃止してGCも導入し、馬鹿でもバグが出にくくなったから。
その後スクリプト言語が受けてるのは富豪プログラミングの方が断然楽だから。
ただ効率を考えたらポインタを直接扱える方が断然有利なので、Goは簡単な範囲でポインタを使える言語の位置づけだと思う。

772 ：デフォルトの名無しさん：2024/04/04(木) 23:40:17.98 ID:vlvoJs2w.net

ただしJavaは敷居を下げすぎて業界にバカが多数流入した
ポインタを取り扱える/扱えない がハードルとして機能していた
Go関係ない話ですまん

773 ：デフォルトの名無しさん：2024/04/05(金) 00:59:31.65 ID:wkA5bdgA.net

>>763
初老のおっさんのyoutubeで見たけど
actix-web使ったプロジェクトのビルドに10分位掛かってた。
もうちょっと頭使って環境作ればいいのに

ちなワシの環境なら10秒程度

774 ：デフォルトの名無しさん：2024/04/27(土) 20:42:50.26 ID:PtA3qgXN.net

こんばんは

Goってネームバリューあるけどそんなに盛り上がってる感じじゃないよね
javaの後継になるかと思ってたけどそうでもないし

775 ：デフォルトの名無しさん：2024/04/27(土) 21:13:07.86 ID:K8Ze6DJO.net

言語仕様が簡素な点が特徴だけど
Javaのような大規模開発には向いてないかな
ガベージコレクションがあるからC/C++の分野も不向き
守備範囲が意外に狭い

776 ：デフォルトの名無しさん：2024/04/27(土) 23:58:02.43 ID:9h9dlcQc.net

Goはもう衰退傾向に入った

777 ：デフォルトの名無しさん：2024/04/28(日) 10:43:50.01 ID:ebtFAx8m.net

>>775
Javaが大規模開発に向いてるのは「文化」であって、「言語機能」ではないだろ
Goで技術的に出来ない事はない。ただしやる意味もないが
Goが糞なのは「全部書け」という言語ポリシーだが、これはJavaも同じだし

>>774
Javaの代わりにGo使うメリットってポインタが使える事くらいか？
ならJavaの連中はポインタが使えない(使わなくて済む)からJavaに行ったのだから、
> javaの後継になるか
これ自体が間違いだな

ただまあ、GC付きCの需要は以前からあったし、この分野ではそこそこ生き残り続けるのでは？

778 ：デフォルトの名無しさん：2024/04/28(日) 10:57:35.16 ID:vYBqVrR0.net

javaの代わりにGo使うメリットってネイティブコード吐き出すことだと思うけど
処理速度が早くなればそれだけマシンのリソースが少なくて済む

779 ：デフォルトの名無しさん：2024/04/28(日) 11:46:19.27 ID:ebtFAx8m.net

>>778
ああその点は完全に失念してた。
ただなんつーか、今時鯖代より人件費の方が高いので、Web鯖なんて物理で殴る方が安いというソリューションになってしまってる。
Javaも同様の状況だと思う。
Webに比べて製品寿命は長いので、状況異なるかもしれんが。

処理速度が絶対的に必要なのは物理で殴って逃げられないケースで、
これは例えばディスコードやFPS等のゲーム、つまりユーザー間でのデータのやりとりが大量にある状況で収容数を増やしたい場合で、
現在はRust/C++ということになっている。この分野でJavaを選択する奴は居ない。

Javaが使われてるのは大概インフラ、つまり銀行の送金システムや自治体の戸籍管理等だが、
負荷がかかって物理で殴って逃げられないのはDBであってJava記述部分ではないので、
最大でも精々2倍程度にしか速くならない現状で、Goに書き直す事はない。
それよりも書き直す際のバグを嫌うはず。

つまり、Rustが存在せず、鯖代が今の10倍くらい高ければ、JavaをGoに書き直す需要は発生してたはずだが、そうではなかった、ということ。

780 ：デフォルトの名無しさん：2024/04/28(日) 13:33:28.92 ID:PewOJWl2.net

3行で

781 ：デフォルトの名無しさん：2024/04/28(日) 13:57:24.88 ID:MN1XFv8I.net

> Javaの連中はポインタが使えない(使わなくて済む)からJavaに行ったのだから、

アマチュアさんからはそう見えるんだね
職業マにとって言語なんて案件次第なんよ

782 ：デフォルトの名無しさん：2024/04/28(日) 14:28:40.83 ID:ebtFAx8m.net

>>780
速度面も機能面も、GoはJavaの後継ではない

>>781
ゆとり乙

顧客次第というのなら、現時点でのJava案件は今後ともJava案件だろうよ
顧客は公務員かお堅いところで、「もし何かあったら誰が責任を取る？」しか考えない連中だから
C++しかなかった時代ならともなく、現時点でJavaを「安全」とする技術的意味はないが、
顧客はそれを理解出来ず、また、責任逃れの為に誰も先陣を切らない
ただオラクルが妙な動きを見せ始めてるから、その辺どうなるかだが、それでも公務員連中は金払って終わりだろうよ
所詮は税金であって、自分の金ではないから
そういえば三菱銀行は10-15年前にC++で書きました、Haskell使いました、とかやってたが、続報は聞かないね

783 ：デフォルトの名無しさん：2024/04/28(日) 14:52:46.56 ID:MN1XFv8I.net

素人ならではの発想ほほえましい

784 ：デフォルトの名無しさん：2024/04/28(日) 15:24:23.74 ID:P9GmgsNY.net

しょうもないマウント合戦

785 ：デフォルトの名無しさん：2024/04/28(日) 15:26:16.67 ID:ebtFAx8m.net

>>783
ゆとり引きニート乙


>>774
一応捕捉しておくと、773がGoを「速いJava」と『個人的に』考えたのは間違いではない。
ただし『言語として』なら完全に間違いだ。

Javaはビルジョイが「Cでのバグの大半はポインタがらみで、ポインタ使用ケースの9割がStringだった。
だからStringを言語がサポートすればポインタをなくせると考えたんだ」とリーナスに語ったとおり、
ポインタを無くしてバグを減らす為の言語として作られてる。
そして実際、大受けして天下を取った。(なお「大半」と「9割」は逆だったかも)

ただ、速度チューンにはポインタでの効率化が必須で、この意味でGoは「速いJava」として『個人レベルでは』使える。
ただしJavaにはそもそもポインタがないのだから、
この発想、つまり「ポインタを使えば速くなる」とはJava使いは考えないし、実際、出来ない。
(個人レベルなら出来るのは混ざってるだろうが、Java流の開発方針だとチーム全員が出来ないと意味がなく、機能しない。
そしてポインタにまつわる問題をデタラメに吹聴してる震源はJava使いであって、具体的に言えば「メモリリークガー」だが、
C使いがメモリリークに悩まされる事はない。それはCの使い方を知らない馬鹿がデタラメやってて勝手にバグってるだけ。
この意味で ID:vlvoJs2w は正しい事を言ってる。なお俺は ID:Chhm4gg1)

786 ：デフォルトの名無しさん：2024/04/28(日) 15:55:49.27 ID:SU2rs0/X.net

そのようにC/C++を自分は使いこなせると思い込んでいる多くの人たちによってセキュリティホールが生み出し続けられている
結局C/C++を使用禁止にするしか解決策はない
アメリカでは政府レベルで決断して声明を出したので日本も後を追うだろう

「ソフトウェアはメモリ安全でなければならない」との声明を発表、米ホワイトハウス：「C」「C++」よりも「Rust」などの言語を推奨
https://atmarkit.itmedia.co.jp/ait/articles/2403/18/news045.html

787 ：デフォルトの名無しさん：2024/04/28(日) 18:01:20.89 ID:cGfg508i.net

AIによるコンパイラによってC/C++は復活する、コンパイル時にメモリ安全がAIによって保障されるのだ
さらにAIコンパイラがはくエラー＆提案によって誰もがC/C++マスターとなる
つまりRustの人間にメモリ安全を強制する構文ルールは瞬く間に錆ついてしまうのさｗ

もちろんAIの恩恵はガベージコレクションにも及びGo、Pythonなどの実行速度も劇的に上がる
つまりRustはすぐに錆びついてしまうのさｗ　AIという母なる海によってね

788 ：デフォルトの名無しさん：2024/04/28(日) 18:22:25.79 ID:OBzO61ZB.net

めちゃくちゃ頭の悪い妄想だな

789 ：デフォルトの名無しさん：2024/04/28(日) 18:41:43.21 ID:ebtFAx8m.net

>>786
そう思う人がC/C++を使わなければ済むだけ。

> そのようにC/C++を自分は使いこなせると思い込んでいる多くの人たちによって
なお、これはただのコンプレックスで、
ポインタの概念を理解すら出来ない馬鹿はお引き取り下さいではあるが、
ポインタを理解できたがリークするのは、やり方を知らないだけ。
(そしてここはGoスレであり原則後者だから、前者は死ねでいい)

ただ問題は、Javaの連中が「メモリリークガー」とデタラメに吹聴してるのに騙され、
文法にて縛ってしまうRustに逃げてしまってる事。まあ初心者は文法しか見えないから致し方ないが、
実は定番の手法があり、踏襲すれば絶対にリークしないだけ。
賢いからリークしないわけではなく、知ってるか知らないか、守るか守らないか、でしかない。
そしてRustは実際はC->C++->Rustと来ないと意味もメリットも理解出来ず、
「RustのおかげでCを入門する奴が増え、現在RustよりCの入門者の方が多いじゃねえか！」とか2019頃に言われてた気が。
RustはCを駆逐したいようだが、間抜けな話だ。

そして、Javaが「安全」とされていたのは、
・ポインタにまつわる問題が無い
・配列の境界チェックあり　(←これGoはどうだったっけ？忘れた)
・GCありなのでリークしない
・サンドボックス
だと思ったから、技術的に見れば確かにGoはJava＋ポインタ＝高速版Javaとしての側面はあるのだろうよ。
ただ、マーケティング的に(781)、また技術者リソース的に(784)、当面は無いが。

この意味では俺はRustの方が詰んでると思うよ。AIで出来るとは思って無いが、(>>787)
・動的な境界チェックをやってる限り、Cの速度に勝てない
・静的な境界チェックが出来るようになれば、C++にも導入されるだけ
で、出口が無い。
そして意味もなくマウントを取って来た780が言う様に、現在のJavaプログラマはポインタを扱えるのなら、
Java->Goへの大移動は起きるのかもしれんよ。この意味ではRustよりGoの方がワンチャンある。
(けどまあ、普段やってないことがいきなり出来るわけも無く、ゆとり引きニートの言い分なんてお察し、だが)

790 ：デフォルトの名無しさん：2024/04/28(日) 20:18:11.49 ID:MN1XFv8I.net

童貞が女の口説き方教えてくれてるような長文

791 ：デフォルトの名無しさん：2024/04/28(日) 21:47:54.49 ID:J0uaAvkZ.net

例え方がキモすぎる

792 ：デフォルトの名無しさん：2024/04/28(日) 23:14:08.57 ID:/3v3RYNX.net

そんな心配しなくてもAIが進化すればGOもC/C++もRustもなくなって別の高級言語が生まれるよ、もう会話してればプログラムができちゃうような感じになる

793 ：デフォルトの名無しさん：2024/04/28(日) 23:51:58.46 ID:CS4j+YiY.net

>>789
配列の境界チェックは任意に与えられたインデックス値に対してはC言語であろうとなかろうと境界チェック必須
一方で配列の内部であると確認されているなら不要(にすることができる)

例えば配列の内部であると確認されているならその配列内部へのポインタとして持ってしまえば
読み書きアクセスのたびに境界チェックは不要となる

よく使われる配列の全体もしくは一部分の範囲を順にシーケンシャルアクセスする場合もポインタにすれば境界チェックを不要にできる
なぜならその範囲の終端条件に達するまでは内部であると確認されてるため個別の境界チェックは不要

RustがC/C++と同じ速さで動くのもこの原理のため

794 ：デフォルトの名無しさん：2024/04/29(月) 00:43:52.99 ID:Cj8RVhlf.net

>>793
言ってる事は知ってるが、そうではなく、

> 任意に与えられたインデックス値に対して
の時に実際どうしてるか聞いてる。

C言語の場合は、境界チェックして無い。
Rustの場合はするらしい。だからこの部分でどうしてもCより遅くなる。
Javaは勿論やってる。だから馬鹿が書いて添字範囲をオーバーしたら、例外が返されたはず。
Goはどうだったっけ？という事。

で、Javaが792の手法でゴリゴリに高速化し、C比3倍遅かったのが1.8倍程度まで盛り返したのも知ってる。
そしてC#の方はJavaが6,7で留まってた際にも言語自体が進化してたので、高速化がまだJava程には至ってない。

あと、ついでに言うと、（別人かもしれんが)
> セキュリティホールが生み出し続けられている
> 結局C/C++を使用禁止にするしか解決策はない
これも間違いで、C/C++の場合は788に書いたとおり、
・（プログラマの技量により)バグを生みやすい
・ベアメタルなので問題があった場合に直撃する
だが、アプリとしてはバグが無い（上記上側がクリアされてる)、という前提なら、RustはC/C++と比べて安全ではなく、同程度でしかない。
セキュリティホールは設計上のバグだから、言語関係なく発生する。
(だからLinuxをRustで書きなおそうという馬鹿は居ないし、居てもポシャる。
そういえば10-15年程前はLinuxをC++で書き直そう、という連中が居たはずだが、消息聞かないところを見ると、完全にポシャったようだし)
ただ、Javaの場合はセキュリティホールを突いてもVMだから、さらにVMのセキュリティホールを突く必要があり、この意味では安全。
Goの場合はランタイムだから、VM程ではないにしても、ベアメタルよりはまし。ランタイムの実装によっては、VMと同等の堅牢さも確保できる。

ただ、言っちゃ悪いが、Rustの連中がやたら布教に熱心なのは、所詮はその程度の言語なんだと思うよ。
JavaScriptなんて悪口しか聞かないが、蔓延る一方だろ。プログラマに支持されてる言語はこうなるという例だよ。
Rustは精々ポリコレがんばってください。俺はRustは死ぬと予想してるし、そう望んでます。

795 ：デフォルトの名無しさん：2024/04/29(月) 01:08:13.38 ID:ZxN+lFnq.net

>>794
配列の境界チェックをしなければどんな言語でも範囲外アクセスで続行となり致命的な穴となります
だからC/C++以外はどんな言語でも境界チェックが行われています
C/C++でも自分で境界チェックを行わなければ致命的な穴となります
したがってそこで速度差は生じません

796 ：デフォルトの名無しさん：2024/04/29(月) 05:43:48.04 ID:OeTjgfob.net

なんかスレが進んどる。半分は読んでない。
けど大規模開発になると些細なパフォーマンスは関係なくなることには同意した。
それを差し引いても自分はGoが好き。

797 ：デフォルトの名無しさん：2024/04/29(月) 08:46:16.16 ID:Cj8RVhlf.net

>>795
Cで境界チェックしてる奴なんて、世界中でも誰もいない。
境界オーバーは純粋にバグであり、プログラマの責任でデバッグしておけ、というのがCの文化。
そしてずっとそうやって来てる。

だから動的に境界チェックをしてる限り、RustはCよりも原理的に遅く、実際そう。
この意味ではRustは補助輪付きCであり、補助輪の分だけ遅い。
Rust＝馬鹿向けC、といえば分かりやすいか。
そして、C/C++でなんら問題なかった連中からすると、
Rust？記述がウザくなるがリークがなくなって境界チェックしてくれる？
いやリークなんて元々しないし、デバッグもちゃんとやってるから間に合ってるよ、であり、
何もメリットが無いからRustなんて使わない。

798 ：デフォルトの名無しさん：2024/04/29(月) 08:47:08.70 ID:Cj8RVhlf.net

とはいえ数は力である。
Cの場合は「リークや境界オーバーするような馬鹿がコード書くな」であり、
コードを募る場合は中～上級者だけに対象を絞る大前提だが、

799 ：デフォルトの名無しさん：2024/04/29(月) 08:47:32.78 ID:Cj8RVhlf.net

Rustの場合は「文法に従ってさえすればリークは防げます、境界オーバーは動的チェックしてます」らしいので、
大多数の馬鹿からもコードを募れる。これが今の時代には向いているのも確か。

ただ、馬鹿向けCなら、Goの方が上だと思うよ。境界チェックしてたかは忘れたけど。

800 ：デフォルトの名無しさん：2024/04/29(月) 09:45:04.56 ID:yABvkw5a.net

>>799
Goももちろん正しく配列境界チェックをしていてindex out of rangeのランタイムエラーが出るよ
Cだけが基本的なこともできない古い失格言語で範囲外をアクセスしてしまう

801 ：デフォルトの名無しさん：2024/04/29(月) 11:03:19.56 ID:Cj8RVhlf.net

>>800
なら馬鹿向けCはやはりGoで決まりだな。

そして、「僕は馬鹿だから補助輪ください」か、
「俺はちゃんとデバッグするから補助輪なんてイラネエ、100%の速さをくれ」か選べる。
それでいいのでは。
(というかこの辺グダってるのはRustだけで、Go使う連中は最初から100%の速度なんて求めてない。
Rustが原理的にCより遅いのは回避しようも無い事実なのに、嘘ぶいてるからおかしなことになる。
そしてこの手のことを「選択肢を絞り、政治的に解決する」のがパヨクの常套手段で、典型的には>>786
パヨってるRustは当然嫌われてるだけ)


ただまあ、もう一度整理すると、Goは
・ポインタにまつわる問題はそれなりに対策されてる
・配列の境界チェックあり
・GCあり
・ランタイム
だから、経緯とか界隈の文化とか技術者の状況を無視して、単に純粋に言語の技術的側面だけを見ると、Goは
> javaの後継 (>>774)
は言えてるのかもしれんね。
そういえばJavaは「元祖馬鹿向けC」、Goは「２代目馬鹿向けC」と言われてたし、自然な発想なのかも。
ただ「安全」に関しては、一度保険をかけたら二度と戻れないものだから、Javaの連中がGoを「安全」と見なす事はなかなか無いとも思うが。
(ランタイムエラーを吐いてくれる環境で動いているソフトは、
ランタイムエラーで誤魔化せてるから動いているのか、
そもそもバグが無いからランタイムエラーは絶対にないのか、区別付かない。
だから、ランタイムエラーがある環境でどれだけ動かした実績があっても、『保険』をはずしてベアメタルに持って行くことは出来ない)

802 ：デフォルトの名無しさん：2024/04/29(月) 11:07:50.34 ID:2zp3j2iQ.net

Cと違ってGoは賢い

str := "01234"
a := []byte(str)

fmt.Println(a[3]) // → 51 (3のascii code)
fmt.Println(a[3:5]) // → [51 52] (3と4のascii code)
fmt.Println(a[3:7]) // → [51 52 0 0] (範囲外の値は0になる)
fmt.Println(a[3:9]) // → panic: runtime error: slice bounds out of range [:9] with capacity 8

803 ：デフォルトの名無しさん：2024/04/29(月) 11:37:52.73 ID:Cj8RVhlf.net

>>802
> fmt.Println(a[3:7]) // → [51 52 0 0] (範囲外の値は0になる)
これはランタイムエラーのほうがいいのでは？

804 ：デフォルトの名無しさん：2024/04/29(月) 12:54:08.59 ID:DB9NwYGr.net

キータにでも行ってくれ

805 ：デフォルトの名無しさん：2024/04/30(火) 23:59:10.31 ID:QUZ1c+LP.net

>>803
なぜ？

806 ：デフォルトの名無しさん：2024/05/01(水) 08:22:11.43 ID:0mD/sHeG.net

>>805
動作の一貫性が無いから。
或いは

fmt.Println(a[3:9])　を [51 52 0 0 0 0 ] (範囲外の値は0になる)

でもいいが、べき論ならランタイムエラーに揃えるべき。
境界オーバーはプログラマ起因の単なるバグであり、修正することを期待されるので。

ランタイムエラーは本来
・メモリ不足
・DB開こうと思ったが応答が無い、或いは何らかの理由でDBに書き込みが出来ない
・ユーザー文字列をevalしようとしたが、エラーになる
等の、『プログラマのミスではない』問題に遭遇する可能性がある局面でtry-catchするものであって、
プログラマ起因のバグがあってもそれなりに動かす為の仕組みではない。

けどまあ、実際はお前のように後者だと勘違いしてる奴が多いのも事実。
だからJavaは基本的に低品質、というかCでは許されない品質のコードが大量に混入することになる。
これをもって「安全」とするのは本来は間違ってる。
(低品質のコードでもそれなりに動かせる環境自体は研究する価値があるのも事実だが、これは本来は明確に別件としてやるべき。
なおGoの場合はpanicから復旧する手段はなかったような気がするので、この点は多少ましかも)