Go language part 4

1 ：デフォルトの名無しさん：2020/11/16(月) 04:14:40.64 ID:fB5+0hxC.net

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

公式
https://golang.org

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

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

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


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

851 ：デフォルトの名無しさん：2022/02/22(火) 23:17:51.21 ID:6QeruhOo.net

個人的に趣味でゲーム作ってて、
（仕事はPythonとかのスクリプト言語）
そのバックエンドに高速そうなGo使おうと思って勉強してるんだけど
そういうレベルの俺からするとRustはものすごく難しそうというか、厳しそうに思えてしまうんだよな
メモリリークって一番やりそうだもん

852 ：デフォルトの名無しさん：2022/02/22(火) 23:25:51.36 ID:WirMN8li.net

>>851
何か勘違いしてない？
RustはC言語と違って
使われなくなった瞬間に自動的にメモリ解放してくれる言語

853 ：デフォルトの名無しさん：2022/02/23(水) 00:01:15.68 ID:LYKR6qmH.net

>>846
リフレクション以外もひっかかる。
試してから言え。

>>847
APIの秒間リクエスト処理数比較などもそうです。HTTPヘッダパース遅延評価機能を持つものと持たないもののベンチマーク等ではヘッダへのアクセス不要な簡易負荷で比較しているような状況になりがちです。特にデータベースアクセスなどを伴わないような場合だとその性能差は大きな差として現れます。

実際、Goのサードパーティライブラリ「fasthttp」はHTTPヘッダパース遅延評価機能を持っており、この場合ベンチマーク結果の数値は最速実装にかなり近づきます。しかし、HTTPヘッダは実用の現場の場合、評価しないわけにはいかないので実用上の性能は標準のnet/httpと大差ないということが実際にあり得ます。

854 ：デフォルトの名無しさん：2022/02/23(水) 00:49:45.29 ID:eS2QASPG.net

>>852
ガベージコレクションが無いって事しか知らない
違うのか
ってかスレチかもすまん

855 ：デフォルトの名無しさん：2022/02/23(水) 06:07:59.41 ID:hfe0Ou5T.net

>>854
Rustは使われなくなったら即座に自動的にメモリを解放してくれるため
ガベージコレクションを必要とせず速い

856 ：デフォルトの名無しさん：2022/02/23(水) 07:24:21.07 ID:0walZlbe.net

>>842
nanoexpressなんて、HTTPもまともに実装してないウンコでドヤァってんじゃねーよハゲ(笑)しかも、star数3桁だぞｗ
https://www.techempower.comの不正だらけのベンチマークばっかり見てるから、(xxで最速）なんて恥ずかしい言葉が言える。
高機能なほかがサポートしてないフルスタックとHTTPの単純なGETだけ最速になるように調整(不正ではないが）したもの比べて、
中身を、全く見てないのに「なるほど君が色々分かってないのは分かった」なんてマウント取りたいだけだろお前？

普通に使用されてるもので選ぶのが当たり前、「nanoexpressが使えるレベルの仕上がりかどうかは知らんが」しらねーのかよハゲ！！
知らないのに語りすぎだろｗ

>>843
そのくせ次に出してくるのがjust-js/justかよｗｗｗ、just.cc, main.ccがJSに見える病ですか？just-jsのmarkdownにも書かれてるが
「non-async by default - can do blocking calls and not use the event loop」
おまえがさんざ言語の優位性として言ってるasyncすらデフォルトですらねーわｗｗ

なんでおまえ最速が好きなの？
「言語の特性なんてフレームワークの最適化の陰に隠れてほぼ見えない」何度も言ってるけど、明らかに高い同時並列接続はシングル
スレッドな言語では限界があり、レテンシーが極端に落ちるのどんなベンチマーク見てもその傾向。明らかに言語の傾向は出ています、
Rustがreq/secでスループットが「最も高い」という結果も、明らかに言語特性として高負荷でgcではないのでSTWが動かないという
言語の特性がキチンと出ています。
Goが非常に高い同時の並列接続数での、レテンシー速さが一部では、Rustよりも上回る場合があることが、ベンチマークで出ています。

「フレームワークの最適化の陰に隠れてほぼ見えない」見えないのではなく、おまえは見ることが出来ないだけ。だからjust-jsなんて
恥ずかし気もなく言い出せる。オープンソースなんだからコードぐらい追えよ？

857 ：デフォルトの名無しさん：2022/02/23(水) 09:06:25.43 ID:7ZO0r/jE.net

>>851
順当なら間違いなくJS/TS。
どのみちフロントエンドも必要だからJSは習熟するしかない。
それでバックエンドも出来るのだから、Python鯖が嫌ならJS鯖になる。

ただしJSは最速ではない。
(アーキは良いのでコンパイラが出てくれば最速になる可能性もあるが、5〜10年は無いだろう）
だから順当には、JS鯖で負荷的に無理になったタイミングで移行を考えればいい。
そして個人レベルのゲーム鯖でこれが必要になる事はまずない。
もし仮に大当たりしてこうなっても、マネタイズがそれなりに出来ていれば、人を雇う事/外注も出来る。


もしコンピューターについて学びたいと思ってるのなら、順当にはCになる。
Rustを最初にやっても、色々意味が分からないはず。
一般的にはRustはC->C++->Rustと学ばないと良さを理解出来ないと言われていて、
Rustやるんだったら結局はCもやる事になるので、最初からCやっとけとなり、
「RustのおかげでRustよりもCを学ぶ連中の方が多くなってしまったではないか！！！！」とRust界隈で話題になってたのが2019だったと思う。
ただし最終的にRustを使うつもりならCの熟練者になる必要はない。ただ、知っておく必要はある。

この辺最近、こいつらはこの処理が何故重いのか全く理解出来てないんだな、と感じる事が多い。
これはコンピューターが複雑化した事もあるが、コンピューターの物理面を知らないで済ませようとしてるからだ。
（論理的なプログラミングに留めている。それを目指したのがJavaでもあるのだが）
だからベンチマークに頼らないといけなくなる。何故それが速いか遅いかを自分で判断出来る能力がないからだ。
だからこの辺、自分で判断出来る能力が欲しければCをやるべきだし、
とはいえ現実的にはフレームワークを使うわけで、フレームワークが最適化されてればそれで良し、駄目なら駄目、
と一生ベンチに頼るのもありだし、現実的にこれでも大した問題がないのも事実だろう。
この場合はCなんてやるだけ無駄、ってことになる。だからどういう能力が欲しいかを自分で考えるべきだね。

ちなみにRustもTSもNodeも無かった時代に同じ事を聞かれるとGoと答えただろう。
Go界隈の最大の問題はここで、最初に運良くブーストした？のに浸ってる。
今はもう違う事を認識出来てない。

858 ：デフォルトの名無しさん：2022/02/23(水) 09:13:45.39 ID:hfe0Ou5T.net

>>857
なぜ不便なCを勧めるのか理解できない
Cをやるくらいなら自動的にメモリを解放してくれるRustが楽で良い
スクリプト言語と似た感じで便利にプログラミングできる点も良い

859 ：デフォルトの名無しさん：2022/02/23(水) 09:22:59.07 ID:bUSsBe0W.net

Cもなんだけど、TSなんか特に。
マルチコア使うのがめちゃくちゃ下手な言語を、どうしてGoの対抗馬に持ってこれるの？
それら全ての言語を使ってないのでは？

nodeはnodeで便利だがGoと代替にはならんよ。
RustはRustで早いけどGoの代替には簡単にはならない。

860 ：デフォルトの名無しさん：2022/02/23(水) 09:27:29.73 ID:3VU0Qb68.net

objective-c: objectiveが売りなんで頭にもってきたネーミング
c++: cのフリしつつ拡張するつもりの邪悪なネーミング
go: いちにーさんしーごーでシンプルにしーの後に躍り出る命名

861 ：デフォルトの名無しさん：2022/02/23(水) 09:46:33.29 ID:7ZO0r/jE.net

>>858
モロクソ書いてるだろ。3行しか読めない馬鹿か？

オレオレゲーム鯖立てるつもりならJS/TS、個人ゲーで負荷的に無理になることはまず無いし、フロントエンドでどのみち使うし。
コンピューターについて学ぶつもりならC、Rustを先にやったところでRustを使えるようにしかならない。
現段階でGoを選ぶ理由がない。Goを学ぶ事が目的ならどうぞだが。

862 ：デフォルトの名無しさん：2022/02/23(水) 10:36:48.23 ID:EqZ7VJsi.net

フロントエンドなら最近はWASMが増えてきて記述言語で一番適していて多数派がRustといった状況
もちろんサーバーサイドもRustで行ける
Goは巨大ランタイムのせいでWASMと相性がよくない

863 ：デフォルトの名無しさん：2022/02/23(水) 11:07:50.59 ID:bUSsBe0W.net

>>862
そもそもGoは外部と相互運用する事を前提としてない言語だと思う。
少し互換性は失われるけど、isomorphicにしたいならTinyGoかなぁ。

864 ：デフォルトの名無しさん：2022/02/23(水) 11:12:09.17 ID:vCUIsgzX.net

node-jsもjust-jsもJavaScriptの実行環境。just-jsでも
(async()=>{await Promise.all([...Array(10)].map(async(_,i)=>{just.print(i);}));})();
が普通に実行できる。並列かどうかは知らない。

865 ：デフォルトの名無しさん：2022/02/23(水) 12:45:46.30 ID:gMbnXrXW.net

JSである以上、asyncなんて書いてもコールバックであり並列でもなければ、平行ですらありません。というかほんの数年前のJS使いなら
setTimeout()と書いて非同期タイマー呼び出しぐらい理解してるはずなんだが？今では、Nodeなら、nextTick()だろうけど
普通に実行できるとか、そりゃ言語仕様としてGoogleが携わってるV8使ってんだから出来るでしょうよｗ
just-jsおじさんｗ

866 ：デフォルトの名無しさん：2022/02/23(水) 13:09:37.82 ID:bUSsBe0W.net

JavaScriptのアーキテクチャが良いと言うのもよくわからんよな。
シングルスレッドだし、別プロセスは前から立てれたが、別スレッドを満足に立てられるようになったのは最近。

epoll使ったイベントループの事を褒めるのであれば、それこそGoのselectの方が賢いんだし。

867 ：デフォルトの名無しさん：2022/02/23(水) 14:41:59.08 ID:vCUIsgzX.net

一応書いておくけど何かをディスってるわけではないよ。訂正してるだけ。
V8はエンジン。言語仕様はES〜。
>>856がnon-async by default - can do blocking calls and not use the event loopを引き合いに出していたので、asyncが使えることを示した。
並列になることを期待している可能性もあったが、コードを追って確認したわけではないので、単に「知らない」と書いた。

868 ：デフォルトの名無しさん：2022/02/23(水) 15:37:31.02 ID:7ZO0r/jE.net

>>866
JSが何故ここまで蔓延ってるのか理解出来ない奴がGoを使っているのは分かった。
844の記事にもあるが、「脳死」プログラマ向き言語がGoなのだろう。
>>828の
> Goは何も考えんでも
も同じ方向を示してる。

ただな、みんなよりマシな物を使いたがるんだから、広く使われている物にはそれなりの理由があるんだよ。
そういうのを考えたくない奴がGoを使ってて、その中で満足出来る人にとっては、小さく閉じた幸せな世界なのだろうけどさ。


>>867
> cat hello.js | just --
> non-async by default - can do blocking calls and not use the event loop
このjustってもしかして鯖ではなくコマンドラインから使う用？なら欲しいかも。
今はスクリプト業務でJSを使いたい場合、DevToolのコンソールで無理矢理やってるから。
(冷静に考えてみればNodeでも出来るはずだが、やろうとした事はなかったな…)

869 ：デフォルトの名無しさん：2022/02/23(水) 15:51:46.27 ID:vCUIsgzX.net

>>868
just-jsのjustコマンドはnodejsのnodeコマンドに相当
consoleオブジェクトがないなど癖が強いので、一般利用なら個人的にはnodeでいいと思う

870 ：デフォルトの名無しさん：2022/02/23(水) 19:44:15.21 ID:bUSsBe0W.net

>>868
はびこってるのか理解できないと言うのは誰かと間違ってないか？
俺はnodeはnodeでアリだがGoの分野とは相容れないと言ってるんだが。
考えないと早くならないcppやrustと対比させてるのであって、jsとは全く対比させてない。

871 ：デフォルトの名無しさん：2022/02/23(水) 21:47:24.05 ID:EqZ7VJsi.net

>>865
それはJavaScriptに対してあまりにも無知すぎる
async/await登場以前からJSは並行プログラミング言語
async/awaitはどの言語でも同じだがそれを同期して同期風に記述できる付加機能
ちなみにworkerによってJavaScriptは並列プログラミングも可能

872 ：デフォルトの名無しさん：2022/02/24(木) 02:41:19.56 ID:aoL+Ya6Q.net

>>871
上の「 (async()=>{await Promise.all()」がどこに並列があって、関係のないworkerに話が飛ぶんだｗ誤魔化しマウント野郎ｗ
ウッホウッホホ、ドラミングｗ
おまえのご自慢のnanoexpressとかjust-jsのどこにworkerが使われてるんだ？

873 ：デフォルトの名無しさん：2022/02/24(木) 02:56:09.99 ID:aoL+Ya6Q.net

>>868
使ったことないのに言い出す奴ｗｗｗ
「JSが何故ここまで蔓延ってるのか」C#おじさんの全方位敵対ｗ

874 ：デフォルトの名無しさん：2022/02/24(木) 03:05:18.77 ID:QeQ2VGy/.net

nanoとかjustとか全く知らなくて
JSについては普通にブラウザ上とNode.jsしか使っていないが

>>865
> JSである以上、asyncなんて書いてもコールバックであり並列でもなければ、平行ですらありません。

これは明らかにウソ
JavaScriptは基本的に全て並行プログラミングであって並行に動作する
しかもJSの場合は暗黙的に自動並行開始という特徴がある
例えばGoならgo、Rustならspwanしないと並行開始されないが
JSは非同期関数(＝名前にSyncと付いていないもの)を使った時点でスケジューラに登録され並行開始
これはコールバック使用でもPromise使用でも同じでもちろんasync/await使用でも同じ
Web関連の並行性について話をするなら上記の初歩的な知識は必須な基本事項

875 ：デフォルトの名無しさん：2022/02/24(木) 03:12:11.21 ID:gyy9N0gw.net

並行か？ioか無いとスレット取りっぱなしでラ？

876 ：デフォルトの名無しさん：2022/02/24(木) 03:15:40.31 ID:yGsnJUen.net

あっそ、じゃあGoスレじゃなくNodeスレで一人語ってくださいね？言語以前に人としてのマナーを学びましょう

877 ：デフォルトの名無しさん：2022/02/24(木) 03:22:14.88 ID:9O+r6lMK.net

>>874
Goの適用範囲のメインがウェブ周辺なのにも関わらずそういう基本的な知識すらないやつ時々いるよな
あと他の言語を知らずしてGoの良い点も悪い点も語れないしな

878 ：デフォルトの名無しさん：2022/02/24(木) 03:28:06.36 ID:z0JbsGq8.net

>>875
並行と並列の違いも理解できてないから、あんまり相手にしてもしょうがないよ。Goも知らないっぽい・・・
Goはgo呼び出ししなくてもメインルーチェンがgoroutineだし

879 ：デフォルトの名無しさん：2022/02/24(木) 03:28:15.25 ID:gyy9N0gw.net

Goのメイン、Webでは無いだろ。
自分の分野がWebだからハンマー釘になってるのでは？

880 ：デフォルトの名無しさん：2022/02/24(木) 03:29:04.26 ID:gyy9N0gw.net

>>878
そうよね…なんか凄く脱力感あるわ…。
この文脈でTSを推す理由が全くわからん。

881 ：デフォルトの名無しさん：2022/02/24(木) 03:36:49.68 ID:QeQ2VGy/.net

>>878
君が理解出来ていないのではないか
JavaScriptはWorker使わない限り全て並行であり並列ではない
もちろんWorkerを使えば並列も可
まさかと思うがGoではどうなのかも理解できていなかったりする？

>>880
TSなんて書き込みをしたこともないのでそれは別人だぜ

882 ：デフォルトの名無しさん：2022/02/24(木) 03:41:58.08 ID:dTNpqM+n.net

内容ゼロの真逆のことを言い出した…
Goのメインはパイプラインデータ処理のバッチ系のほうが大きいと思うね、確かにメニーコアをあまり無駄なく活用するからwebも使えるけど

883 ：デフォルトの名無しさん：2022/02/24(木) 03:45:18.78 ID:9O+r6lMK.net

自分と異なる意見を書いてるやつは敵であり、敵はそいつ一人
という思い込みパターンは5chではよくあるな

884 ：デフォルトの名無しさん：2022/02/24(木) 03:48:08.63 ID:6w5SyGQZ.net

ID:QeQ2VGy/
「JavaScriptは基本的に全て並行プログラミングであって並行に動作する」
「JavaScriptはWorker使わない限り全て並行であり並列ではない」

(笑)解離性同一性障害かなんなのか、当てるスレ。もうさjavascriptもgoもrustも関係ないなあ

885 ：デフォルトの名無しさん：2022/02/24(木) 03:50:57.70 ID:QeQ2VGy/.net

>>884
どちらも正しいが何を言いたい？
JavaScriptは基本的に全て並行であって並列ではない
Workerという後から追加された機能を使ったときのみ並列動作が可能

886 ：デフォルトの名無しさん：2022/02/24(木) 03:54:14.80 ID:9O+r6lMK.net

おそらくだけど>>884氏は並行と並列の違いをわかっていないために誤読
さらに暴走して解離性なんちゃら言い出しただけかと

887 ：デフォルトの名無しさん：2022/02/24(木) 05:26:36.76 ID:cGpWV2sd.net

はい、ここでトリックです。(goをこよなく愛する方々スレ汚しごめんなさい)

以下動かすとnode.jsでもjust.jsでもブラウザでも約100msになります。
(async()=>{
// justのときは↓のコメント外す
// const console = {log: (arg)=>just.print(arg)};
// const setTimeout = just.setTimeout;
const sleep = ms => new Promise((f)=> setTimeout(f, ms));
const start = Date.now();
const p1 = sleep(100); // タスク1
const p2 = sleep(100); // タスク2
await p1;
await p2;
console.log('end:' + String(Date.now() - start));
})();
もしタスク1とタスク2を逐次実行するとしたら、約200msでないといけません。
タスク1とタスク2を並行に実行したので、約100msなわけです。

888 ：デフォルトの名無しさん：2022/02/24(木) 07:44:45.85 ID:7j5xGGNI.net

>>887
jsは自前でsleepしてないから妥当すぎてなんとも
シングルスレッドな言語で自前でsleepしてたらイベントも受けとれんわ
時間が来るまで処理のスイッチがなされないだけ

889 ：デフォルトの名無しさん：2022/02/24(木) 08:26:03.01 ID:gyy9N0gw.net

>>881
そうだね。そのWorkerがクソ重いって言ったぞ。
worker跨ぐ並行並列の話では？C#のasync awaitは。

Goはworkerを立てずともなってる。

890 ：デフォルトの名無しさん：2022/02/24(木) 08:27:43.23 ID:gyy9N0gw.net

>>887
sleepではなく切れ目無くCPUをガンガンに使う処理入れようか。

891 ：デフォルトの名無しさん：2022/02/24(木) 08:40:42.53 ID:7t2RQWHZ.net

>>861
Rust界隈は>>858みたいなバカ多いから……いわゆるゴールデンハンマー。

Rustはもっと学習メソッドと設計思想の解説を強化すべきだと思うわ。一番厄介な所有権についても、実行速度とメモリ安全を両立させるためにどういう管理をしているのか説明すればわかりやすいのに。

892 ：デフォルトの名無しさん：2022/02/24(木) 08:47:04.56 ID:r4yoOnDZ.net

sleep自慢なわけです。C#とasyncから始まった今ここに集まってくる奴らは、道具を眺めて優れた何かを作ってない口だけ
自分で作ってもいない日本刀の刀身眺めてニヤニヤしてる気持ち悪いマニアと一緒

893 ：デフォルトの名無しさん：2022/02/24(木) 08:59:42.43 ID:9O+r6lMK.net

>>890
スケジューラの類いを作ってことあるプログラマーならば
sleepとは時間が来るまでそのタスクが寝るだけだあって
その間に他のタスクが動くことくらいわかりそうなものだが理解できないのか？

>>888
sleepなどのタイマー類はスケジューリングランタイムが提供すべきものであって自作するものではないぞ

894 ：デフォルトの名無しさん：2022/02/24(木) 10:19:55.02 ID:gyy9N0gw.net

>>893
そもそもsetTimeoutで完全にCPUを明け渡してて何が「並行」なんよ。

895 ：デフォルトの名無しさん：2022/02/24(木) 10:36:22.27 ID:QeQ2VGy/.net

その>>887が作った例でsetTimeoutでは不満で裏で具体的に動くもので示して欲しいなら
>> const sleep = ms => new Promise((f)=> setTimeout(f, ms));
>> const p1 = sleep(100);

この部分を代わりに公開テストURLの遅延オプション(秒単位)を使って
const sleep = (sec) => {
fetch(`https://httpbin.org/delay/${sec}`);
};
const p1 = sleep(5);
これで順次なら5秒+5秒=10秒かかるところが並行に動いて5秒ちょっとで動くことがわかる

>>891
Rustも難しくない
上記と同じ例ならその部分はこれで動く
let sleep = |sec| {
spawn(fetch(format!("https://httpbin.org/delay/{sec}")))
};
明示的にspawn()する必要がある点以外はJavaScriptと同じ
ちなみにformat!はsprintf相当のフォーマッティングで変数sec部分を展開
どちらも作成されたsleep関数はPromise/Futureを返していてそれに対してawaitできる

896 ：デフォルトの名無しさん：2022/02/24(木) 12:43:57.22 ID:PkL2tYJv.net

>>869
ありがとう。
手元のNode環境で公式ドキュメントのサンプルコードで試したら普通に動いたわ。（当たり前だが）
俺が勝手に鯖専用と勘違いしていただけで、最初からそう作ってあるんだな。


>>870
ん？870＝828≠866と理解してるから、誰かと勘違いしているわけではないぞ。
ただまあ、それだと考えたくない奴がGoを使うという見解には事には同意という事か。

> 考えないと早くならないcppやrustと対比させてるのであって
禿(＝ストロウストラップ、C++の始祖の巨人）曰く、「C++はプログラマを育てる言語だ」
その理由は簡単で、「考える」からだよ。
C++はあらゆる事が出来る言語であり、思いつく事は何でも試せる。
だからこそ最速の地位を保っているわけだが、
基本的に安全装置なんて付いてないため（まあC++はそれでも付けようと努力してる方だが）
失敗する時は派手に失敗する。
そしてこの、色々試して、成功したり、失敗する過程で、プログラマは成長していく。

Goが脳死で出来るのは脳死してる奴にはメリットだけど、考えないと(慣れはするが)成長はしないので、
成長したいプログラマはGoには居ないし、Goのプログラマは成長もしてない。
多分俺が感じるGo界隈の異様さはここなのだろう。ギークさが足りない。
まあ俺がGoやる事はほぼ無いからいいんだが。

897 ：デフォルトの名無しさん：2022/02/24(木) 12:44:19.14 ID:PkL2tYJv.net

Goはアーキが良くない。中途半端なんだよ。Erlangを考えるなら、
Goはループを廃止して全部goroutineにし、基本map/reduceでmap側をgoroutineにし、
依存性のありなしだけを記述、つまり依存部分はチャネルで接続、
独立部分はgoroutineでランタイム内のスケジューラで状況を見て自動的にループに変更、
とかだと面白かったかもしれん。これなら脳死でひたすらgoroutineに切り出しで済むから。
実際はこれをやったらgoroutineが重すぎて余計に遅くなるから
どの程度goroutineにするか「考えないと」いけないわけでさ。
(この顛末をモロに書いてたのが810で俺が探してたブログ(改めて探したけどやっぱり無いが))
ただ実態はGoランライムが(OSのスケジューラと同様に)
チャネル、スタック、エントリ関数ポインタを持つGoroutine型のオブジェクトを大量に用意して
イベントドリブンで動かしているだけだから、チャネルとスタックの『衣』の部分だけどうしても重くなる。
だから普通に他言語でイベントドリブンで書かれたら絶対にその分負けるわけで、この辺もアーキの良くない部分だよ。
「最速を目指す気はない！」ってのが答えなんだろうけどさ。
ただ、簡単に書ける割には速いってのならJS/TSになってしまうし。

898 ：デフォルトの名無しさん：2022/02/24(木) 12:45:07.89 ID:PkL2tYJv.net

「考えて」判断するなら、コンピューターについて学ばなければいけない。
考える気がないから、学ぶ必要もないし知る気もない。
論理的には正しいし、実際問題として動けばいいのならこれで問題ない。
けど、なんだかね。まあ俺が文句を言う筋もないが。

他言語：オレオレ流でも曲がりなりにもいいコードを書こうとはしてる(結果はさておき)
Go信者：Goで書けば全て落着、と信じてる

だから俺ら他言語の連中は基本的にキョロキョロしてる。
「○○では△△が出来るらしいぞ」「それっていいのか？」「いやあ…」と大体空回りしてるけど、
これは自由の代償として受け止めるしかない。
ここをGoの連中は「そんなの面倒だ。Goで書けば全て問題ないんだ」と信じ切れる奴が集まっているのだろう。
そういう連中もいて、そういう言語も必要なのも事実だろう。
ただ、プラットフォームと心中する気ならC#の方が100倍マシだけどな。
元々はLinuxで使えないという問題はあったが、一応解決された（とはいえ現実的にどうなのかは知らんが）

「No is temporary, Yes is forever.」(844のブログ)はその通りなのだが、結果的には少しタイミングが早かった。
2000年代前半はオブジェクト指向＋マルチスレッド全盛だったから、Goはこれらの問題を解決するようには作ってある。
問題はその後非同期が主流になってしまった点で（まあこれも今後変わるかもだが）
goroutine is foreverであれば、非同期が主流の状況が続く限り埋没する未来しかない。
登場時の問題は解決出来てるが、仕様を追加する気がないのだから、それ以降の問題は何ら解決出来ない、
という当然の状態ではあるのだが。
この点C#は変節に変節を重ね、筋が良かったとは言いがたいが、その時の便利機能を取り込み続けた結果、
「今一番生産性が高い」の地位は何だかんだで保持してる。

899 ：デフォルトの名無しさん：2022/02/24(木) 12:48:03.88 ID:4cQqvqtW.net

ひたすら独り語り

900 ：デフォルトの名無しさん：2022/02/24(木) 12:50:56.09 ID:gyy9N0gw.net

自分にある引き出しでしか喋ってないのな。
Go書いたこと結局無さそう。

TS早くないってば。

901 ：デフォルトの名無しさん：2022/02/24(木) 12:53:50.71 ID:rd5PFIsb.net

結局最後は速さにこだわりはじめてRustにすればよかったって流れなんだよな

902 ：デフォルトの名無しさん：2022/02/24(木) 13:24:03.51 ID:QeQ2VGy/.net

>>901
たしかに速さ目当てでRustにも手を出したが
言語としての機能が豊富でGoよりもプログラミングが快適ということに気付いた

903 ：デフォルトの名無しさん：2022/02/24(木) 23:55:59.28 ID:PkL2tYJv.net

色々考えて大体整理が付いたので、ついでにつらつらと。

Goは多分文系プログラマには一定の需要がある。残念ながら多分滅びもしない。

例の「2番じゃいけないんですか？」で、
理系：「2番なのは結果であって、1番を目指さないと2番にも成れないよ」と反発したものだが、
文系：「2番目指せば2番に成れるだろ」と思っているからこその話であり、
競争を放棄した連中にとっては確かに良い塩梅ではある。

Cでいいけど、Cでは辛い、という人の為に、
Go = C + GC + String + 最低限のクラス
という事なら、確かにそこそこ使い勝手が良い。
ただし最先端のプログラミングに触れる事はないので、本人が選ぶのは自由だが、若い奴に勧めるのは悪だろう。
ただもう最先端なんて追いたくない、ロートルで良いんだ、Cでほぼ満足だ、という層には、
betterCとしては使い勝手が良い。C++はGCが無いので。

そして進化をしない事を選択した結果、最先端プログラミングをしたい奴は去り、
変わらない事が良い事だとする連中だけが残った。
だから今後とも変わらず、それが良しとされる。
合うかどうかは性格の問題だろうね。俺は無理だが。


>>894
「シングルスレッド」というキーワードに惑わされてJSを理解出来ないのなら、今のC#と同じだと考えていい。
今のC#のasyncでI/Oを切り出せばJSになるし、
JSのasyncでCPUバウンドのジョブをworkerに投げればC#になる。
JSは「メインスレッドがシングルスレッド」というだけで、I/Oはマルチスレッドで動いてる。
819のベンチではMultithreadのNodeはGoの1.5倍速出てるが、clusterというコマンドでCPU数だけインスタンスを立ててるだけ。
リクエストが干渉しないのならこれで問題ないのも事実。
スクリプト言語の癖に奇妙な程速いのは、元のアーキが良いからでもある。だからC#にモロパクされてる。
そしてC#が整備したasync文法をJSがモロパクしたわけだが。

904 ：デフォルトの名無しさん：2022/02/25(金) 04:57:49.84 ID:aDhOSI3t.net

その長い主張はまとめるとこういう主張？
言語機能が貧弱なGoは普通のプログラマーにとっては使いづらいだけの存在だけど
豊富な機能や複雑な機能を使いこなせない劣ったプログラマーにとっては需要がある

905 ：デフォルトの名無しさん：2022/02/25(金) 05:03:43.53 ID:3Y4Z8gJm.net

rust良いんだけど特定の種類のプログラム
例えば赤黒木とか二重リンクリストみたいなポインタを操作しまくるようなプログラムは明らかに向いてないんだよな

906 ：デフォルトの名無しさん：2022/02/25(金) 08:15:32.32 ID:TaGUkQP3.net

>>905
unsafe使いまくるから、野良ライブラリに任せないで標準ライブラリ用意して欲しいよな。

907 ：デフォルトの名無しさん：2022/02/25(金) 08:30:45.32 ID:u7rOKKj6.net

>>906
それは標準ライブラリの位置付けに誤解がある
Rustでは最小限のものしか標準ライブラリに入れない方針を明確にしている
だから各用途ごとの重要なライブラリは全て外部にある
例えばasync/awaitやFutureの枠組みは言語仕様と標準ライブラリにあるが
そのための非同期ランタイムは外部にある

あとunsafeの認識は大丈夫と思うが念のため
unsafeは内部に閉じ込めて安全な公開インタフェースを持つ型(type)やモジュールを作るために存在している
だから標準ライブラリも内部はunsafeだらけだが公開インタフェースを用いる限り安全が保証されるといった具合い
どのような安全なインタフェース体系にするかは用途ごとに異なるためそれぞれに適したライブラリを選ぶか自作すればよい

908 ：デフォルトの名無しさん：2022/02/25(金) 08:39:36.17 ID:ifNOEbaN.net

>>903
文系理系の切り方も謎だけど、
「適切なところに適切な道具を持ってくる」というのはエンジニアリングの基本。
誰彼構わずF1マシンに乗っても工数だけかかる。銀の弾丸は無い。

JSのasyncはworkerには投げられない。Promiseベースのworkerへの割り振りは単純にはならない(できない)。
async/awaitをなんとかしようとすると例外のためにスタックを持ち回る必要がある。
そしてclusterはマルチプロセス。

もしかしてnodeもエアプなの？

909 ：デフォルトの名無しさん：2022/02/25(金) 08:47:26.78 ID:apxGtOuK.net

>>907
その方針がRustのダメなところだという話だよ。goは一応"Build fast, reliable, and efficient software at scale"というコンセプトからはあんまり外れていない。
Rustはメモリ安全性が最大のコンセプトなのに、メモリ安全性から外れる部分をカバーしない方針はコンセプトと矛盾している。

910 ：デフォルトの名無しさん：2022/02/25(金) 08:55:53.55 ID:u7rOKKj6.net

>>909
何が問題なのかその文章からはわからないから明確に述べてほしい
RustはC++の方針の失敗を反面教師として上手く機能している
Goの良さはもちろん承知しているがRust視点から見ればGoは言語機能が貧弱なのに巨大なランタイムでGCもあり互いに真逆の立ち位置にいるわけだから

911 ：デフォルトの名無しさん：2022/02/25(金) 10:29:26.05 ID:JmFlgtI0.net

>>904
最新のプログラミングをしたい/学びたい層にはGoは駄目だが、
昨今の他言語は常に肥大化しているので、仕様の更新を潔く諦め、
(15年前のプログラミングパラダイムで良ければ、)
『ちょうどいいプログラミング言語』であるGoには一定の需要はあり続けるはず。

なら10年ごとに「ちょうどいいプログラミング言語シリーズ」として改訂していって欲しいところだが。


> 豊富な機能や複雑な機能を使いこなせない劣ったプログラマー
これはわざとだろうがちょっと悪意が酷すぎる。
というか最近の若い奴はどうやら「全機能を使う事＝使いこなす＝有能」と捉えてる感があるが、これは違う。
プログラミング言語はあくまでアプリケーションを作る道具なのだから、
自分が欲しい機能があればそれで十分で、それ以上は必要ないんだよ。

912 ：デフォルトの名無しさん：2022/02/25(金) 10:30:28.78 ID:JmFlgtI0.net

>>908
言語の思想として「2番で良いですよね」があるんだよGoには。（結果的かもしれんが）
俺としては、というか、多分アンチ勢は
「1番を目指した上で1番に成れないのは仕方ないが、1番を目ざしもしないのは駄目だ」という感覚なんだよ。
これが科学分野で競争してる連中の普通の感覚だから。
この感覚がない＝科学分野で競争を強いられてない＝文系、というわけ。

実際レンホー発言の時もそうだったが、学術会議の任命問題でも大概酷かったろ。
その前にコロナ禍で「今の日本でも科学的な物の見方を出来る奴はこんなに少ないのか」とは驚いたが。

この「1番を目指さない」が性格に合うかだよ。
｢1番を目指したい｣連中にとってはGoは武器としては貧弱すぎる。


> JSのasyncはworkerには投げられない
Workerに投げた時点でasyncだろ。接続はonmessageなんだから。
async文法を使えという話ではなく、プログラミングパラダイムとしての非同期(async)だよ。

> async/awaitをなんとかしようとすると例外のためにスタックを持ち回る必要がある。
これについては考えてない。というか、C#はそうしてるけど、あれ意味あるかね？
そもそも俺はtry-catch自体あまりいい仕組みとは思ってない。
大体においてJSではtry-catchが非同期の先になってしまうので不便だし、
リトライする気がなければ放置でも大した問題にならないし。
むしろC#がそこまでしてtry-catchを強引に持ってきた事に驚いた。
(リソース返却のためなら非同期先でcatchでよく、
リトライのためなら終了イベントでフラグ管理して丸々リトライでよいので。《どうせほぼリトライなんてしないように作るわけだし》)
まあ俺はtry-catchに関しては消極派で、Go方式でもまあいいよ程度なので、Promise以前の素のJSのtry-catchでも十分満足してる。
だからバリバリのtry-catch派とは話が噛み合わないかも。

913 ：デフォルトの名無しさん：2022/02/25(金) 11:17:47.06 ID:9DGl33if.net

>>912
こういうわかってそうで全くわかってないレスは疲れるわ

914 ：デフォルトの名無しさん：2022/02/25(金) 11:47:16.86 ID:ydtDuSNe.net

>>910
「Rustがメモリ安全をコンセプトとするなら、(メモリ安全から外れる)unsafeが必要になる事態を放置するべきではない」ということだよ。
最小ライブラリとかはあくまで開発方針で、コンセプトの根幹となるメモリ安全を犠牲にしてまで優先する話じゃないということ。優先順位付けが間違っている。
まぁ、スレ違いだからこれ以上続けないけど、そういうのを棚に上げてgoを攻撃するのはダサいと思うわ。

915 ：デフォルトの名無しさん：2022/02/25(金) 11:57:21.98 ID:ifNOEbaN.net

>>912
2番で良いも何も無くて、まず「全てにおいて1番というシンプルな解は無い」なんよ。
だから「Rustが1番、Goが2番、でも書きやすいからGoを使う」という発想がおかしい。
「この案件にはGoが1番良い」という発想でGoを選定するんよ。
科学分野での競争を強いられた結果、道具が先鋭化しただけでしょ。十分に1番を目指してるよ。

プログラミングのパラダイムとしてのasyncであれば、goは同期関数のように書いてもほぼ全ての行に対してasync/awaitだよ。それがgoroutineなんよ。mainもgoroutineだからね。
それをN:Mスレッドで回すの。

try-catchが全てにおいて良いかと言うとそうでもないから、goは多値で返したんよ。
そうではない言語であればtry-catchは必要だと思うよ。
そしてasync/await・Promise以前のtry-catchは使い物になりません。

916 ：デフォルトの名無しさん：2022/02/25(金) 12:04:36.06 ID:u7rOKKj6.net

>>914
それはunsafeを理解していない
unsafeを悪だと勝手に思い込んでいるようだがそれは違っていてunsafeは必要不可欠なもの
まず言語に関係なく「unsafeな操作無しではほとんどの構造を書けないもしくは効率的に書けない」という当たり前の事実がある
そこでRustは「型やモジュールの内部にunsafeを閉じ込めて安全なインタフェースだけを外に出す」という戦略で出来た言語

したがって標準ライブラリか外部ライブラリかに関係なく両方とも
・それらが提供する型やモジュールの内部はunsafeが存在する(もちろんゼロの場合もある)
・それらが提供する型やモジュールの外部インタフェースは安全である(ことが求められる)
全てがこの原則で作られている
一方で従来の言語C/C++ではunsafeな操作がプログラム全体に散在してしまい安全性を保証できなかった

917 ：デフォルトの名無しさん：2022/02/25(金) 12:10:17.45 ID:aDhOSI3t.net

>>912
RustはGoと異なり非同期タスクをスタックレスで実現している上に
RustはGoと同じくtry-catchを採用していないね

918 ：デフォルトの名無しさん：2022/02/25(金) 12:34:23.12 ID:ydtDuSNe.net

>>916
だからスレ違いと言ってるだろ。
しかも「メモリ安全から外れるunsafeが必要になる事態を放置している」の反論になってないし(標準ライブラリで赤黒木とか二重リンクリストを持っている方が結果的にメモリ安全にしやすいのは変わらない)。
これ以上やるならRustスレにコメしてくれ。

919 ：デフォルトの名無しさん：2022/02/25(金) 13:28:20.21 ID:aDhOSI3t.net

>>918
それは君の理解不足
unsafeな操作はプログラミングをする際に絶対避けることはできないけど
それをできる限り小さな狭い範囲に閉じ込め、かつ、その外に影響をもたらさないように設計しよう、というのが根幹
次に、二重リンクリストも二分木もRustの標準ライブラリにある
もし万が一その仕様が気に入らないなら他のクレートを探すか自作すればよい
どこに不満があるのかすら君は言うことさえ出来ずに君はイチャモンを付けているだけ

920 ：デフォルトの名無しさん：2022/02/25(金) 13:54:38.00 ID:kxjR7eze.net

>>919
go関係なさすぎ

921 ：デフォルトの名無しさん：2022/02/25(金) 14:00:53.92 ID:9DGl33if.net

>>919
完全に同意

922 ：デフォルトの名無しさん：2022/02/25(金) 16:05:49.05 ID:kxjR7eze.net

>>919
転送しました
https://mevius.5ch.net/test/read.cgi/tech/1644596656/91

923 ：デフォルトの名無しさん：2022/02/25(金) 16:13:12.03 ID:iu2arc+w.net

Rustスレでいつもホラ吹いてて隔離されてるやつだからさ
Go vs Rustみたいな隔離スレ立ててかまいたいやつだけが相手してやるといい

924 ：デフォルトの名無しさん：2022/02/25(金) 16:57:45.37 ID:u7rOKKj6.net

>>919
同意
その点を彼は全く理解できてないんだよ
そして彼は>>914でも「unsafeが必要になる事態を放置するべきではない」とか意味不明な主張をしてる

925 ：デフォルトの名無しさん：2022/02/25(金) 17:20:54.95 ID:kxjR7eze.net

>>923-924
Rustスレでやれ

926 ：デフォルトの名無しさん：2022/02/25(金) 17:48:16.43 ID:MtnpFyFt.net

せっかく対処法教えてやったのに
ちなみにそいついつも一人二役で自分のレスに安価付けるからw

927 ：デフォルトの名無しさん：2022/02/25(金) 21:14:02.35 ID:aDhOSI3t.net

>>925
俺が>>919で書いたことはRustも書くプログラマーにとっては基本的な常識なのでRustスレにおいては異論すら出ないため無意味だぜ
その基本的な常識を理解せずに間違ったRust批判をこのGoスレでする人がいたから説明したまで

928 ：デフォルトの名無しさん：2022/02/25(金) 21:35:23.89 ID:dqMip1aQ.net

このおじさん勢いあるスレならどこにでも湧くな

929 ：デフォルトの名無しさん：2022/02/25(金) 21:47:06.20 ID:3Y4Z8gJm.net

こんなおじさん昔はいなかったのにどこから湧いてきたんだろう

930 ：デフォルトの名無しさん：2022/02/25(金) 21:57:26.52 ID:cRacAjKI.net

退職してすること無くて暇なんじゃね？

931 ：デフォルトの名無しさん：2022/02/25(金) 22:05:54.67 ID:LgZQhCZj.net

観察者効果で生まれた

932 ：デフォルトの名無しさん：2022/02/25(金) 22:10:44.84 ID:31pfTetO.net

そのおじさん昔からいるぞ
昔はコテハンも使ってたが相手にされなくなったてやめたみたい
Ruby君と並ぶ有名人

933 ：デフォルトの名無しさん：2022/02/25(金) 22:50:23.56 ID:9DGl33if.net

>>925
RustスレはRustそのものの議論をするスレだから他言語との比較はやらないだろ
↓こっちのスレの方に行ってもらったほうがいいと思う。
次世代言語23 Go Nim Rust Swift Kotlin TypeScript
https://mevius.5ch.net/test/read.cgi/tech/1638086359/

もしくは↓このスレがあるんだったら
C vs C++ vs Rust Part.3

golang vs Rust Part.1
みたいなスレを作るとか

934 ：デフォルトの名無しさん：2022/02/25(金) 22:52:44.27 ID:S5tvR1Yl.net

Rust vs その他
みたいなスレにまとめてくれ

935 ：デフォルトの名無しさん：2022/02/26(土) 01:11:35.81 ID:kpnhrKVl.net

>>915
> だから「Rustが1番、Goが2番、でも書きやすいからGoを使う」という発想がおかしい。
この発想は俺は別におかしいとは思ってない。
例えばアメリカでは「Pythonで書け」と言われるらしいが、これは、
「Pythonは糞だが誰でも読める。前任者がいなくなっても後任者がすぐ見つかる」からであり、
自分個人で完結する物以外は言語特性や好みだけで選べるものでもない。
だからWeb系なら「とりあえずJS/TSで書け」となるのが妥当、という話はすでに788でした通り。
が、まあ、これはさておき、

> 「この案件にはGoが1番良い」という発想でGoを選定するんよ。
だからこれは何なんだよ？という話だろ。Web系ではない、というか、
TS/Node/Rustが出てきた時点でWeb系に最適な解ではなくなったというのは792,857で言ったとおり。


> プログラミングのパラダイムとしてのasyncであれば、
> goは同期関数のように書いてもほぼ全ての行に対してasync/awaitだよ。それがgoroutineなんよ。
これは言いすぎだが、goroutineでasyncの代替になるのは事実だ。
ただ、そういう書き方って基本的にしてないでしょ。
多くの人はマルチスレッドだと思って書いてるし、Goの公式ドキュメントもそうだったと思ったが。
(goroutineは非同期を実現するための物です！！！なんて謳ってたっけ？)

マルチスレッド：同期関数を実行するスレッドが沢山。
　単に高火力を必要とするならスレッドを複数起動して既にあるコードをぶち込めばOK。
非同期：非同期ジョブは『どの順で完了しても』問題なく動くように書く必要があり、
　また、非同期ジョブの実行順/完了順の指定も出来ない。
　（だから数珠繋ぎにするしかなく、コールバック地獄だPromiseだ、という話になる）

だから非同期の場合は根本的にマルチスレッドとはプログラミングを変える必要があって、
具体的にはイベントドリブンで書く事になる。だからJSにはmainがない。
ところがGUIもイベントドリブンで書くので、元々GUI担当のJSとは相性がいい。
（というか、だから当時は異端でしかない「非同期」を採用したのかもしれないが）

936 ：デフォルトの名無しさん：2022/02/26(土) 01:11:53.09 ID:kpnhrKVl.net

逆にmainがあるのは、
mainから入って、高火力が必要ならスレッド起動で同じコードを走行させる、という
マルチスレッドのパラダイムに適した構造だ。
だからmainがある言語、例えばCでGUIを書くと悲惨なコードになる。元々イベントドリブン向きに出来てないからだ。
Goも同じで、基本的にはfork/joinを完結にgoroutineで出来るようにしてるだけで、それはマルチスレッド向けだよ。

つっても非同期スタイルで書けば書けるのも事実だけどな。
819のベンチでGoはAsynchronousTCPとなってるが、これはそういう事なのかね？
なおNode(multithread)に1.5倍も負けてるのは、多分ランタイムの問題だよ。
JSは非同期専用のランタイムであり、それに対してマルチスレッド向けのランタイムに非同期コードを載せて非同期にしたくらいでは並べない。
というか、静的コンパイル言語がJITとはいえ動的言語に大差で負けてる事自体があり得ない事で、
これは「同じ土俵で戦えていない」事を意味する。一つはランタイムで、本来は、
・精々マシンスレッドと同程度〜数倍程度のgoroutine用
・マシンスレッドの100-1000倍以上程度のgoroutine用
・非同期コード用
とチューニングや内部構造を変えたランタイムを用意すべきだよ。
資産はコードであり、ランタイムは交換すればいいだけなので、やればいいだけだと思うのだけど。（もうやってるかもしれないが）

あとついでに言うと、ランタイムはやっぱりC/C++で書くべきだよ。境界チェックを遅くなる言い訳にするのなら特に。
Go/Rust共に、「これでCのコードはなくなりました！えっへん！」ってな事をやってたと思ったが、
ランタイムが遅いようでは勝負にならないからね。
「GoをメンテするためにはGoだけ知っていれば十分で、Cを知っている必要はない」ってのはコミュニティの宗教として重要なのは分かるけども、
実用性を考えたら、ランタイムなんて糞速い事が重要であって、何言語だっていいでしょ。
この辺、スクリプト言語はDSLだとわきまえてて、ランタイムを自言語で書こうとかいう無駄な事をやってない。

937 ：デフォルトの名無しさん：2022/02/26(土) 01:13:02.46 ID:kpnhrKVl.net

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

938 ：デフォルトの名無しさん：2022/02/26(土) 06:42:38.06 ID:BX4iLvdt.net

>>937
JavaScriptの非同期呼び出しでも普通は無視せずPromiseにcatch付けて捕獲するぜ
例: async_func_foo.catch(err => console.log(err))
あとRustの非同期呼び出しもResultが帰ってくるからエラーを捕獲できる

939 ：デフォルトの名無しさん：2022/02/26(土) 07:29:58.26 ID:xkMoRRzB.net

Goを叩く為にJavaScriptを使ってるだけで、JavaScriptの理解度かなり浅いなこのおじさん。
しかしこんなおじさんがずっと暴れてんのか、全然議論できないじゃん。対策としてはワッチョイ導入くらいしか無いだろうね。

940 ：デフォルトの名無しさん：2022/02/26(土) 08:20:49.61 ID:W5JOGvZg.net

長い文章ダラダラ書く人ってプログラマーの素質ないよ
文章を短く簡潔に書ける人ってプログラムも同様に書ける

941 ：デフォルトの名無しさん：2022/02/26(土) 08:45:19.95 ID:kpnhrKVl.net

>>938
> 例: async_func_foo.catch(err => console.log(err))
これは字が赤いか黒いかの違いしかないけどな。

まあ俺はtry-catch消極派だから、Go/Rust方式で問題なく、C#の仕様はオーバースペック過ぎるけど、
Goの場合はJSとは違ってtry-catchはそれなりに機能するはずだから、不満持ってる奴もそれなりにいるはずだけど。
（そういう連中は既に去ってる気もするが）

942 ：デフォルトの名無しさん：2022/02/26(土) 09:09:48.94 ID:yRlIqUsp.net

発想が違う、どの案件でも、その案件にとって1番だから使う、と言う言葉が伝わってないのか？
俺も十分、言外の言葉は理解できないタイプだが、流石に通じると思うんだが。

書きやすい、読みやすいからこれを選定した、と言うのは「1番」でしょ。

基本的にそういう書き方してると言うか、自然に書くとそうなる。これはドキュメントに書いてあっただろ。

非同期とマルチスレッドを分けて考えろよ…。

実際にはnodeもそうだけど、C#のTaskなんかに関してもめちゃくちゃ解像度甘いのでは？

943 ：デフォルトの名無しさん：2022/02/26(土) 09:10:48.16 ID:yRlIqUsp.net

goだと、非同期スタイルで書けるとかでなくて、ブロッキング関数、同期関数を書いたとしてもgoroutine間では適切にスイッチングされて、他の言語で言うawaitがかかってるんよ。常に低コストで。
それはN:M軽量スレッドだからなし得ることなので、他の言語ができてない以上何とも比べづらい。

944 ：デフォルトの名無しさん：2022/02/26(土) 09:11:12.66 ID:yRlIqUsp.net

オール想像で喋ってるよな、こいつ。

945 ：デフォルトの名無しさん：2022/02/26(土) 09:42:59.75 ID:Cq56y6gH.net

>>939
ワッチョイは浪人生の自演が捗るだけ

946 ：デフォルトの名無しさん：2022/02/26(土) 09:45:22.81 ID:Zjg02ogZ.net

ローニンでワッチョイ消してるやつ正規表現で弾けばええやん

947 ：デフォルトの名無しさん：2022/02/26(土) 09:55:57.50 ID:UdeBSueS.net

自演するのにワッチョイ消すバカはおらんやろ

948 ：デフォルトの名無しさん：2022/02/26(土) 10:07:05.87 ID:xkMoRRzB.net

荒らしの手間が増えるだけで十分価値がある

949 ：デフォルトの名無しさん：2022/02/26(土) 10:19:30.57 ID:kpnhrKVl.net

>>943
> ブロッキング関数、同期関数を書いたとしてもgoroutine間では適切にスイッチングされて、他の言語で言うawaitがかかってるんよ。
これは普通はマルチスレッドと言う。Thread/goroutineを複数（マルチ）起動して引っかかったらスイッチングさせるだけなのだから。
そして大概の言語はこれを自然に書けるようになってる。

> それはN:M軽量スレッドだからなし得ることなので、他の言語ができてない以上
これが嘘、というか誤解。他言語でもいくらでもスレッドを起動する事は出来る。（が余計に重くなるので普通はやらない）
goroutineもGo信者が言う程軽くもないのでいくらでも起動していいわけではない。(現実的には)

これを脳死でgoroutineはコストゼロ、だからgoroutineに切り出す事がプログラマの仕事である、と解釈できれば美しいのだが、
これを実際に試して「思ってたよりも全然パフォーマンスが出ねぇ、これならNodeの方が速ぇ…」となった顛末を書いてたのが何度も言ってるブログ。
これは言語と言うよりはランタイムの問題だけど。

950 ：デフォルトの名無しさん：2022/02/26(土) 11:28:52.99 ID:nWK21oqu.net

JSのPromiseは非同期の扱いとしてはかなり好き

951 ：デフォルトの名無しさん：2022/02/26(土) 12:15:41.10 ID:pDCyYMqI.net

>>949
N:Mのグリーンスレッドであって単なるマルチスレッドじゃない。
単に引っかかったら切り替えるんでなくてスティーリングまでやるのは他の言語の言語標準機能にはErlangぐらいにしかない。

どこが嘘なんよ。
コストゼロでは無いが、いわゆるスレッドよりは遥かに軽いぞ。