Go language part 4

[表示 : 全て最新50 1-99 101- 201- 301- 401- 501- 601- 701- 801- 901- 1001- 2ch.scのread.cgiへ]
Update time : 02/22 10:01 / Filesize : 319 KB / Number-of Response : 1020
[このスレッドの書き込みを削除する]
[＋板最近立ったスレ＆熱いスレ一覧 : ＋板最近立ったスレ／記者別一覧] [類似スレッド一覧]


↑キャッシュ検索、類似スレ動作を修正しました、ご迷惑をお掛けしました

Go language part 4

1 名前：デフォルトの名無しさん mailto:sage [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/
321 名前：デフォルトの名無しさん [2021/01/21(木) 01:16:44.85 ID:6tk1Snw3.net]: あわしろ氏がDockerはオワコン、これからはWSLと言ってる。
322 名前：デフォルトの名無しさん mailto:sage [2021/01/21(木) 03:04:48.79 ID:084E4D0G.net]: 推奨NGワード：あわしろ
323 名前：デフォルトの名無しさん mailto:sage [2021/01/21(木) 05:13:54.11 ID:pnbRvl8z.net]: 推奨NGワード：NGワード
324 名前：デフォルトの名無しさん [2021/01/21(木) 05:17:47.11 ID:6tk1Snw3.net]: イクヤさんを馬鹿にしてんのか？
325 名前：デフォルトの名無しさん mailto:sage [2021/01/21(木) 07:41:51.93 ID:JXSnM7xR.net]: >>317
バカにされているのはお前自信だぞw
326 名前：デフォルトの名無しさん mailto:sage [2021/01/21(木) 10:36:56.38 ID:9HZQp01R.net]: >>301
これ教えてくれや
327 名前：デフォルトの名無しさん [2021/01/22(金) 23:26:34.48 ID:vuLukHTi.net]: goのパッケージで、全然違う役割で同じパッケージ名つけなくなったときみんなどうしてる？
328 名前：デフォルトの名無しさん mailto:sage [2021/01/22(金) 23:47:27.87 ID:clRMgbeK.net]: apiwrapper2
apiwrapper3
saigo_no_apiwrapper
apiwrapper_final
こんなかんじで
329 名前：デフォルトの名無しさん [2021/01/24(日) 02:37:19.18 ID:49bdBtsk.net]: >>321
そうかぁ...なんだかなぁ
330 名前：デフォルトの名無しさん [2021/01/24(日) 04:02:02.83 ID:hPeuQsPP.net]: イクヤさんはバカじゃないぞ。
ただの嫌な奴だ。
331 名前：デフォルトの名無しさん [2021/01/24(日) 19:31:46.17 ID:tQo0lqIt.net]: import (
zenzen "xxx.com/omae/package"
chigau "xxx.com/aitsu/package"
)
332 名前：デフォルトの名無しさん [2021/01/24(日) 22:40:05.67 ID:49bdBtsk.net]: >>324
いや、自分が作ってるアプリ内でパッケージが被りそうな場合ですー
333 名前：デフォルトの名無しさん mailto:sage [2021/01/24(日) 23:29:36.37 ID:1VpxryXU.net]: >>325
自分でも同じじゃないか？
334 名前：デフォルトの名無しさん [2021/01/25(月) 18:17:56.09 ID:d/3tjDJa.net]: >>326
たとえば、

package encrypt

っていう、APIの通信を暗号化するパッケージを自分で作ったとして、あとからユーザーがアップロードした画像を暗号化する処理作りたくなったとき、また

package encrypt

ってつけたくなるけど、最初に作ったAPIを暗号化する処理向けにすでに「encrypt」って使われてるからどうしよーってなるって話ですね

package apiencrypt
package userimageencrypt

にするのが普通ですか？
335 名前：デフォルトの名無しさん mailto:sage [2021/01/25(月) 18:55:36.51 ID:ViKOXBu7.net]: >>327
いや、同時に使用する場合でも>>324さんの言うようにエイリアスで区別してインポートして使えばいい
例えば標準パッケージのnet/httpに対して、サブリポジトリにもgolang.org/x/net/httpがあったりとか、実験的実装でも同じパッケージ名をつけたりしているし
336 名前：デフォルトの名無しさん [2021/01/25(月) 19:17:10.86 ID:d/3tjDJa.net]: >>328
いや、importするときの話ではなくて、実装する時の話です！
ちょっとあとでサンプルコード用意しますね！！
337 名前：デフォルトの名無しさん mailto:sage [2021/01/25(月) 20:10:27.92 ID:ViKOXBu7.net]: >>329
だから公式でもやってるから気にするなw
338 名前：デフォルトの名無しさん mailto:sage [2021/01/25(月) 21:54:18.14 ID:SeLyUu4E.net]: 何がそんなに嫌なんだ？
339 名前：デフォルトの名無しさん mailto:sage [2021/01/25(月) 22:12:50.28 ID:yfUr2T9s.net]: 単にエイリアスのことを理解してないだけでは？
340 名前：デフォルトの名無しさん [2021/01/25(月) 23:54:29.57 ID:d/3tjDJa.net]: すいません、僕のエイリアスの理解が間違ってました。↑でみなさんが言ってることが正しいです。
意味不明な事言って、誠に申し訳ありませんでした😳
341 名前：デフォルトの名無しさん [2021/01/26(火) 00:02:10.18 ID:7TBhA+72.net]: このスレでgolangのモヤモヤが一つ解消できました。本当にありがとうございました。
342 名前：デフォルトの名無しさん mailto:sage [2021/01/26(火) 01:18:09.44 ID:84lZ6EGP.net]: 別にgolangだけじゃなく他の言語もほぼ同じ仕様だぞ
343 名前：デフォルトの名無しさん mailto:sage [2021/01/26(火) 02:03:46.73 ID:wg8lZWjJ.net]: 意外と素直なやつで気にいった
344 名前：デフォルトの名無しさん [2021/01/26(火) 15:48:34.40 ID:7TBhA+72.net]: >>335
別ディレクトリの同一パッケージ名つけちゃうと、同じパッケージという扱いになると勘違いしてました。
ディレクトリが違えば、ちゃんと別パッケージ扱いになるんですね
345 名前：デフォルトの名無しさん mailto:sage [2021/01/26(火) 19:32:50.53 ID:QK4hy34A.net]: 公開したアプリの機能追加しようとしたらgolintがまたゴネはじめた
調べるともうdeprecatedが可決されてるんだな
Apiと書くとAPIにしなきゃ絶許とかアホな子なんで困る
346 名前：デフォルトの名無しさん mailto:sage [2021/01/26(火) 19:41:08.73 ID:QK4hy34A.net]: すなおにgolangci-lintに切り替えた
347 名前：デフォルトの名無しさん mailto:sage [2021/01/27(水) 15:46:00.33 ID:dNCRGAZL.net]: 最近素直な人多いね🤗
348 名前：デフォルトの名無しさん mailto:sage [2021/01/27(水) 19:26:08.32 ID:D9j7gzMM.net]: 素直に尿道オナニーした
349 名前：デフォルトの名無しさん [2021/01/27(水) 20:43:24.94 ID:Qr3ry02h.net]: >>341
素直やなあ
350 名前：デフォルトの名無しさん mailto:sage [2021/01/30(土) 20:27:47.43 ID:Vt3mM499.net]: ごー言語ってどんなメリットがあるの？
351 名前：デフォルトの名無しさん mailto:sage [2021/01/30(土) 20:40:40.31 ID:qJyO6h8a.net]: 高速なWebAPIが超楽に作れる

あとは、慣れるとスクリプト代わりに使える
352 名前：デフォルトの名無しさん [2021/01/31(日) 00:23:18.15 ID:v0/+r0AQ.net]: 実行環境側で準備がいらないから、ちょっとしたツールとか作って人に配ったり、サーバーで実行したりしやすい
353 名前：デフォルトの名無しさん mailto:sage [2021/01/31(日) 02:08:30.36 ID:sEqffcUE.net]: linuxとwindowsで動かすツールにjava使ってたんだけど
少しづつGoに移植してる
かなり良い感触
ついにjavaを捨てられる
354 名前：デフォルトの名無しさん mailto:sage [2021/01/31(日) 02:54:28.37 ID:pT/gblY8.net]: >>345
それがあったか！

あとgithubからcloneしてこなくても go run できるのは意外と便利

でもこないだ statik を run したらノートンが怒って temp に作成された statik のイメージを問答無用で削除
build して実行したら動くから、temp にある exe がローカルディレクトリのファイルに書き込みするとヒューリスティック検知が危険と判断してるんだな、多分
355 名前：デフォルトの名無しさん [2021/02/03(水) 21:45:23.85 ID:CpFR0HHF.net]: >>347
> あとgithubからcloneしてこなくても go run できるのは意外と便利

これどゆこと？？
356 名前：デフォルトの名無しさん mailto:sage [2021/02/03(水) 22:46:07.77 ID:KfiW2k04.net]: >>348
この例だと statik を使うとき、go.mod に github.com/rakyll/statik を追加しとくじゃない
ここで、statik でファイルを固めるために statik コマンドをビルドしなくても
$ go run github.com/rakyll/statik -f -src=static
と打つと実行できるの

でもノートン入れてると危険な動作だと判断されるんで、run じゃなく build して実行ファイル作らないとダメだった
357 名前：デフォルトの名無しさん [2021/02/03(水) 23:03:33.06 ID:KfiW2k04.net]: このテクニックは
https://qiita.com/yaegashi/items/d1fd9f7d0c75b2bb7446#%E3%82%B5%E3%83%BC%E3%83%89%E3%83%91%E3%83%BC%E3%83%86%E3%82%A3%E3%81%AE%E3%82%B3%E3%83%BC%E3%83%89%E3%82%B8%E3%82%A7%E3%83%8D%E3%83%AC%E3%83%BC%E3%82%BF%E3%82%82-go-run-%E3%81%A7%E5%AE%9F%E8%A1%8C%E3%81%99%E3%82%8B
で知った
358 名前：デフォルトの名無しさん [2021/02/04(木) 00:47:53.46 ID:J8c7zBiK.net]: >>349
ほーー！これ知らなかった。有益な情報ありがとう！
359 名前：デフォルトの名無しさん mailto:sage [2021/02/06(土) 07:34:59.64 ID:b91D85Wz.net]: importで現在のpackage宣言からの相対パスが使えなくなったのはクソ仕様変更だと思う
おのれ Russ Cox
360 名前：デフォルトの名無しさん mailto:sage [2021/02/06(土) 07:40:15.26 ID:b91D85Wz.net]: 具体的に恨んでることは、あるサイトのコードを使い回して別のサイトのコードを書くとき、import を全部修正しなきゃならん
というかしてる
Linux ならまあ sed で置換すればなんとかなると思うけど、Windows で開発してるし
361 名前：デフォルトの名無しさん mailto:sage [2021/02/06(土) 07:42:46.96 ID:b91D85Wz.net]: あ、元のサイトの一部のコードは使い回すために go get して import してるから、sed でも面倒だわコレ
362 名前：デフォルトの名無しさん mailto:sage [2021/02/06(土) 07:48:05.22 ID:b91D85Wz.net]: なんか上手いことやってくれるツールってあるの？
363 名前：デフォルトの名無しさん mailto:sage [2021/02/06(土) 10:01:04.65 ID:3JTS0SZe.net]: タダで使わせてもらってるくせに糞とか恨むとか
そういう心根だから日本はソフトウェア技術で海外に負けるんだよ
364 名前：デフォルトの名無しさん mailto:sage [2021/02/07(日) 03:51:41.73 ID:XZf/W+8m.net]: タダで使わせてもらってるじからって大人しくしてるほうが進展しないと思うよｗ
もちろん活発にフィードバックが最善だが
365 名前：デフォルトの名無しさん mailto:sage [2021/02/07(日) 17:49:54.31 ID:7CsMj5zJ.net]: 趣味でいじってて、検索に使うAPIを作ろうとしてるんだけど
関数の動的な引数について

ぐぐると出てくるFunctional Option Patternってどれくらい使われてるのかね
structをポインタで渡す（nil判定のため）でいいかなと思い始めてるんだけど
366 名前：デフォルトの名無しさん mailto:sage [2021/02/07(日) 19:19:28.11 ID:ChxxRz8n.net]: >>358
たまに見るけど、エディタのコード補完と相性悪くてどんなオプションがあるのかがクッソ分かりにくい
個人的には大嫌い
367 名前：359 mailto:sage [2021/02/07(日) 19:21:38.26 ID:ChxxRz8n.net]: Functional Optionの話ね
補足
368 名前：デフォルトの名無しさん mailto:sage [2021/02/07(日) 19:31:24.83 ID:9kVjsnaW.net]: structをポインタで渡すという一文で、わかってるのかな？という疑念が
FOP はざっくりと、アレンジする対象のオブジェクトを受けて内容を好きに設定する関数を、引数として渡す手法

ここでその関数の引数に対象structのポインタじゃなく実体渡しで受けるようにすると、コピーを書き換えちゃう事になるから設定しても動かない
ポインタで渡す以外の話にはならない
369 名前：デフォルトの名無しさん mailto:sage [2021/02/07(日) 19:38:47.51 ID:9kVjsnaW.net]: もしかしてstructをというのは、FOPではなくオプション用のstructを用意するという話か
370 名前：デフォルトの名無しさん mailto:sage [2021/02/07(日) 21:18:42.15 ID:7CsMj5zJ.net]: >>359-360
どもども
サンプル見ても、準備する関数とか増えるから
スコープのためにimportのためにディレクトリのネストもう一個深くしないときついかなとか
色々めんどくさそうだった

>>362
そういうことです
手法として
・そもそも関数を別に切ってしまう（一番簡単だけどメンテがめんどい）
・引数を関数のために定義したstructのポインタにする
・FOP
という3つが挙がってた
371 名前：デフォルトの名無しさん mailto:sage [2021/02/08(月) 14:27:57.38 ID:UNTBzX6A.net]: 13年目のGo言語 - Steve Francia氏との対話から見えたそのエコシステム、進化、そして未来
https://www.infoq.com/jp/articles/go-language-13-years/
372 名前：デフォルトの名無しさん mailto:sage [2021/02/10(水) 23:54:39.22 ID:yW2IX31f.net]: 18か月毎に、Goのユーザベースは2倍に膨れ上がっているのです。これはつまり、今日行われる変更は、5年前に比べて10倍の人々に影響を与える、という意味になります。
373 名前：デフォルトの名無しさん mailto:sage [2021/02/10(水) 23:55:51.44 ID:yW2IX31f.net]: Goが現在備えている依存管理は素晴らしいものですが、おそらくは5年前に実現するべきものでした。
この遅れが難しい問題をより難しくして、結果的に必要以上のストレスをコミュニティに起こしているのです。

同じように、現在開発を進めている大きな言語変更がジェネリクスです。これもコミュニティに大きな影響を与えるでしょう。
もし最初からすべてをやり直すことができて、この機能がいかに重要かを事前に理解しておくことが可能だったならば、おそらく7年前から本格的な開発を始めておきたかった、と思っています。
374 名前：デフォルトの名無しさん mailto:sage [2021/02/10(水) 23:56:43.35 ID:yW2IX31f.net]: 言語として不足している唯一の大きな機能はジェネリクスです。先程も話したように、現在はこの開発に注力しています。
375 名前：デフォルトの名無しさん mailto:sage [2021/02/10(水) 23:58:38.65 ID:yW2IX31f.net]: ・Goは優れた既定言語(default language)で、システムやサーバ、API、デーモン、データベース、Webサイトなどに適しています。Goはパフォーマンスと開発者の生産性を、高いレベルで両立させています。

・Dart + Flutterは、GUIベースアプリケーション(モバイルおよびデスクトップ)に適しています。Flutterは、複数のOSとフォーマットで動作する単一クライアントアプリケーションの記述というアイデアを、高いレベルで実現しました。

・Rustは、詳細なコントロールが必要な場合に適しています。低レベルな処理やカーネルなどです。Rustは精密性に優れていますが、その分、複雑さは大きくなります。このトレードオフが理に適っている場合もあります。そうであれば、Rustが最適です。
376 名前：デフォルトの名無しさん mailto:sage [2021/02/10(水) 23:59:45.15 ID:yW2IX31f.net]: Goは1度の週末で学べますし、2週間あればプログラミングに習熟することができます。もっと早い人もいるでしょう。他のいくつかの言語で経験があれば、Goは非常に短期間に習得できます。

Goを導入した企業と会った時に、彼らが一貫して話してくれることのひとつが、Goは習得の容易な言語だ、という点なのです。
377 名前：デフォルトの名無しさん mailto:sage [2021/02/11(木) 02:00:07.60 ID:Nn8EIl24.net]: ジェネリクス結局どうなるんだよ
378 名前：デフォルトの名無しさん mailto:sage [2021/02/11(木) 03:54:00.93 ID:y89gNJMQ.net]: 議論の末リジェクトされたって結構前に見たけども
379 名前：デフォルトの名無しさん mailto:sage [2021/02/11(木) 06:20:02.21 ID:MYnJXR31.net]: あったら便利かも知れないけど、無くても不便を感じてないんだよな
多分、普段に書いてる案件の方向性の違いじゃないかな
ライブラリ書きな人は欲しがるのかも
380 名前：デフォルトの名無しさん mailto:sage [2021/02/11(木) 06:24:20.93 ID:Nn8EIl24.net]: Webアプリだと必要なケースはほぼないかな
複雑なデータ構造を扱う分野とか数値計算なら必要だろうね
381 名前：デフォルトの名無しさん mailto:sage [2021/02/11(木) 07:33:17.81 ID:MYnJXR31.net]: 複雑なデータ構造というより、多様なクラスじゃないか？
クラスが異なるが構造は同じ、といった場合に処理を使い回すための機能だから
たとえばList<Animals>とか
382 名前：デフォルトの名無しさん mailto:sage [2021/02/11(木) 09:48:01.53 ID:XTRtAjen.net]: https://github.com/golang/go/issues/43651
spec: add generic programming using type parameters #43651
Labels: Proposal Proposal-Accepted Proposal-FinalCommentPeriod

アクセプトされたぞ
383 名前：デフォルトの名無しさん mailto:sage [2021/02/11(木) 09:52:52.27 ID:XTRtAjen.net]: あと議論の末リジェクトされたのはエラーのキャッチでは？

https://github.com/golang/go/issues/43777
proposal: Go 2: catch error handler #43777
384 名前：デフォルトの名無しさん [2021/02/11(木) 10:26:29.66 ID:5PMeOFeV.net]: >>375
おお！承認されたのか
ところで、go2はいつくるの？
385 名前：デフォルトの名無しさん mailto:sage [2021/02/11(木) 11:34:18.35 ID:XTRtAjen.net]: https://blog.golang.org/generics-proposal

v1.18β（今年末）にはジェネリクスが入ってる予定だそうだから
そこからしばらくexperimental feature扱いになるとして
だいたいv1.20（再来年頭）かそこらでexperimentalじゃなくなってv2.0にするんじゃないか

まあこれは一番順調に行ったらって予想だけど
386 名前：デフォルトの名無しさん mailto:sage [2021/02/11(木) 12:43:54.91 ID:qJXsIZl0.net]: >>375
ファイナルフュージョン承認！
387 名前：デフォルトの名無しさん mailto:sage [2021/02/11(木) 13:01:17.98 ID:ZLyjCLFI.net]: 実装難しそうだから相当先だろうな
特殊化をコンパイル時にやるのか実行時にやるのかすら決まってないみたいだ
388 名前：し []: [ここ壊れてます]
389 名前：デフォルトの名無しさん mailto:sage [2021/02/11(木) 14:10:14.32 ID:MYnJXR31.net]: Javaのジェネリクス導入時みたいに、総称型コレクションの利用で警告を出すような真似はしないで欲しい
390 名前：デフォルトの名無しさん mailto:sage [2021/02/11(木) 14:18:10.77 ID:MYnJXR31.net]: なんで Java ではデフォルトで「raw型の使用を無視」にしとかないで、探して無視に指定するまでうるさく警告を出すことにしたんだろう
391 名前：デフォルトの名無しさん mailto:sage [2021/02/12(金) 03:53:22.35 ID:Cyc/UqZY.net]: 結局仕様はほぼJavaと同じか
392 名前：デフォルトの名無しさん [2021/02/12(金) 13:19:24.35 ID:vQ8mDll0.net]: エラーキャッチリジェクトかよ・・
393 名前：デフォルトの名無しさん mailto:sage [2021/02/12(金) 19:55:13.35 ID:IU5AN8go.net]: issue の本文で
func xxx() xxx, error
とか
nill
とか、go 使ってないような奴なのは見え見えだし、
妥当じゃないか？
394 名前：デフォルトの名無しさん mailto:sage [2021/02/13(土) 01:19:56.35 ID:uGwTnb+S.net]: ジェネリック馬鹿を排除できるだけでもgoを採用する意味あるわ。
395 名前：デフォルトの名無しさん [2021/02/13(土) 02:05:58.45 ID:b8+Lb4od.net]: 実務でgoやってみたいけど今は未経験の募集あまりないな
396 名前：デフォルトの名無しさん mailto:sage [2021/02/13(土) 02:18:54.12 ID:x/Vsj8xA.net]: ジェネリクス反対派って結局何がしたかったんだろう
訳がわからん
言語の設計者でもないのに
397 名前：デフォルトの名無しさん [2021/02/13(土) 03:56:17.09 ID:qDntuLeS.net]: >>386
お薬かな
398 名前：デフォルトの名無しさん mailto:sage [2021/02/13(土) 05:14:35.81 ID:0tM9M8c+.net]: Java ではジェネリクス過激派による強制で多いに迷惑したから
399 名前：デフォルトの名無しさん mailto:sage [2021/02/13(土) 08:17:20.01 ID:x5WG3KQe.net]: >>383
Javaと同じってどこが？
400 名前：デフォルトの名無しさん mailto:sage [2021/02/13(土) 09:26:28.23 ID:0tM9M8c+.net]: 正直、意味があるのか俺には理解できない
他の言語は継承による拡張なので共変反変が意味を持つ
でも go は継承による関係じゃなくて、インターフェースを具備しているかどうか
元々がインターフェースさえ合致していれば可換なのだから型パラメータには意味がない
そう思ってしまう

どうしても型パラメータが必要な用例、それを目立つように挙げて貰いたい
401 名前：デフォルトの名無しさん mailto:sage [2021/02/13(土) 10:56:01.28 ID:QtTWHsVQ.net]: Goで便利なのはsort関数とかmap関数なんかではないの？
今まで型ごとに書くしかなかったんだし。
402 名前：デフォルトの名無しさん mailto:sage [2021/02/13(土) 12:32:44.33 ID:0tM9M8c+.net]: まずmapはインターフェースをキーとしても値としても使えるから問題にならない
ソートもsort.Interfaceを具備したコレクションでソートするから、Swapとかのための比較可能な値を返すメソッドをインターフェースで持てば良い

構造体はただの入れ物に過ぎないよね
403 名前：デフォルトの名無しさん mailto:sage [2021/02/13(土) 12:40:39.64 ID:0tM9M8c+.net]: インターフェースで構造体の多態性を確保してるから、それが既に型パラメータ以上の柔軟さを持ってる
なんでインターフェースよりも性質的に劣ってる型パラメータを導入しなきゃなんないの？
頭のいい人が、それでも導入が必要だと判断したのだから、そこには理由があるはず
でも頭が悪いから、俺ではissueで見つけられなかった
404 名前：デフォルトの名無しさん mailto:sage [2021/02/13(土) 12:54:38.86 ID:QtTWHsVQ.net]: >>394
インターフェイスを使ってしまうと毎回型チェックしないといかんし、コンパイル時に縛りもかけられんでしょ。
テストで網羅するといっても、ユーザに使ってもらうライブラリなんかではそうもいかん。
静的解析でもうまくいかんこともあるし、柔軟性を持ちたいのではなくて、コンパイル言語として担保したいんじゃないか？
俺は今まで型ごとに関数作ってたけど、インターフェイスでなんとかしてたって事？それも極端だな。
405 名前：デフォルトの名無しさん mailto:sage [2021/02/13(土) 13:03:01.32 ID:0tM9M8c+.net]: >>396
というかインターフェースを型パラメータみたいな物として使っていて問題なかったと言ってるんだよ
機構として使い回すために、その機構に使いたかったらインターフェースを実装する
ソートの機構が使いたかったらsort.Interfaceを実装するでしょ
406 名前：デフォルトの名無しさん mailto:sage [2021/02/13(土) 13:27:48.18 ID:0tM9M8c+.net]: >>396
そもそも何で型チェック？
メソッドの挙動やらが違うのに同じインターフェースを使ってるのか？
Javaとかの型パラメータでも、まさか中でキャストして使ってるのか？

偶然にインターフェースを実装してしまったケースなんて想定しても仕方ないと思う
それは設計ミスだから
区別用にダミーのメソッド生やしとけば？
407 名前：デフォルトの名無しさん mailto:sage [2021/02/13(土) 13:30:40.12 ID:+kP5eWz9.net]: goは組み込みで要素が型付けされた動的配列と連想配列を持ってるから、他のコレクションはあまり必要ないんだよね
それらでカバーできないようなケースってそもそも大抵は特殊な状況なんで、汎用的なコレクションではなくアプリの要請に合わせて独自に作るのが自然
408 名前：デフォルトの名無しさん mailto:sage [2021/02/13(土) 13:45:02.72 ID:0tM9M8c+.net]: んな意味不明なジェネリクスより
>>251 のバグを直して欲しいんだよな
409 名前：デフォルトの名無しさん mailto:sage [2021/02/13(土) 13:54:07.96 ID:QtTWHsVQ.net]: >>397
ジェネリクスはロジックを使い回すのためだけにあるわけではないと思うよ。
Sortableなんてinterfaceを実装した配列を引数に受ける関数の戻り値の型は何になる？
Sortableの配列が帰ってきても無意味でしょ。

>>398
中でキャストするとかは意味不明じゃないか。
ジェネリクスがない頃のObjectの配列を受けざるをえないメソッドはまた違っただろうけど。
ダミーのメソッドとか完全に意味不明。
410 名前：デフォルトの名無しさん mailto:sage [2021/02/13(土) 14:07:47.74 ID:0tM9M8c+.net]: >>401
Sortableの配列を返すので正しい
文意からソート結果だろ？

君が型チェックしなきゃならんとか意味不明な事を言い出すからエスパーしたんだよさせるなよ
インターフェースならメソッドを呼ぶだけだから型チェックなんて話は出てこない
型チェックするってことは実体に変換しなきゃならんという話だろ

そうでない場合に考えられるケースとして、偶然に同じインターフェースを実装してしまった構造体を、偶然に渡してしまうコーディングミスを考えているとエスパーしてあげた
そんな阿呆な設計をしてるなら、引数としてるインターフェースにダミーのメソッドを生やしとけば、別のインターフェースになるから誤って渡すミスは無くなる
エスパーさせるなよ
411 名前：デフォルトの名無しさん mailto:sage [2021/02/13(土) 14:21:47.27 ID:QtTWHsVQ.net]: >>402
ソート可能なインターフェイスを受けてソート可能なインターフェイスが帰ってきても何も得しない。

[T Sortable]な関数の返り値は[]Tで十分でしょ。
結果がもう一度ソート可能かなんか必要な情報でない。

intがSortableだとして、返り値が[]Sortableだと、結果は型チェックしないとだよね。
[]intが直接帰ってきた方が効率的だし、無駄なコードではないよね。
やってることも自明。

mapとかflattenなんかなんかはジェネリクス使えないと使い物にならんと思うが。

エスパーするならジェネリクスの使いみちをエスパーしなよ。
412 名前：デフォルトの名無しさん mailto:sage [2021/02/13(土) 14:23:26.25 ID:x5WG3KQe.net]: 単一の引数だけなら>>395のようにインターフェースで代用できるけど
複数の引数や戻り値の型を合わせたいという場合は型引数が使いたいよね。
413 名前：デフォルトの名無しさん [2021/02/13(土) 14:34:17.23 ID:qDntuLeS.net]: >>398
キャストしないといけないの理解できてないあたり、型パラメータとインターフェースでの実装の違い理解してなさそう
414 名前：デフォルトの名無しさん mailto:sage [2021/02/13(土) 15:24:34.05 ID:0tM9M8c+.net]: >>404
複数の別のインターフェースを引数に持たせれば問題ないでしょ
それぞれが型パラメータとして機能するんだから

戻り値も同じ………いや、戻り値に関しては一概には言えないのか
でも実体ポインタを返すメソッドは>>251のバグに引っ掛かるんで使いたくない
→ 戻り値の実体ポインタはインターフェースを備えてるならば、本来は反変でアップキャストされてインターフェースを返しているとも判断されるべき
このバグで多態が機能しなくなるから使いたくない
具体的にはシグネチャが違うため、変種をコレクションに混在して格納できない

ジェネリクスを導入して個別に実体ポインタを返せるようにした時に同じ現象になるはず
このメソッドを持つジェネリクスな構造体は、それぞれ可換でないので多態が適用できない
コレクションに混在させられない

インターフェースを返す設計ならば、それらは実体は異なっても多態が機能してコレクションに混在格納できる
よって、インターフェースを返す方が設計として抽象度に優れている

以上の論旨から、ジェネリクスはインターフェースの下位互換だとしか見えない
415 名前：デフォルトの名無しさん mailto:sage [2021/02/13(土) 15:35:29.60 ID:x5WG3KQe.net]: >>406
違くて、2つの引数があるときにその型が同じであってほしい場合とかね。
416 名前：デフォルトの名無しさん mailto:sage [2021/02/13(土) 15:42:03.45 ID:0tM9M8c+.net]: >>407
その場合には同じインターフェースの二つの引数を持つことによって問題がある事例について具体的に指摘してくれ
型が同じことは保証されてるぞ
417 名前：デフォルトの名無しさん mailto:sage [2021/02/13(土) 15:44:29.17 ID:QtTWHsVQ.net]: >>406
インターフェイスはインターフェイスで使えば良くて、ジェネリクスで効率的にできたり型を自明にできる部分はジェネリクスを使えばよいでしょ。
今でもコードジェネレータなんかで作ってる部分もあるだろうし。

どちらかがあれば原理的にどちらかが不要なのと、
どちらかがあれば片方は作ってはいけないのは別。

Sortとか、mapの[T,U]のKeyのみ、Valueのみを([]T,[]U)と、配列として返す関数なんか書こうと思ったらジェネリクスが無いと型チェックの嵐でしょ。
確かにキャストではないけど、型チェックもノーコストではないよ。

ジェネリクスのある言語使った事無いんじゃないの？

>>403のケースなんかはどうするん？型チェックすんの？
418 名前：デフォルトの名無しさん mailto:sage [2021/02/13(土) 15:45:29.07 ID:QtTWHsVQ.net]: >>408
map[T]Uを受けて、[]Tと[]Uを返す関数。
419 名前：デフォルトの名無しさん mailto:sage [2021/02/13(土) 15:51:17.90 ID:0tM9M8c+.net]: とか顔真っ赤にして主張してきたけど、具体的にちょっと面倒な事例に自分で気づいてしまった

new() が厄介だな
new の代わりにインスタンスを生成する factory 一時クラスを外から渡してやれば解決するんだけど面倒ではある
420 名前：デフォルトの名無しさん mailto:sage [2021/02/13(土) 15:56:48.27 ID:x5WG3KQe.net]: >>408
結局は返り値の話に帰着するのかもしれないけど (T, T) -> T な関数が欲しいとかね。
421 名前：デフォルトの名無しさん mailto:sage [2021/02/13(土) 16:10:36.47 ID:QtTWHsVQ.net]: 返り値に関係なかったら、Tとそれに対するfunc(x T)を受ける関数とかかなぁ。
422 名前：デフォルトの名無しさん mailto:sage [2021/02/13(土) 16:10:51.14 ID:0tM9M8c+.net]: >>410
納得した

メソッド引数のシグネチャが異なるものを一本化して書けるわけか
確かにインターフェースじゃmap[T]Uを引数とした共通メソッドは書けない
T,Uがインターフェースだとしても、それぞれのインターフェースの組ごとにメソッドが必要になるから
423 名前：デフォルトの名無しさん mailto:sage [2021/02/13(土) 16:12:52.49 ID:QtTWHsVQ.net]: >>414
伝わってよかった。逆もしかり。
[]Tと[]Uを渡してmap[T]Uを返してくれる関数も。
Pythonでいうとzip関数的な。
424 名前：デフォルトの名無しさん mailto:sage [2021/02/13(土) 17:03:51.51 ID:0tM9M8c+.net]: >>415
JavaだとProxyを使って何でも解決するという黒魔術的解決手段があるのが恐ろしい
デバッグ用だよねとか思ってると struts とかwebフレームワークのソース読んだ時に、インタセプターとかで普通に使われていて更にビビる
425 名前：デフォルトの名無しさん mailto:sage [2021/02/13(土) 17:45:13.81 ID:F3GRWro3.net]: >>416
Springの十八番だな。
ただ、ああいう方法だと結局、ランタイムで死ぬかどうかをテストで担保するしかないって方向性に行きがち。
あとパフォーマンスももちろん遅い。
今回のジェネリクスがどう実装されるかが一番気になるけど、俺的には素直に関数たくさん作って欲しい。
426 名前：デフォルトの名無しさん mailto:sage [2021/02/14(日) 01:42:02.77 ID:o9olz+i9.net]: これメソッドには型パラメータ無理なの？
427 名前：デフォルトの名無しさん [2021/02/15(月) 02:10:12.40 ID:QPKY0Zj9.net]: >>400
どう考えてもバグじゃないと思う。Goのinterfaceとstructの関係はembedしなければほぼ静的方チェックありの
ダックタイピングだから「そのメソッド実装がインタフェースAを実装している」と思い込んでるのは自分であって
実際にはJavaのようなimplementではないです。もっと言うなら、ルックアップが行われるのは、実行時であり
コンパイルは厳密な型チェックが行われます
428 名前：デフォルトの名無しさん mailto:sage [2021/02/15(月) 07:00:31.98 ID:fLCzNLbm.net]: >>419
んじゃ、言語拡張要望と言い直そう
メソッドの戻り値がインターフェースでの戻り値の型に反変できるなら、インターフェースを具備していると判定して欲しい、と
429 名前：デフォルトの名無しさん mailto:sage [2021/02/15(月) 07:12:07.78 ID:E7fw/gtI.net]: ポインタじゃなくてインターフェースを返すのが正しいのでは？
何故ポインタを返す
インターフェースのポインタにはなんの意味もない
430 名前：デフォルトの名無しさん mailto:sage [2021/02/15(月) 07:45:45.18 ID:NOYsfhr4.net]: >>421
いや、インターフェースのポインタじゃなくて、構造体ポインタ
構造体ポインタ*SubがインターフェースISubを具備しているのは代入させて確認

んでISubを返すメソッドを持つ別のインターフェースを具備させようとした時に、戻り値としてISubではなく、ISubに代入可能な*Subを返させると、シグネチャ不一致でエラー
ISub を期待しているのに *Sub を返していると

インターフェースを具備しているかの判定でも、反変を考慮してくれないだろうか、という要望
そうすればインターフェース対応でキャストして返すメソッドと構造体固有のメソッドの二本を作らなくて済むから

作れよ、と言われちゃうか
431 名前：デフォルトの名無しさん mailto:sage [2021/02/15(月) 08:02:45.25 ID:NOYsfhr4.net]: >>421
シグネチャが合わないコンパイルエラーの時だけ、戻り値の型が互換(反変可能)かで追加チェックさせればいいから、パフォーマンスが極端に悪くなることはないはず
という見立て
432 名前：デフォルトの名無しさん [2021/02/15(月) 14:32:51.97 ID:QPKY0Zj9.net]: >>421
インタフェースを返すのが理論的にも実装にも正しいけど、インターフェースのポインタは埋め込みを
するときにコンパイラが使う。あんまりこれをやるモジュールは（メモリサイズが大きくなるから？）
標準ライブラリ以外見ないけど。
>>423
「 ISub を期待」というのは分からなくも無いけど、実行時じゃなければ分からないチェックを
コンパイルの速度と、言語の厳格性を犠牲にして、（かなり）保守的な言語がやると思えないですね
433 名前：デフォルトの名無しさん mailto:sage [2021/02/17(水) 21:45:03.79 ID:cMG1yy0u.net]: Go 1.16 is released
https://blog.golang.org/go1.16
434 名前：デフォルトの名無しさん mailto:sage [2021/02/18(木) 00:00:24.35 ID:Nj/E13Sa.net]: 今回の目玉は embed で、あとは modules がデフォルト利用になったくらいか
96% って、どこから来た数字なんだろ？
435 名前：デフォルトの名無しさん mailto:sage [2021/02/18(木) 01:11:43.46 ID:cGA2Qyj5.net]: ioutilオワコンになったのか
436 名前：デフォルトの名無しさん [2021/02/18(木) 01:58:45.29 ID:DBnOoZ1k.net]: え、これすごくない？
ファイル内容のバイナリを変数に設定できるのか
クソ便利そう
437 名前：デフォルトの名無しさん mailto:sage [2021/02/18(木) 02:18:54.53 ID:cGA2Qyj5.net]: 凄くはないがまた変なものを入れたなあ
438 名前：デフォルトの名無しさん mailto:sage [2021/02/18(木) 08:15:16.68 ID:a7MZxCIG.net]: そんなに変なもの？
結構ニーズあったじゃん。
439 名前：デフォルトの名無しさん mailto:sage [2021/02/18(木) 10:42:52.64 ID:CVa006wI.net]: embed例を交えながら詳しく懇切丁寧に説明してくれ
440 名前：デフォルトの名無しさん mailto:sage [2021/02/18(木) 10:59:32.89 ID:a7MZxCIG.net]: >>431
WebUIを持ったアプリの画像なんかのアセットをバイナリ一つで配布したいとか。
441 名前：デフォルトの名無しさん mailto:sage [2021/02/18(木) 19:44:54.68 ID:13d7fDKM.net]: それはしゅごい
442 名前：デフォルトの名無しさん mailto:sage [2021/02/19(金) 01:02:34.28 ID:h/t0+GoU.net]: それって凄いことなの？逆に今までできなかったの？
443 名前：デフォルトの名無しさん [2021/02/19(金) 02:06:27.21 ID:C4/TpWTT.net]: 外部ライブラリで出来てたから、そんなにインパクトはない。むしろNotifyContextの方が意味ありそう
こういう事は他言語だと非常にやりづらい
444 名前：デフォルトの名無しさん mailto:sage [2021/02/19(金) 02:54:55.96 ID:h/t0+GoU.net]: NotifyContext例を交えながら詳しく懇切丁寧に説明してくれ
445 名前：デフォルトの名無しさん mailto:sage [2021/02/19(金) 02:57:11.30 ID:EqIzDHt7.net]: 自分で調べろや
446 名前：デフォルトの名無しさん mailto:sage [2021/02/20(土) 05:37:00.99 ID:b7O3Qybq.net]: android アプリを調べようと、go android 常駐アプリで検索したんだけど、go の記事�
447 名前：ｪ探しづらい 以前からポケモンが引っ掛かっていた上に、次のandroid11はGoエディションなのか？ []: [ここ壊れてます]
448 名前：デフォルトの名無しさん mailto:sage [2021/02/20(土) 10:48:48.97 ID:b7O3Qybq.net]: 1.16 だと、Deprecation of io/ioutil は面倒に感じるなぁ
一杯使っちゃっていて
449 名前：デフォルトの名無しさん mailto:sage [2021/02/20(土) 12:08:15.81 ID:AdT3uMXC.net]: 検索ワードはgolangって言うのはこのスレの常識
450 名前：デフォルトの名無しさん mailto:sage [2021/02/20(土) 12:48:22.08 ID:Gn0QOwDd.net]: そういやgolang.jpってもう活動していないのか
日本のgoコミュニティの総本山たるべきドメイン名を無駄にしやがって
451 名前：デフォルトの名無しさん [2021/02/20(土) 16:13:03.32 ID:seCRjC7e.net]: ほんと返すがえすも go は名前がクソい
452 名前：デフォルトの名無しさん mailto:sage [2021/02/20(土) 17:07:51.09 ID:QogkRbMK.net]: ほ～ら～　あしもとを見～て　golang
453 名前：デフォルトの名無しさん mailto:sage [2021/02/21(日) 00:08:47.19 ID:4ZSApsu7.net]: 名前よりもマスコットがキモすぎるのが気になってしかたがない
454 名前：デフォルトの名無しさん mailto:sage [2021/02/21(日) 00:49:16.30 ID:1AmDYpOZ.net]: キモネズミ
455 名前：デフォルトの名無しさん mailto:sage [2021/02/21(日) 03:58:10.72 ID:XsukC5HX.net]: ヽ( ;ﾟ;ж;ﾟ;)ﾉｺﾞｰﾌｧｯ
456 名前：デフォルトの名無しさん mailto:sage [2021/02/21(日) 07:48:25.22 ID:y91K2jdN.net]: 俺みたいにゴーファ君を結構可愛いとか思う人間がいるから厄介
457 名前：デフォルトの名無しさん mailto:sage [2021/02/21(日) 20:35:02.33 ID:H/D/EzLk.net]: JAVAのマスコットよりはまし(´・ω・`)
458 名前：デフォルトの名無しさん mailto:sage [2021/02/21(日) 22:08:56.40 ID:RiVq+6hw.net]: c#はマスコットいないんだぞ
クラウディアとか藍澤光とかいたけどな
459 名前：デフォルトの名無しさん mailto:sage [2021/02/21(日) 22:43:47.36 ID:y91K2jdN.net]: マスコット…冴子先生がCortanaとして復職してくれたなら、Cortanaボタンを非表示にしないのに…
460 名前：デフォルトの名無しさん mailto:sage [2021/02/22(月) 00:06:54.06 ID:X+4sJ2iC.net]: マスコットはD言語がカワイイ。LISPが最キモ。
461 名前：デフォルトの名無しさん mailto:sage [2021/02/22(月) 00:53:22.82 ID:vmWIyuyK.net]: LISPにマスコットなんてあったのか・・とおもってググってみたら
たしかにこれはエグい
キモすぎ
462 名前：デフォルトの名無しさん mailto:sage [2021/02/22(月) 18:22:17.90 ID:GfaSrtw3.net]: なんか gui ライブラリで調べるといろいろ出てきてよくわからん
マルチプラットフォームな gui って何がええんや？
Qt は golang で使ってる人おるんかえ？
463 名前：デフォルトの名無しさん mailto:sage [2021/02/22(月) 18:24:31.58 ID:Xis0SD1d.net]: GoでGUIアプリを作っている人はほぼ存在しない
464 名前：デフォルトの名無しさん mailto:sage [2021/02/22(月) 18:48:30.06 ID:GfaSrtw3.net]: >>454
ありがとう、そうなんか
主にバックエンドで使われてる感じなんかな

https://i.imgur.com/pGBnPCA.png

ふむう
465 名前：デフォルトの名無しさん mailto:sage [2021/02/22(月) 20:26:35.06 ID:MldvwhvK.net]: ローカルHTTPD建てて、ブラウザからAPIで操作するアプリは提供してる
466 名前：デフォルトの名無しさん mailto:sage [2021/02/23(火) 15:36:36.73 ID:zz5KyfHR.net]: >>455
ウチはElectronでGUI作ってバックグラウンドにGo使うてる
467 名前：デフォルトの名無しさん mailto:sage [2021/02/23(火) 16:06:31.74 ID:+9qO7MJU.net]: >>457
面白そうだね
オレオレGUIツールだと.netが楽すぎるのでそっちで書いちゃうけどGOで書くのも楽しそうだ
468 名前：デフォルトの名無しさん mailto:sage [2021/02/23(火) 16:23:00.26 ID:ADOMIACK.net]: GUIは俺は普通にブラウザ起こしてるな。
IE使われると辛いけど。
469 名前：デフォルトの名無しさん [2021/02/23(火) 17:19:08.91 ID:VHVs6NAa.net]: 簡単なguiツール作るならlorcaオススメ
470 名前：デフォルトの名無しさん mailto:sage [2021/02/23(火) 20:02:44.99 ID:K/n0XAdC.net]: for (大分類) {
　for (中分類) {
　　for (小分類) {

　　　wg := sync.WaitGroup{}
　　　cpus := runtime.NumCPU()
　　　errCh := make(chan error, cpus)
　　　defer close(errCh)

　　　for (アイテム) {
　　　　wg.Add(1
471 名前：) go func() { defer wg.Done() errCh <- 他の関数() }() } err := <-errCh if err != nil { return だめです } wg.Wait() } } } こんなコードでwaitしっぱなしになるんだけど なぜなんでしょうか(´・ω・｀) 途中の即時関数にwgのポインタ（&wg）渡すのもやってみたけど、 結果変わらなかった []: [ここ壊れてます]
472 名前：デフォルトの名無しさん mailto:sage [2021/02/23(火) 21:17:47.85 ID:PToR0U76.net]: >>461
・errCh <- 他の関数() はバッファが一杯の場合ブロックする
・err := <-errCh はブロックする
goのchannelは初心者が使うと極めてデッドロックを引き起こしやすいので、まずはchannel使わずに正しく動作するものを作れるようになってから手を出すことを強くお勧めする
473 名前：デフォルトの名無しさん mailto:sage [2021/02/23(火) 21:36:09.19 ID:K/n0XAdC.net]: >>462
ありがとうございます
全体としては物はもうできていて、上記の処理は大量にファイルを出力するため重く
速度改善としてgoroutineを入れようと試みてました。
まあファイルシステムのi/oがボトルネックだとそんなに変わらないかもしれませんが…
474 名前：デフォルトの名無しさん mailto:sage [2021/02/23(火) 22:03:06.71 ID:K/n0XAdC.net]: エラー判定をgoroutineと同じ階層で判定することで返ってくるようになりました
一応オチとしてめも
速度改善はならず
475 名前：デフォルトの名無しさん mailto:sage [2021/02/23(火) 22:38:49.04 ID:VENYjQF8.net]: >>461
ぱっと見しただけで検討しないで書くけど
errCh の受付数はcpuの数
errChの読み込みが一回しかしてないからアイテム数が受付数を越えたら書き込みがブロックされてwgがDoneされない
DoneされないからWaitは抜けてこない
のでデッドロックということでは？
476 名前：デフォルトの名無しさん mailto:sage [2021/02/23(火) 22:41:20.70 ID:K/n0XAdC.net]: >>465
ご指摘のとおりでした
なのでgoroutineと同じループの中でerrChを取るようにしたら動作しました

wg作る位置も動かないからだんだんスコープ狭めていったんですが
一番外のforの外で作って動きました
477 名前：デフォルトの名無しさん mailto:sage [2021/02/23(火) 23:35:24.39 ID:yNATq+Pp.net]: それみんな絶対最初ハマるよな
478 名前：デフォルトの名無しさん mailto:sage [2021/02/26(金) 08:25:09.52 ID:Bk6XWue8.net]: Goのグラフィックって、標準だとこんなに低レベル処理なパッケージしかないのか……
JavaScriptで言うならImageDataしかない感じ
誰かのライブラリ使わないと線を引くだけでも大変
479 名前：デフォルトの名無しさん mailto:sage [2021/02/26(金) 10:33:50.46 ID:jNY0Xh1+.net]: Golang でグラフィックやろうと思う時点で変
480 名前：デフォルトの名無しさん mailto:sage [2021/02/26(金) 12:53:20.65 ID:Bk6XWue8.net]: イメージを生成するサービスを考えてたん
481 名前：デフォルトの名無しさん mailto:sage [2021/02/26(金) 12:57:25.97 ID:jNY0Xh1+.net]: 　　　　　 ∧,,,∧
　　　　（・ω・｀）　スマンカッタ・・・
　　　　　/　y/　ヽ
　━(m)二フ⊂[_ノ
　　　（ノノノ l l l ）
　￣￣￣￣￣￣￣￣￣
482 名前：デフォルトの名無しさん [2021/02/27(土) 00:21:54.45 ID:vRM0KdjR.net]: 標準ライブラリなんて小さい方がええやん。HTML5のCanvas APIみたいのならgithubに腐る程ある
github.com/fogleman/gg
483 名前：デフォルトの名無しさん mailto:sage [2021/03/01(月) 04:10:54.66 ID:TpLFIcMN.net]: Goに期待しすぎだろ
484 名前：デフォルトの名無しさん mailto:sage [2021/03/01(月) 05:09:43.67 ID:slICkU79.net]: まあ、イケイケGoGoジャーンプ！って言葉もあるくらいやし…
485 名前：デフォルトの名無しさん mailto:sage [2021/03/01(月) 18:31:47.86 ID:yHt6Qgj2.net]: 姫ちゃん…
486 名前：デフォルトの名無しさん mailto:sage [2021/03/01(月) 20:51:58.46 ID:Uq9hcXch.net]: https://i.imgur.com/2zyfBy2.jpg
goで思い出すのはこれだった
487 名前：デフォルトの名無しさん mailto:sage [2021/03/03(水) 00:18:59.60 ID:p9OW2PxW.net]: golang.jpドメイン譲渡したのね
488 名前：デフォルトの名無しさん mailto:sage [2021/03/03(水) 22:42:43.62 ID:jgL4cdff.net]: 本当だ。いまのところ微妙そう
489 名前：デフォルトの名無しさん mailto:sage [2021/03/04(木) 00:12:11.42 ID:zOLUDfBP.net]: bloggerってまじかよ
490 名前：デフォルトの名無しさん mailto:sage [2021/03/05(金) 23:37:39.02 ID:NrMSs+Xp.net]: 16がでてしばらくたつけど、何か問題があった人いる？

無かったら入れようとか姑息
491 名前：デフォルトの名無しさん mailto:sage [2021/03/06(土) 00:21:56.60 ID:fsuLBHjt.net]: 当初から分かってたがPlan9同様、実用言語ではなく
他の言語のリファレンスとしての研究用言語になったな
492 名前：デフォルトの名無しさん mailto:sage [2021/03/06(土) 00:38:15.94 ID:KM3KYugu.net]: 実用してるが…？
493 名前：デフォルトの名無しさん mailto:sage [2021/03/06(土) 00:40:14.00 ID:d8HwcXCo.net]: もともとグーグルの社内言語だったと聞くが
本家では今も活用されているのかね
494 名前：デフォルトの名無しさん [2021/03/06(土) 00:45:32.22 ID:KIij34oc.net]: Plan9を実用してる物好きもいるわけだし
495 名前：デフォルトの名無しさん mailto:sage [2021/03/06(土) 01:20:00.90 ID:W4toJ95e.net]: モンストの通知サービスの一部でも、他の言語とのトライアルの結果で採用したとのインタビュー記事が、つい先日あったし(日経XTECH)
496 名前：デフォルトの名無しさん mailto:sage [2021/03/06(土) 01:21:35.92 ID:W4toJ95e.net]: 学習が簡単というのがデカかったらしい
分かってるな
497 名前：デフォルトの名無しさん mailto:sage [2021/03/27(土) 12:51:18.06 ID:odHdDNPL.net]: CodeZine（コードジン）: 2020年のGo言語利用状況が明らかに、9648名の開発者が回答.
https://codezine.jp/article/detail/13819

正直、手前味噌過ぎて萎える
無作為アンケートならともかくなぁ
498 名前：デフォルトの名無しさん mailto:sage [2021/04/24(土) 03:38:06.28 ID:ifUTO7D9.net]: echoでAPIのパラメータの初期値を設定する方法って
ぐぐると構造体作ってコンストラクタで設定しよう！とか出てくるんだけど
なんかすごく面倒な上記述場所が離れててわかりにくい気がしてならないんだけど

例えばこんなのは悪手？
まあ悪手なんだろうけど

func getParam(p string, defaultValue interface{}) interface{} {
　switch defaultValue .(type) {
　　case string:
　　　if p == "" {
　　　　return defaultValue
　　　} else {
　　　　return p
　　　}
　　case int:
　　　ret, err := strconv.Atoi(p)
　　　if err != nil {
　　　　return defaultValue
　　　}
　　　return ret
　}
　return nil
}

pageNo := getParam(c.Get("pageNo"), 1).(int)

一般的な方法ってあるのかね
499 名前：デフォルトの名無しさん mailto:sage [2021/04/28(水) 00:42:58.14 ID:1SQ+syPV.net]: 勢いないな
特に語ることがないんだろうけど寂しい
500 名前：デフォルトの名無しさん mailto:sage [2021/04/28(水) 00:50:07.66 ID:yDqZolk/.net]: 2こないとずっとこうだろな
501 名前：デフォルトの名無しさん mailto:sage [2021/04/28(水) 20:28:06.34 ID:4UCtxfw0.net]: 見上げて～golang～♪
502 名前：デフォルトの名無しさん mailto:sage [2021/04/29(木) 01:22:39.54 ID:466xktgC.net]: ひさしぶりに書く機会があったが
やっぱクソだなこの言語
503 名前：デフォルトの名無しさん [2021/04/29(木) 13:27:14.24 ID:VDhRy7EO.net]: >>492
けっこう同意
504 名前：デフォルトの名無しさん mailto:sage [2021/04/29(木) 17:19:19.73 ID:Ir6i0rIh.net]: 肝心のグーグルに普及させる気がないように思う
メンテナンスが別組織に移ったにしてもさ
505 名前：デフォルトの名無しさん [2021/04/29(木) 20:46:39.37 ID:CJL0HvU9.net]: ファンクション実行環境が使い放題のところでは有用かもしれないけど、それ以外だとあまりいいことがない
506 名前：デフォルトの名無しさん mailto:sage [2021/04/29(木) 22:07:05.66 ID:WSQEbpw8.net]: ジェネリクス入ればまた話題になるさ
それ以外では大きな機能追加はなさそうだし
話すことはゼロ
507 名前：デフォルトの名無しさん [2021/05/03(月) 07:41:43.88 ID:Yuy7LADv.net]: >>496
これまた同意
508 名前：デフォルトの名無しさん [2021/05/03(月) 10:42:59.25 ID:O7+GYvY4.net]: Ubuntuに最新のfzfを入れるために成り行きでgoも入れてビルドに使ってるんだけど、使い勝手どう？
509 名前：デフォルトの名無しさん [2021/05/10(月) 23:35:35.91 ID:FH4+0Y9S.net]: 全体的な満足度は高く、回答者の92％がGoを使用して満足しています
510 名前：デフォルトの名無しさん [2021/05/12(水) 12:17:45.17 ID:/qsSpkSD.net]: 公式の正規表現パッケージだと機能が足りないんで高機能版を探してるんだけど
例えばgolang pcreで検索すると玉石混交っぽいのがたくさんヒットします。定番はどれですか？
511 名前：デフォルトの名無しさん mailto:sage [2021/05/12(水) 12:48:25.99 ID:heOXda5C.net]: ないよ
基本的に標準で妥協するのがgoの流儀
512 名前：デフォルトの名無しさん mailto:sage [2021/05/12(水) 13:26:25.47 ID:4BNP4E9q.net]: Golint is deprecated and frozen.
https://github.com/golang/lint
513 名前：デフォルトの名無しさん mailto:sage [2021/05/12(水) 14:21:32.78 ID:V3rxtHou.net]: golintなんて使うな！ってのはかなり前から言われてなかったか？
そうか、とうとうというかやっと非推奨になったか
514 名前：デフォルトの名無しさん mailto:sage [2021/05/12(水) 15:46:19.35 ID:cNdHMJPH.net]: Golintよりあの独特のキモさのあるマスコットを frozen してくれ
515 名前：デフォルトの名無しさん mailto:sage [2021/05/13(木) 06:49:06.23 ID:i4261GGU.net]: そういや、今は golangci-lint で gosample, unused, deadcode を disable して使ってるけど、皆は何を使ってる？
516 名前：デフォルトの名無しさん mailto:sage [2021/05/17(月) 09:13:26.08 ID:kl1wKiv0.net]: ごふぁー君、日本人が日本の感覚でリファインしたらどうなるだろうな
可愛くなるかな
517 名前：デフォルトの名無しさん mailto:sage [2021/05/17(月) 09:37:57.05 ID:Lk3ol8M7.net]: 美少女にされてポリコレで炎上して終了
518 名前：デフォルトの名無しさん mailto:sage [2021/05/17(月) 10:27:08.28 ID:tCPY+RXs.net]: 出目だけ直せばかなり可愛いと思うの
519 名前：デフォルトの名無しさん mailto:sage [2021/05/17(月) 16:09:31.77 ID:ki4Fszz7.net]: もうある
520 名前：デフォルトの名無しさん mailto:sage [2021/05/17(月) 21:21:05.60 ID:gfx8XjK2.net]: えー、めっちゃかわいいやん。
いろいろ並べたらかなり上位に食い込むはず
https://www.google.com/search?q=gopher+golang

ちなlisp
https://www.google.com/search?q=lisp+alien
521 名前：デフォルトの名無しさん mailto:sage [2021/05/18(火) 07:51:53.47 ID:KgfYT/kM.net]: lispキモッ!!!!!
522 名前：デフォルトの名無しさん mailto:sage [2021/05/18(火) 11:48:20.95 ID:JTwnomFG.net]: land of lisp知らん人って居るの？居るか、昔の本やもんね…
523 名前：デフォルトの名無しさん mailto:sage [2021/05/18(火) 11:55:07.53 ID:eZ1jimh0.net]: lisp興味あったから買ったけど、興味なかったら買わないだろうし知らない人多そう。
あの本のコミック感好き
524 名前：デフォルトの名無しさん mailto:sage [2021/05/18(火) 12:47:44.48 ID:KgfYT/kM.net]: lispみたいな妙ちくりんな言語好きなやつらって
かっこつけるのが好きなだけなやつのイメージ
525 名前：デフォルトの名無しさん mailto:sage [2021/05/18(火) 13:43:10.70 ID:eZ1jimh0.net]: ()なだけにか、うまい
526 名前：デフォルトの名無しさん mailto:sage [2021/05/18(火) 15:18:58.11 ID:rbHsLKwn.net]: 歴史的な意義は大きいよ
lispマシンみたいな非効率な物作るのも今では考えられんし
調べる分には面白い
527 名前：デフォルトの名無しさん mailto:sage [2021/05/18(火) 17:50:33.31 ID:K7AiWxDd.net]: じゃ、gopherはキャワイイ、lisp alienはカッコいいって結論でいいよね？
528 名前：デフォルトの名無しさん mailto:sage [2021/05/20(木) 20:04:23.04 ID:eq1VjwUx.net]: いいよ
529 名前：デフォルトの名無しさん mailto:sage [2021/05/31(月) 19:04:04.05 ID:4YxEhylU.net]: 月末日の今日timeのAddDateのキチンとした仕様理解したわ…
530 名前：デフォルトの名無しさん mailto:sage [2021/06/01(火) 03:54:23.59 ID:XPr1LW+9.net]: A Tour of Goでわざと誤ったコード書いてRunするとエラーとか何も表示されないんだけどこれって俺環？
一応FirefoxとChromeで試した
531 名前：デフォルトの名無しさん mailto:sage [2021/06/01(火) 05:07:07.58 ID:uviIosIU.net]: エラー行と、Go build failed が出てます
play ground のサーバが落ちてたとか？
532 名前：デフォルトの名無しさん mailto:sage [2021/06/01(火) 07:39:06.98 ID:AwIwdigt.net]: 大抵、拡張とかせい
533 名前：デフォルトの名無しさん [2021/06/05(土) 17:26:46.46 ID:/GCBUkfd.net]: GoにGenerics入るの喜ばれてるのを見るにD言語で良かったのではってなる・・・
534 名前：デフォルトの名無しさん [2021/06/08(火) 20:33:43.16 ID:hv7oAT4j.net]: GoLandっていうIDEすこ
これ使ったら他のIDEには移れねえわ
535 名前：デフォルトの名無しさん mailto:sage [2021/06/08(火) 20:47:33.83 ID:Yg8CMFGO.net]: 基本的にVSCode信者だけどVSCodeのGo拡張は糞すぎるんだよなあ
まあどうせ他の言語も日常的に使うからGoのためだけに移行するのはありえないんだが、さすがに糞すぎる
536 名前：デフォルトの名無しさん mailto:sage [2021/06/08(火) 21:09:41.18 ID:1LMznI/d.net]: いうほどか？C++とかもあんなもんじゃん
537 名前：デフォルトの名無しさん mailto:sage [2021/06/08(火) 21:19:41.74 ID:TOKjPAZ1.net]: VScodeがGo/HTML/JavaScript/Markdownと幅広いから、それだけで間に合っちゃうんだよな…
538 名前：デフォルトの名無しさん mailto:sage [2021/06/08(火) 23:18:45.50 ID:8Fr3CQSw.net]: 機能とかはともかく、ステータスバーをやたら占有するのは糞だな。
539 名前：デフォルトの名無しさん mailto:sage [2021/06/09(水) 01:01:33.46 ID:y3OB765l.net]: ステータスバーを占有、、、？
540 名前：デフォルトの名無しさん mailto:sage [2021/06/13(日) 22:15:56.68 ID:lkM0NMIG.net]: VagrantのRubyコードをGoでリライトする模様
541 名前：デフォルトの名無しさん mailto:sage [2021/06/13(日) 23:00:16.90 ID:exUpBE38.net]: ほう。Vagrantfileはどうするのかな。今だとYAMLとかになりそうな悪寒。
542 名前：デフォルトの名無しさん mailto:sage [2021/06/13(日) 23:12:30.98 ID:Nkflk8c7.net]: Vagrantとかまだ使ってる奴いるの？
Dockerでオワコンとか以前に、GoだとVMもコンテナもなしに生でも普通に動くようにポータブルに作るだろうし
543 名前：デフォルトの名無しさん mailto:sage [2021/06/13(日) 23:25:59.99 ID:exUpBE38.net]: 普通に、WindowsでVirtualBox使うならその環境構築にほぼセットだわ。
Goのアプリしか使わないわけでもないしな。
544 名前：デフォルトの名無しさん mailto:sage [2021/06/13(日) 23:41:09.94 ID:eXqVG9aT.net]: WSLかDockerでよくね
545 名前：デフォルトの名無しさん mailto:sage [2021/06/13(日) 23:43:18.70 ID:WJQpzq26.net]: >>530
まじ？！
546 名前：デフォルトの名無しさん mailto:sage [2021/06/14(月) 03:57:38.10 ID:WMzG+VdI.net]: https://www.hashicorp.com/blog/toward-vagrant-3-0
これだね
rubyは徐々にコアから切り離してオプション化していく感じかな
547 名前：デフォルトの名無しさん mailto:sage [2021/06/14(月) 04:16:45.90 ID:SZpJFTNw.net]: あらー
まあユーザーからしたらRuby入れるの面倒だったしな
548 名前：デフォルトの名無しさん mailto:sage [2021/06/14(月) 07:44:36.39 ID:6p9bp5Dj.net]: >>533
WSLで用が足りるならVirtualBox自体使う必要がないんだろうがな。
ただ、単にLinuxのソフトウェアが動けばいいんじゃなくてやっぱり仮想環境が必要な場面はあるし。
以前Ubuntuの複数バージョンを使い分けたりしたことがあるが、こういう用途にはまだ必要。
549 名前：デフォルトの名無しさん mailto:sage [2021/06/14(月) 07:45:52.08 ID:6p9bp5Dj.net]: リンク間違えた。>>538は>>534ね。
550 名前：デフォルトの名無しさん mailto:sage [2021/06/14(月) 11:59:12.37 ID:DpCafs9R.net]: goのcoroutineはgoroutineていうのに
goのcontextはgontextていわないのはなぜ？
551 名前：デフォルトの名無しさん mailto:sage [2021/06/14(月) 12:04:15.12 ID:ei9nXL3B.net]: goroutineはGo言語のルーチンじゃなくて予約語goで作られるroutineだからじゃね？
552 名前：デフォルトの名無しさん mailto:sage [2021/06/14(月) 12:23:24.79 ID:6p9bp5Dj.net]: そもそも goroutine は coroutine じゃなくて thread だから。
553 名前：デフォルトの名無しさん mailto:sage [2021/07/02(金) 14:46:02.08 ID:LpLK6KDw.net]: https://twitter.com/alexanderdanilo/status/1410521878855176194

Rob Pikeが引退ってマジか
(deleted an unsolicited ad)
554 名前：デフォルトの名無しさん mailto:sage [2021/08/01(日) 03:30:57.24 ID:8X1C7Oi5.net]: Goもようわからん方向に進んでますな
インフラ用言語と割り切ればええんかな
555 名前：デフォルトの名無しさん [2021/08/12(木) 01:08:37.12 ID:b4UG5w9l.net]: goで問題解くサイトみたいなのありますか？
556 名前：デフォルトの名無しさん mailto:sage [2021/08/12(木) 11:50:15.21 ID:s+UN3BdM.net]: 今は、WSL2, Docker, VSCode(Remote Container, WSL2 ならRemote WSL)で十分。
Mac, vagarant, virtual box さえ不要

Ruby on Rails では、Heroku, Cloud 9, CircleCI などのクラウド開発

ローカル開発なら、Dockerを使うのが簡単だが、
日本人が作った、バージョンマネージャーのanyenv で、rbenv, nodenv も使える。
asdf でも、多言語の好みのバージョンを入れられる

echo -e "$RBENV_ROOT\n$NODENV_ROOT"
/home/ユーザー名/.anyenv/envs/rbenv
/home/ユーザー名/.anyenv/envs/nodenv

任意のLinuxディストリビューションをWSL2で動かす　Clear Linux OSを動かすまで、2021/4
https://impsbl.hatena＠blog.jp/entry/ClearLinuxOnWSL2

注意。アク禁にならないように、URL 内に、＠を入れました

Docker Hub からpull したイメージを、tar へexport して、
それをWSLで、D ドライブへimport する

docker export
wsl --import

WSLでカスタマイズしたものを、さらにexport しておく。
wsl --export
557 名前：デフォルトの名無しさん [2021/08/14(土) 18:30:15.43 ID:1pPVCqqe.net]: ジェネリクスは入った？
558 名前：デフォルトの名無しさん mailto:sage [2021/08/17(火) 12:12:44.83 ID:uiypcFr0.net]: Go 1.17 is released!
https://twitter.com/golang/status/1427378613289164810
(deleted an unsolicited ad)
559 名前：デフォルトの名無しさん [2021/08/17(火) 17:56:17.55 ID:OnI2KERu.net]: >>541
goroutineって
オプションで複数のCPUコアに分散も出来るけど
実際はほぼ軽量スレッドじゃん？
コルーチンみたいなものじゃないの？

プログラムの書き方がスレッド使ったプログラムっぽかったら、
Goみたいに実装が極力OSスレッドに頼らないものになっててもスレッド（グリーンスレッド）？
560 名前：デフォルトの名無しさん mailto:sage [2021/08/17(火) 21:51:06.20 ID:082KifEP.net]: goroutineはstackful coroutine
561 名前：デフォルトの名無しさん [2021/08/21(土) 18:09:12.95 ID:7GAoG1Iq.net]: Rustのメモリ安全性はボローチェッカーによって担保されている

Nimバージョン：1.5.1でRustのボローチェッカーに似た「View types」が実装されれば、
GC無しでView types参照の有効性を検証することによってメモリ安全性を保証しつつ
限りなく抑え込まれたタイプ量で高速化したCのソースコードを吐き出せます

Nimソースコード ==nimコンパイラ==> Cソースコード ==Cコンパイラ==> バイナリ

なので、nimコンパイラが通った時点でメモリ安全性が担保されませんか？

Nimの実験的特徴
著者：アンドレアス・ルンプ
バージョン： 1.5.1
nim-lang.github.io/Nim/manual_experimental.html

Nimは限りなく抑え込まれたタイプ量で高い生産性とPythonのような高い可読性を実現し
ているにもかかわらず、Cのソースコードを吐き出せるので割り振られた仕事が早く終わっ
ても終わってないふりをして怠けることができる

「怠け者とはこうあるべきだ！」と言うとても大事な事を Nim は我々に教えてくれます
562 名前：デフォルトの名無しさん mailto:sage [2021/08/21(土) 18:16:54.48 ID:O7+p4qIy.net]: Rubyガイジに続いてNimガイジの登場？
563 名前：デフォルトの名無しさん [2021/08/22(日) 12:20:27.60 ID:0Cz6ueFz.net]: Rustのメモリ安全性はボローチェッカーによって担保されているが、
Nimと比較してRustはタイプ量が多い
564 名前：事により限りなく低い生産性と C++のような高い難読性、超巨大なバイナリ生成性能を兼ね備えています Nimはバージョン1.5.1でRustのボローチェッカーに似た「View types」が実装されれば、 GC無しのView typesで参照の有効性を検証することによってメモリ安全性を保証しつつ 限りなく抑え込まれたタイプ量で高速化したCのソースコードを吐き出せます Nimソースコード ==nimコンパイラ==> Cソースコード ==Cコンパイラ==> バイナリ なので、nimコンパイラが通った時点でメモリ安全性が担保されませんか？ Nimの実験的特徴バージョン1.5.1 http://nim-lang.github.io/Nim/manual_experimental.html 第二プログラミング言語として Rust はオススメしません Nim をやるのです https://wolfbash.hateblo.jp/entry/2017/07/30/193412 Nimは限りなく抑え込まれたタイプ量で高い生産性とPythonのような高い可読性を実現し ているにもかかわらず、高速なCのソースコードを吐き出せるのでC言語でリモートワーク されている方は割り振られた仕事が早く終わっても終わってないふりをして怠けることができる 「怠け者とはこうあるべきだ！」と言うとても大事な事を Nim は我々に教えてくれます []: [ここ壊れてます]
565 名前：デフォルトの名無しさん mailto:sage [2021/09/09(木) 23:03:13.52 ID:uQCXRnBV.net]: >>545
ttp://rosettacode.org/wiki/Category:Go
566 名前：デフォルトの名無しさん [2021/09/15(水) 01:01:00.82 ID:e45L6iVT.net]: 9月TIOBEプログラミング言語ランキング
https://news.mynavi.jp/article/20210913-1971335/
567 名前：デフォルトの名無しさん [2021/09/18(土) 17:33:40.58 ID:kYto5Bfg.net]: Go言語を嫌う6個の理由
https://www.kbaba1001.com/entry/2021/09/17/073149
568 名前：デフォルトの名無しさん mailto:sage [2021/09/18(土) 18:19:07.86 ID:ED687M4K.net]: まー、概ね間違ってもいないかな？
でもmapなどがループより優れてるっーのは感想にしか過ぎなくないか？
569 名前：デフォルトの名無しさん mailto:sage [2021/09/18(土) 19:44:16.34 ID:1qFQH5Bo.net]: 優れているかどうかはともかくmapとかは便利だよ
Genericsが導入されたらめっちゃ使われるようになるっしょ
570 名前：デフォルトの名無しさん mailto:sage [2021/09/18(土) 19:55:59.68 ID:ED687M4K.net]: 短く分かりにくいコードが書けて便利
571 名前：デフォルトの名無しさん [2021/09/18(土) 20:04:43.61 ID:VYLTl1id.net]: 総称によるイテレーションを伴うmap/reduceは他の言語みたいに単一スレッドの自己満足じゃなく
デフォルトで並列にして欲しいです。。。
572 名前：デフォルトの名無しさん mailto:sage [2021/09/18(土) 20:15:55.61 ID:9LlZohSd.net]: map/reduceが使われる殆どのケースでは、入力の振り分けや結果のマージ、コンテキストスイッチ等のコストのため、並列化するとかえって遅くなるんだよ
573 名前：デフォルトの名無しさん [2021/09/18(土) 20:27:06.45 ID:VYLTl1id.net]: うっせーうっせーうっせーわ、あなた思うよりmap/reduceに並列度引数付ければいいだけです！
デフォルトで言うてる文章も読めないアホはgolangのM:Nモデルの高速スイッチが分かってない
574 名前：デフォルトの名無しさん mailto:sage [2021/09/18(土) 20:33:23.01 ID:9LlZohSd.net]: だから「殆どのケースでは」って言ってるじゃん
デフォルトで並列なら確実に遅くなるよ
575 名前：デフォルトの名無しさん mailto:sage [2021/09/18(土) 20:39:09.73 ID:G1H8j0E2.net]: 駄々っ子には何を言ってもムダ
576 名前：デフォルトの名無しさん [2021/09/18(土) 21:09:31.39 ID:IxZBx6u4.net]: 気持ち悪い単発ID援護
577 名前：デフォルトの名無しさん mailto:sage [2021/09/18(土) 22:54:51.12 ID:em3js4pK.net]: その記事は肝心のポイントが一つ抜けておるな
goは何がクソといってまず名前がクソすぎる
40年50年前にできた言語じゃないんだからちゃんと後先考えて名前つけろや！
578 名前：デフォルトの名無しさん mailto:sage [2021/09/19(日) 12:53:46.33 ID:HwX1dH8g.net]: goの最大の問題は検索のしづらさだろねえ

Goのヘイト記事は外国でもある（そりゃそうだ）

Why Golang Is Bad for Smart Programmers
https://raevskymichail.medium.com/why-golang-bad-for-smart-programmers-4535fce4210c

I want off Mr. Golang's Wild Ride
https://fasterthanli.me/articles/i-want-off-mr-golangs-wild-ride

もっと強烈なのあったはずなんだけど見つかりませんでした
579 名前：デフォルトの名無しさん mailto:sage [2021/09/19(日) 13:03:36.46 ID:W3Ibxi5N.net]: でも悪評も評判のうちなんで
WebAPIとして最適な並列処理性能を持つとはいえ、なんでそんなに注目されるのか
極論言えばWebAPI作るくらいしか能はないよね
580 名前：デフォルトの名無しさん [2021/09/19(日) 14:20:10.51 ID:2JoXdmjo.net]: GoにGenericsが導入されるのは来年か、待ち遠しいなあ
581 名前：デフォルトの名無しさん mailto:sage [2021/09/19(日) 14:33:08.77 ID:kGPMuBj8.net]: ググラビリティなら同じ名前のゲームがあるRustより遥かにマシ
582 名前：デフォルトの名無しさん mailto:sage [2021/09/19(日) 14:42:11.42 ID:eLx8+R0U.net]: 最近だと SIMD命令への対応がうれしい(実装コードはこれからだけど)

cmd/go: add GOAMD64 environment variable
https://github.com/golang/go/commit/b1bedc0774d8a3a7ff8778e933ee92e8638e9493

Microarchitecture levels
https://en.wikipedia.org/wiki/X86-64#Microarchitecture_levels
583 名前：デフォルトの名無しさん [2021/09/21(火) 14:14:06.62 ID:QKlGGi7s.net]: Fuzz testing
584 名前：デフォルトの名無しさん [2021/09/21(火) 14:57:53.57 ID:ZVAhNDzz.net]: >>566
c って名前をつけた奴に無理な注文すんなｗ
585 名前：デフォルトの名無しさん mailto:sage [2021/09/21(火) 15:24:48.06 ID:YFZVt4Mm.net]: たまには D とか V のことも思い出してあげてください
586 名前：デフォルトの名無しさん mailto:sage [2021/09/21(火) 15:45:09.78 ID:VBMIAkoo.net]: >>573
Szl (Sawzall) っていう命名もできるのになあ
587 名前：デフォルトの名無しさん [2021/09/21(火) 16:21:52.65 ID:ZVAhNDzz.net]: >>567
> Why Golang Is Bad for Smart Programmers
> https://raevskymichail.medium.com/why-golang-bad-for-smart-programmers-4535fce4210c

読んだ
Cしかやったことない奴は騙せても
いろんな言語やってきた奴からしたらショボすぎるわな
あとどうでもいいけどDを引き合いに出してGo批判するって斬新だなｗ
588 名前：デフォルトの名無しさん mailto:sage [2021/09/21(火) 16:40:46.07 ID:VBMIAkoo.net]: D言語ちょっと試したことあるけどなかなか心地良かったよ。
しかしなぜGoやRustが使われて、Dが使われないのか、というな視点でも評価してほしいな。

「俺が考えた最強の言語」を作る人はいっぱいいても、ちゃんとコミュニティを作って使われるようになる言語はなかなかないね。
589 名前：デフォルトの名無しさん [2021/09/21(火) 16:52:12.16 ID:ZVAhNDzz.net]: >>577
> 「俺が考えた最強の言語」を作る人はいっぱいいても、ちゃんとコミュニティを作って使われるようになる言語はなかなかないね。

Perl6もフィボナッチ数列から最初の十個を出力を
say (1, 1, *+* ...*)[^10];
と簡潔に書けたりして最強言語だけど使われてないね
590 名前：デフォルトの名無しさん mailto:sage [2021/09/21(火) 17:19:40.36 ID:kwTaz7X0.net]: write only language として最強でもなぁ・・・
591 名前：デフォルトの名無しさん mailto:sage [2021/09/21(火) 17:32:46.95 ID:YFZVt4Mm.net]: >>578
そういやこの前「Perl6 は～」って話してたら「rakulang だ！」って怒られたわ
592 名前：デフォルトの名無しさん mailto:sage [2021/09/21(火) 18:08:02.89 ID:chSqlukK.net]: Goは、①普通にビルドできて、②普通にデプロイできて、③後々ゴミにならない
という当たり前の事が当たり前にできることに存在意義がある
簡単なことだけどそれができない言語が多いんだよね
593 名前：デフォルトの名無しさん [2021/09/22(水) 01:42:07.18 ID:l6mKxMvi.net]: ジェネリクスが入ればそこがまた飛躍の時
594 名前：デフォルトの名無しさん [2021/09/22(水) 08:18:04.28 ID:FHlooIbh.net]: 2021年にもなってジェネリクスを待ち望んでる言語があるとか
痛々しすぎん？
595 名前：デフォルトの名無しさん mailto:sage [2021/09/22(水) 09:14:59.43 ID:B3HpsGLJ.net]: いらん
と開発元も思ってたけど、おまえらがどうしても欲しいと言い続けたからだろ
596 名前：デフォルトの名無しさん [2021/09/22(水) 09:30:44.14 ID:FHlooIbh.net]: 言語をデザインした奴が最初の段階で要らんと言ってるなら
それを貫き通してほしいよね
馬鹿にいまさら迎合することなく

Javaにジェネリクスが入った時も同様の失望を覚えた
597 名前：デフォルトの名無しさん mailto:sage [2021/09/22(水) 09:47:34.93 ID:Z6AQmIPR.net]: 俺はジェネリクスが欲しいと思ったことはないなあ
sliceとmapに型があるから実際ほとんど十分なんだよね
598 名前：デフォルトの名無しさん [2021/09/22(水) 09:50:30.16 ID:SSzxu7sL.net]: システムプログラミングではいらんかもしれんけど業務アプリではないとつらい
599 名前：デフォルトの名無しさん mailto:sage [2021/09/22(水) 10:12:49.72 ID:B3HpsGLJ.net]: 言語デザイン的には業務アプリは考えてなかったけど、業務アプリでも使いたいという要望が広まってきて、その弊害というかなんというか
業務アプリにgoroutineはオーバースペックだし、JavaとかC#でいいと思うんだよな
600 名前：デフォルトの名無しさん mailto:sage [2021/09/22(水) 10:16:35.88 ID:B3HpsGLJ.net]: Goって、より良いCとして使うだけの利用者層は今はどれくらいのシェアなんだろ？
601 名前：デフォルトの名無しさん mailto:sage [2021/09/22(水) 10:54:15.71 ID:csq4xmc8.net]: Generics が入る時点で Go1 と Go2 に枝分かれするかと思ったけど
そうでもないみたいだな
602 名前：デフォルトの名無しさん mailto:sage [2021/09/22(水) 12:08:04.57 ID:rujUi/9T.net]: Genericsがないから、いまは代わりにコード生成でなんとかしてるんでしょ
コード生成ってメンテしづらいし面倒だよ
603 名前：デフォルトの名無しさん mailto:sage [2021/09/22(水) 12:08:24.30 ID:xw08ZBoX.net]: 型クラスがないジェネリクスとか片手落ちなんだよな
それに標準の型クラスもないのにどうやって共通性を持たせるんだろうとか
いろいろ無理な気がする
使いにくいから誰も使わないということになりそう
604 名前：デフォルトの名無しさん mailto:sage [2021/09/22(水) 12:23:07.31 ID:rujUi/9T.net]: >>589
Linux関連プロジェクトみたいに、既存関連リソースがC言語ばかりだとC使うんだろうけど、
しがらみのない新しいツールではCなんて滅多にないような？ほとんどGoかRustなのでは・・・？

シェアは全くわからんけど、おれの趣味寄りにもなるけど有名なのだと
Docker、Kubernetes関連、moby、HashiCorpのプロダクト、etcd、CockroachDB、InfluxDB、BoltDB、fzf、Hugo、frp、traefik

もしかしてこういう話じゃない？
605 名前：デフォルトの名無しさん mailto:sage [2021/09/22(水) 12:45:37.46 ID:rujUi/9T.net]: >>592
例えばこういうふうにすれば、共通の演算子である+を使えたりするけど、これじゃダメ？
https://go2goplay.golang.org/p/hYqlmKON7VE
606 名前：デフォルトの名無しさん mailto:sage [2021/09/23(木) 00:48:02.08 ID:wxnnur2v.net]: はよGenerics使わせろ
607 名前：デフォルトの名無しさん mailto:sage [2021/09/23(木) 01:09:42.88 ID:5iThOVVW.net]: >>595
WIP ブランチなら既にデフォルトで -gcflags=-G=3 になってる
gopls も対応したので Emacs + Eglot でサクサク書いてる
608 名前：デフォルトの名無しさん mailto:sage [2021/09/23(木) 19:28:09.42 ID:wxnnur2v.net]: おお、いいね
609 名前：デフォルトの名無しさん [2021/09/24(金) 07:59:47.34 ID:ljIO2QUf.net]: https://i.imgur.com/z2Aqpr0.png
610 名前：デフォルトの名無しさん mailto:sage [2021/09/27(月) 07:44:16.84 ID:lxaeA1bT.net]: TVCM見てて Go Pay が出てきて吹いたわ
なんなの提供元
ポケモンGoに勝てるの？
GO TO トラベルに勝てるの？
Google Pay に勝てるの？
それも調べたら MOV Pay から名称変更とか、そこまで逆境が欲しいの？
山中幸盛なの？
611 名前：デフォルトの名無しさん mailto:sage [2021/09/27(月) 09:06:27.80 ID:lxaeA1bT.net]: 書かなくても分かると思ったけど一応、サービス内容に対しての話じゃないからね
ググラビリティの話

Go が後続のサービスにどれだけ苦しめられてるのか
任天堂やら日本国政府やらGoogleやらのパワープレイヤーなら知ったこっちゃないだろうけど、泡沫勢力じゃ約束されし絶望じゃん
612 名前：デフォルトの名無しさん mailto:sage [2021/09/27(月) 13:53:26.84 ID:LxdgSnnl.net]: ググラビリティって普通GolangかGo言語で検索すんじゃねーの？
Cとかでどうやってんの？
613 名前：デフォルトの名無しさん mailto:sage [2021/09/27(月) 13:56:04.08 ID:stBORJeg.net]: 親会社名自体が猛烈に低ググラビリティという…
614 名前：デフォルトの名無しさん mailto:sage [2021/09/27(月) 14:52:06.48 ID:Z8J42Gkb.net]: >>599
どうした急に
お薬飲め
615 名前：デフォルトの名無しさん mailto:sage [2021/09/27(月) 15:05:56.76 ID:lxaeA1bT.net]: >>603
>>600
書かなくても……書いといて良かったわ
616 名前：デフォルトの名無しさん mailto:sage [2021/09/27(月) 15:19:55.68 ID:tsIS/8pJ.net]: 検索ワードで回避できる問題なんかどうでもいい
一般人が検索するような物でも無いし
コマンドが短く入力しやすい方が重要
squirrelみたいな名前にしたら腱鞘炎になるぞ
617 名前：デフォルトの名無しさん mailto:sage [2021/09/27(月) 17:54:21.16 ID:Ac+aBfL/.net]: >>601
C言語
618 名前：デフォルトの名無しさん mailto:sage [2021/09/28(火) 08:06:03.36 ID:zmriYPIE.net]: 極主夫道の二巻の福引きGo等の商品がどうみてもGopher君のパチモノ
619 名前：デフォルトの名無しさん [2021/09/29(水) 15:30:15.59 ID:W9rNFdvq.net]: 見上げてGolang、夜の星を
620 名前：デフォルトの名無しさん mailto:sage [2021/10/18(月) 13:29:08.84 ID:tOAzdfyW.net]: Go簡単って言うからやってみたらローカルファイルimportするのに相対パス使えないとか
go mod するんだとかGOPATHはもう使わないとかｺﾞﾁｬｺﾞﾁｬｺﾞﾁｬｺﾞﾁｬ・・なんじゃこれ？全然シンプルじゃない
ツール周りがゴチャりすぎやろ、やっぱPythonが神だわ
621 名前：デフォルトの名無しさん mailto:sage [2021/10/18(月) 13:40:38.36 ID:+iNX7XVA.net]: そうですね。Python使った方が良いと思いますよ。さようなら
622 名前：デフォルトの名無しさん mailto:sage [2021/10/18(月) 19:24:50.47 ID:vvHfCZ9q.net]: まあ相対パス使えないのはやり過ぎな気もする
htmlですらbaseを指定できるのに、何を恐れているのか
パーサーを作る際に楽だからなのかな？
623 名前：デフォルトの名無しさん mailto:sage [2021/10/18(月) 21:26:33.48 ID:w/yRHxqY.net]: え？ go.mod で replace しておけばいいんじゃない？
624 名前：デフォルトの名無しさん [2021/10/27(水) 21:55:02.42 ID:HQ60ALa2.net]: Sum Type、Union elementあと4か月か…2月/8月
625 名前：デフォルトの名無しさん mailto:sage [2021/10/27(水) 22:05:51.76 ID:HL6HkAZF.net]: Genericsは1.18に載らないの？
626 名前：デフォルトの名無しさん mailto:sage [2021/10/27(水) 22:49:21.67 ID:Dm8DTcKu.net]: 既に WIP ブランチでは使える様になっているから 1.18 で
正式採用になると思う(gopls も対応済み)
627 名前：デフォルトの名無しさん mailto:sage [2021/10/31(日) 15:45:47.64 ID:Qz/5KmYR.net]: ついにGenerics載るんだね、楽しみやなー。

ところで、ユーザ定義演算子は計画されてない？
AddとかMulみたいなメソッドじゃなくて+とか*みたいな演算子使いたいこともあるんよね
628 名前：デフォルトの名無しさん mailto:sage [2021/10/31(日) 18:46:09.19 ID:OY4TDGUi.net]: >>616
>>594みたいな書き方しか無理みたい
トホホ
629 名前：デフォルトの名無しさん mailto:sage [2021/11/01(月) 23:46:42.69 ID:jfjYB5Nx.net]: GOおもろない
なんとかしてや
630 名前：デフォルトの名無しさん [2021/11/02(火) 14:39:41.99 ID:vRCKOPQ3.net]: >>618
どこがどうおもろないんや？
631 名前：デフォルトの名無しさん mailto:sage [2021/11/02(火) 21:14:20.28 ID:c4MpaWiz.net]: 仕事だから仕方なく使ってるのはあるな
632 名前：デフォルトの名無しさん [2021/11/03(水) 08:59:07.96 ID:owwwLqi1.net]: なんも知らん新人でも、できるベテラン・新人でも、仕事に使うにはソースコードに均一性のある良い言語だわいな
633 名前：デフォルトの名無しさん mailto:sage [2021/11/03(水) 09:11:16.68 ID:hIbM46+W.net]: 最近Goの現場入ったけど
dep?とかいうモジュール使っててGOPATHにも気を使わないと駄目で
結構混乱する
初期で大分失敗してると思うわGo
634 名前：デフォルトの名無しさん [2021/11/03(水) 10:49:56.25 ID:I/oot80l.net]: depは3年ぐらい前から正式な公式ツールじゃもう無いし、ツールの煩雑性や使い勝手は言語に関係ないよ
PATH変数に気を使うのはC,C++でも一緒、そもそも環境構築すら出来ない失敗をしてんのはあんたか
現場の手順書が無いか
635 名前：デフォルトの名無しさん mailto:sage [2021/11/03(水) 11:46:43.90 ID:XfZZ+0lv.net]: 「改訂2版みんなのGo言語」という本を読めば？

学生時代に、Ruby 製のVagrant を作って、
Terraform で有名なHashiCorp を作った、今世紀最大の起業家、
Ruby/Go の神、Mitchell Hashimoto のソースコードも解説している
636 名前：デフォルトの名無しさん mailto:sage [2021/11/03(水) 12:11:59.17 ID:508Y0Igq.net]: go.mod に書いとくだけで github やらから直接にライブラリを導入できる点で、環境面では目一杯助かってるわ
Mavenやらpipが組み込まれてる感じだけど、基本機能であることは大きい
Mavenとかpipは別途入れないとならんし、それぞれ本体と別の環境整備しないとならないから
637 名前：デフォルトの名無しさん mailto:sage [2021/11/03(水) 19:24:54.92 ID:ywwxM/TS.net]: >>622
今更？
638 名前：デフォルトの名無しさん mailto:sage [2021/11/04(木) 16:01:17.99 ID:eo9m+3ij.net]: 趣味で使って面白い?
639 名前：デフォルトの名無しさん mailto:sage [2021/11/04(木) 16:13:12.12 ID:5gkz3BSt.net]: 面白い
GCP無料枠でそこそこ実用性のあるサイト建てたりできるし
640 名前：デフォルトの名無しさん mailto:sage [2021/11/04(木) 16:27:08.12 ID:eo9m+3ij.net]: なるほど
googleの犬になるか
641 名前：デフォルトの名無しさん mailto:sage [2021/11/04(木) 19:21:19.80 ID:5gkz3BSt.net]: だってアマとか無料枠ないんだもん
一年目だけってのは、単に初回サービスって言うんだよ
642 名前：デフォルトの名無しさん [2021/11/05(金) 14:20:53.38 ID:0z+NMKpK.net]: Herokuとか
643 名前：デフォルトの名無しさん mailto:sage [2021/11/07(日) 15:35:29.83 ID:mQ9A5wfK.net]: 社会人なら別にEC2使ってもマイナーサービスのサーバ台ぐらい余裕やで。
一ヶ月分の料金なんて、スタバ2回分くらいだろ。

そら安いほうがいいけど。
644 名前：デフォルトの名無しさん mailto:sage [2021/11/07(日) 22:23:20.41 ID:aZyVG3bY.net]: micro使えば安いけど明らかにメモリが足りないんだよな
おまけに調子に乗ってぶん回すと詰まるし
最低でもmedium程度は欲しいがそうなると結構高くなる
645 名前：デフォルトの名無しさん mailto:sage [2021/11/07(日) 22:38:38.82 ID:VzSbYdr/.net]: Oracle Cloudは？
コンソールが重くて独自性強いけど起動してしまえばいっしょ
646 名前：デフォルトの名無しさん mailto:sage [2021/11/07(日) 23:41:21.11 ID:KgxySftM.net]: サイト立ててもアクセスが日に数件なんでほとんどマシン回ってないやww
647 名前：デフォルトの名無しさん [2021/11/08(月) 16:12:42.92 ID:KvpLYeV7.net]: microといえば思い出す、大手のNでスワップしまくりなんも考えてないSEが手配したmicro
しかもWindowsの時の絶望感・・・
648 名前：デフォルトの名無しさん mailto:sage [2021/11/08(月) 16:32:31.04 ID:Qfm8QX8G.net]: んなもん動くか！

とググったら
https://qiita.com/zakky/items/68c4749889717c3cd849
おぅい！！
649 名前：デフォルトの名無しさん mailto:sage [2021/11/08(月) 16:42:16.76 ID:NUVpgUuA.net]: microでも小さいサービスならメモリ足りるやろ？ goだったら100MBメモリ食うこともありえないくらいやろ
メモリリークでもしてるんじゃないの？
Windowsとか動かしたらそらきついだろうけど。
650 名前：デフォルトの名無しさん mailto:sage [2021/11/08(月) 17:40:06.67 ID:Qfm8QX8G.net]: 動くか、と言ったのはWindowsの話
400MB確保できるみたいだから意外と使えるかも？
651 名前：デフォルトの名無しさん mailto:sage [2021/11/08(月) 18:00:09.69 ID:NUVpgUuA.net]: なんでそんなにWindowsを動かしたいんだ・・・。
652 名前：デフォルトの名無しさん mailto:sage [2021/11/09(火) 13:54:21.34 ID:dGlVH92+.net]: >>640
pインスタンスでwindowsを動かすのは普通に多いよ
653 名前：デフォルトの名無しさん mailto:sage [2021/11/09(火) 17:10:56.19 ID:8qmTEk8+.net]: いや、なんで？という疑問への答えじゃないよな
ぶっちゃけLinuxでSSH接続専用にすれば済むから
654 名前：デフォルトの名無しさん mailto:sage [2021/11/09(火) 19:48:05.88 ID:+FOj3uk2.net]: GUI系のアプリを動かすんだよ
CAD系のシミュレータとか
windowsにしか存在してないアプリが多い
655 名前：デフォルトの名無しさん [2021/11/09(火) 23:41:06.97 ID:5nP8kmAz.net]: github.com/fogleman/gg が遅くてちょっと困った。
Webassemblyで普通にcanvasの関数をcallした方が速いなんて。
ebitenはdraw系の関数少ないからなぁ。
656 名前：デフォルトの名無しさん [2021/11/11(木) 09:52:59.41 ID:zPNWYi1t.net]: Twelve Years of Go
Russ Cox, for the Go team
10 November 2021
657 名前：デフォルトの名無しさん [2021/11/17(水) 23:16:51.89 ID:a+84vLf4.net]: gotoの使用は許可されてる？
658 名前：デフォルトの名無しさん mailto:sage [2021/11/18(木) 06:41:13.91 ID:eOo002y1.net]: >>646
普通は使わないが何故か仕様にあるんだから許可されてるんだろ
659 名前：デフォルトの名無しさん [2021/11/18(木) 17:38:26.56 ID:kJKbHvZv.net]: 深いループを抜けるときはgotoを使う
660 名前：デフォルトの名無しさん mailto:sage [2021/11/18(木) 21:15:03.90 ID:iWaFftPG.net]: ラベルgotoは、gotoではあっても古い言語で禁忌されているgotoではありません。

ダイクストラのgoto文論争はBASICはもちろんですが、1968年に“Go To Statement Considered Harmful”
（Go To 文は有害とみなされる）において行番号へ飛ぶような言語が多かったために起こった論争です。
C言語も古くからありましたが、こちらもあまり使われなくなりました。なによりもgoto以前に
setjmp, longjmpという、関数の間でのジャンプ出来るようなC標準ライブラリが存在したために
より強く禁忌されたといえるでしょう。のちにStructured ProgrammingからO-OProgrammingへ移り変わる
につれて行番号は何もなく、文の構造の厳格性や動的ディスパッチなどが整備されたため、必要性が薄れました。

現在あるラベルgotoとは、ループの中に飛び込むgotoなどではなく、二重のループ中のbreakなどで
脱出経路を明確化するなど、例えばコンピュータサイエンスの分野ではHaskellにおいてはモナドを利用して
例外や非決定性計算行うなど、引数付きgotoとも呼ばれる。
661 名前：デフォルトの名無しさん mailto:sage [2021/11/19(金) 09:01:28.58 ID:Fh4InTPD.net]: Inline指定出来ないので関数呼び出しのコスト低減くらいしか用途が思いつかない
そこまでシビアな実装滅多に無いから基本的に使わない
662 名前：デフォルトの名無しさん mailto:sage [2021/11/19(金) 12:21:28.19 ID:WNpWqDaH.net]: 確かに関数化すりゃブロック脱出もシンプルにreturnさせりゃいい
となるとgotoは関数呼び出しによるオーバーヘッドの削減だけなのかな？
ナノ秒単位でも削減したいという余程のシビアな要件で使うって話になるけど、関数呼び出しごとにスタックのチェックが入るGoでそんな要件に意味ってあるの？とも思う
663 名前：デフォルトの名無しさん mailto:sage [2021/11/19(金) 12:34:26.60 ID:kQNnUQCo.net]: というよりもアホ意識高いgoto異端審問官が、文句つけてくるので使わない。
664 名前：デフォルトの名無しさん mailto:sage [2021/11/19(金) 15:43:47.01 ID:oZVaazpx.net]: おれにとっては、Golangでgoto使うのは、構文解析器みたいなのを書くときにたまにあるんだけど、共通の処理までジャンプしたいときとか、
for文とかをネストしたときに、いくつか上のブロックまでジャンプしたいときかなあ。これも構文解析したあとの評価器で使うこともある気がする

ようするに最適化とかじゃなくて、ちょっとした大域脱出みたいなノリで使ってる

Go本体のソースコードでもこんな感じgoto使ってるんじゃなかったっけ
665 名前：デフォルトの名無しさん mailto:sage [2021/11/20(土) 11:05:39.09 ID:GriTsYN5.net]: 俺たちのGO！
666 名前：デフォルトの名無しさん [2021/11/21(日) 07:26:46.41 ID:8Zd5Z9wI.net]: IDEはどれがおすすめ？
667 名前：デフォルトの名無しさん mailto:sage [2021/11/21(日) 07:39:21.64 ID:AMP8EKz2.net]: 自分はVSCode
668 名前：デフォルトの名無しさん mailto:sage [2021/11/21(日) 23:14:16.37 ID:1+FhODzH.net]: 私はEmacs
669 名前：デフォルトの名無しさん [2021/11/22(月) 06:12:39.00 ID:I9kdAR+e.net]: VSCodeもemacsもIDEではないけどね
670 名前：デフォルトの名無しさん mailto:sage [2021/11/22(月) 07:05:20.26 ID:rahxNjIR.net]: バージョン管理からテストまで環境内で完結してるのに仲間外れなのか
671 名前：デフォルトの名無しさん mailto:sage [2021/11/22(月) 19:08:36.54 ID:uiCHuC7N.net]: emacsは"環境"だから、
emacs > IDE
だよな

ところでIDEの定義って何よ？
高機能エディタと垣根がなくなってきたからそれらを区別する意味があるのかどうか
672 名前：デフォルトの名無しさん mailto:sage [2021/11/22(月) 19:28:29.86 ID:rahxNjIR.net]: 統合開発環境だから、コンパイルからデバッグ、バージョン管理にデプロイまで揃ってるemacsとかVScodeを入れないとなると、いよいようろんな定義になる
RADとかグラフィカルな開発環境とごっちゃになってるのでは？
673 名前：デフォルトの名無しさん mailto:sage [2021/11/22(月) 19:36:29.51 ID:rahxNjIR.net]: エディタ内でデバッガと密接に連携(ブレークポイント設置して値を参照とか)できれば統合してると言ってもいいと思うんだが
674 名前：デフォルトの名無しさん mailto:sage [2021/11/23(火) 10:50:24.50 ID:YlZvZbei.net]: mapをrangeステートメントで処理すると毎回順番変わるのな
将来mapの実装を変えた時に要素の順番が変わっても大丈夫なようにあえてランダムにしてるらしい
最初知らなくて嵌った

しかもランダムに返す仕様の方がパフォーマンスをよくしやすいらしい
ensure better balancingって
なるべく偏らないように要素を配置するみたいな意味か

https://stackoverflow.com/questions/55925822/why-are-iterations-over-maps-random/55925880#55925880
675 名前：デフォルトの名無しさん mailto:sage [2021/11/23(火) 11:47:46.83 ID:RPYITf6H.net]: > ランダムに返す仕様の方がパフォーマンスをよくしやすい
いや流石にそんなことはないぞ
処理系の実装変更だけでなくマシン毎に結果が違うことも許容することで、パフォーマンス最適化の余地が広がるという意味だ
676 名前：デフォルトの名無しさん [2021/11/25(木) 20:43:12.75 ID:0woLMmPf.net]: 11月TIOBEプログラミング言語人気ランキング、PHPの下落続く
https://news.mynavi.jp/article/20211109-2181586/
677 名前：デフォルトの名無しさん [2021/11/26(金) 17:11:22.22 ID:xw//vI58.net]: Golangが一番書きやすい
678 名前：デフォルトの名無しさん mailto:sage [2021/11/26(金) 19:19:32.54 ID:TC631CUh.net]: go と defer とチャネルが便利すぎるね
チャネルのキャパシティは未だに悩む
679 名前：デフォルトの名無しさん mailto:sage [2021/11/26(金) 19:31:07.75 ID:jCnjnABk.net]: チャネルはクソだろ
Cでいうポインタ関連のミスによる死と同程度くらいにはデッドロックを起こしやすい極めて危険な仕組み
680 名前：デフォルトの名無しさん mailto:sage [2021/11/26(金) 19:33:40.57 ID:klqHYhKv.net]: 勉強中でよくわかってないんだけど
メインルーチンが死んだらゴルーチンもチャンネルも死ぬんじゃないの？
681 名前：デフォルトの名無しさん mailto:sage [2021/11/26(金) 19:53:34.58 ID:TC631CUh.net]: デッドロックは一番の可能性としてキャパシティを疑う
682 名前：デフォルトの名無しさん mailto:sage [2021/11/26(金) 21:43:15.55 ID:vur9wleR.net]: どんな言語でもスレッドやルーチェンの１つが落ちて無事平穏な言語は少ない。Erlangぐらいかな落ちる前提なのは
683 名前：デフォルトの名無しさん mailto:sage [2021/11/26(金) 22:02:31.09 ID:v7cZYF1p.net]: もう新しいデータ来ないのに
私待つわ…いつまでも待つわ…と待ち続けるコードを書けば
当然ながら詰まる
684 名前：デフォルトの名無しさん mailto:sage [2021/11/26(金) 22:32:30.29 ID:gRCMakca.net]: アミン…大統領
685 名前：デフォルトの名無しさん mailto:sage [2021/11/26(金) 22:54:09.91 ID:b/zo5EjW.net]: 未使用の変数がコンパイルエラーになるのは地味に良い
686 名前：デフォルトの名無しさん mailto:sage [2021/11/27(土) 15:33:06.29 ID:DHp3ezKZ.net]: 俺もチャネルはどうかと思う
ある意味スレッドより危険
687 名前：デフォルトの名無しさん mailto:sage [2021/11/27(土) 15:56:47.57 ID:wymfOW3B.net]: 設計間違えたらデッドロックするのはどんな通信でも一緒じゃね？
チャネルを殊更に危険視するの？
688 名前：デフォルトの名無しさん mailto:sage [2021/11/27(土) 16:07:17.64 ID:z8jcIZfA.net]: >>676
デッドロックしやすい仕様なのは事実だし、危険だからといってその使用を回避できる標準的な代替手段が存在しない
他の言語ではだいたいpromise/future、fork-join、actorがあるからよほど変なことしなきゃデッドロックなんか滅多に起きないよ
689 名前：デフォルトの名無しさん mailto:sage [2021/11/27(土) 16:10:29.89 ID:EtwFQg7M.net]: そうなんだ？　イケてないの？
Googleさんはなんでそんな方式を採用してしまったのやら
690 名前：デフォルトの名無しさん mailto:sage [2021/11/27(土) 16:43:12.87 ID:z8jcIZfA.net]: >>678
デザインパターンみたいなものを極力廃して、小さな標準的なツールセットだけでモノ作れるようにするという思想は一貫している
しかしスレッド関連のデザインパターンというのは基本的に死なないためにあえて制約を設けているのであって、
Goの思想が逆に敷居を高くする方向に作用してしまったということだ
691 名前：デフォルトの名無しさん mailto:sage [2021/11/27(土) 16:49:44.44 ID:kX7QbhiL.net]: CSPモデルに沿った実装がしやすいとは聞く。
CSPモデルができていればそれがデッドロックを起こすかどうか静的に検証できるはず。
692 名前：デフォルトの名無しさん mailto:sage [2021/11/27(土) 16:50:07.92 ID:Xzfp/9Y9.net]: ほえー、そうなんだ
実際のところ、他の人がgoroutineとか使ったやつを -race 付きで実行すると警告出まくるやつばっかだったよ

Goの強みは並行処理だと思ってたのに、他の言語のことはよく知らんけどもそんな有様じゃ強みだなんて言えないなあ
693 名前：681 mailto:sage [2021/11/27(土) 16:53:59.99 ID:Xzfp/9Y9.net]: なんかID変わっちゃってたけど、おれは >>678 ね
>>679 に向けて返信した
694 名前：デフォルトの名無しさん mailto:sage [2021/11/27(土) 17:22:55.75 ID:1Qfj4fkw.net]: CSPモデル
ttp://www.usingcsp.com/cspbook.pdf
695 名前：681 mailto:sage [2021/11/27(土) 18:04:43.03 ID:Xzfp/9Y9.net]: すまん、せっかくCSPを紹介してくれるなら、もっと初心者向けのやつない？
興味はある
696 名前：デフォルトの名無しさん mailto:sage [2021/11/27(土) 18:14:49.72 ID:kX7QbhiL.net]: これとか。
https://staff.aist.go.jp/y-isobe/topse/vic/slides/csp-isobe-2012-03.pdf
697 名前：デフォルトの名無しさん mailto:sage [2021/11/27(土) 18:28:08.91 ID:NTle55ol.net]: >>678
ここに玉にディスりにくるRust坊、ほんと性格悪いな
698 名前：デフォルトの名無しさん mailto:sage [2021/11/27(土) 19:03:33.53 ID:NTle55ol.net]: 設計が間違えてチャネルで無限ブロックするならタイムアウトをつけるべきだし、Rustもチャネルで
無限ブロックするしほかの多くの言語も（スレッド）チャネルの受信でブロックする
チャネルとは違うがErlangメッセージパッシングだって似たようなもの
699 名前：デフォルトの名無しさん mailto:sage [2021/11/27(土) 19:14:15.48 ID:z8jcIZfA.net]: >>687
そういうことを言ってるんじゃないのよ
>>677にも書いたけど標準的な安全な代替手段が存在しないことが問題
700 名前：デフォルトの名無しさん mailto:sage [2021/11/27(土) 19:53:13.18 ID:wymfOW3B.net]: Rustなんてスレッド実装が固まってから五年も経ってないお子ちゃま
701 名前：デフォルトの名無しさん mailto:sage [2021/11/27(土) 19:53:53.46 ID:DHp3ezKZ.net]: スレッドとかだとバッドパーツが一通り手間揃ってて
こういうのはやめましょうってのがほぼデザインパターン化されてるから
コードレビューでつぶせたり
処理を追うとわかったりする
702 名前：デフォルトの名無しさん mailto:sage [2021/11/27(土) 19:54:52.94 ID:LVgG7qhW.net]: >>683,685
CSPモデルのasync/awaitに対する優位性って何？
見た目何もない気がするが。
(ちなJSではなくC#のスレッドプールに対するasync/await想定でよろしく)
703 名前：デフォルトの名無しさん mailto:sage [2021/11/27(土) 20:00:12.03 ID:kX7QbhiL.net]: もともと危険なthread/mutexには安全なwrapperがあるのにgoのchannelにはそれが無いから、ってことかな？
704 名前：デフォルトの名無しさん mailto:sage [2021/11/27(土) 20:12:14.69 ID:K1RL10E4.net]: >>688
平行性のある現代的なプログラミング言語ではデットロックは言語仕様の問題ではなく、食事する哲学者の問題と
同じく制限された個数のチャネルで送られたデータが受け取られていないのに、送信できるようにはなりません。

これがレース競合を起こさないための標準的で安全な手段であり、グローバル変数や変数共有をgoroutine介して
同期ミューテックスもない操作すれば当然警告が出るでしょう。

そもそもgoroutineでのチャネルブロックはデットロックではなく、待機ブロックです。その証拠にSIGINTなどの
シグナルでは待機ブロックでも抜けるはずです。本来のデットロックなら応答しないかゾンビになります
もちろんスレッド（あるいは軽量スレッド）間でチャネルを介してのみデータを共有できるプログラミング言語も
存在しますが、goは親スコープにある変数などを操作できるように利便性のトレードオフ設計であり、より現実�
705 名前：Iで 効率的だとも言えるでしょう また制限された個数でないチャネルの場合は送信に受信側処理速度が追い付かない場合、キューイングされて 無限にメモリーが圧迫される危険性があります。 非同期系の言語で使用されるpromiseや、未来値のプレスホルダーを参照するfutureでデットロックが起きないのは 当たり前です。前者は非同期であり並列/並行ではありません、後者は終了時まで待って値を受け渡すだけです。 fork-joinは何が言いたいのかわかりません、actorプログラミングモデルや純関数言語ならその通りですが 共有したいデータが多くの言語でチャネルやパッシングを介してのみなので競合は起こらないでしょうが いつまで待っても到着しない受信側は、永遠に待ち続けるのは変わりません。 「そういう事をいってるんじゃない」 ま、こういう問題を一切合切、無難に解決してくれる標準的な手段を手続き言語に求めるのは分からなくも ないですが、最終的にデットロック（あるいは待機ブロックで無限待ち）したらどうするか記述するような フォールトトレラント処理が欲しいわけでもないのでしょうが、個数が限られている場合のレース競合対策の ルールなので言語的ではなく、哲学的にどうにもならないと思いますが []: [ここ壊れてます]
706 名前：デフォルトの名無しさん mailto:sage [2021/11/27(土) 20:52:19.87 ID:DHp3ezKZ.net]: >>693
何も分かってないなら書き込むなよ
707 名前：デフォルトの名無しさん mailto:sage [2021/11/27(土) 21:01:18.61 ID:LVgG7qhW.net]: >>693
それお前が今書いたん？
ググってもヒットしないが、そうとも思えないから原典があるのならそっちのURLくれ。

横だが「そういうことを言ってるんじゃないのよ」ってのは、単に、
生でスレッド処理を弄らせてデッドロックの危険を避ける色々な仕掛けを正しく準備しろ、というのなら、
フレームワーク等でその辺の仕掛けを全部用意してしまって、その上でジョブをキューイング出来るようにするだけの方が
処理性能も同じで手間がかからない分だけ合理的だろ、という話だよ。

Web系でSessionや認証周りは全部フレームワークに丸投げするべき、と言われているのと同じ。
スレッド周りでどうせ色々やらないといけないなら、最初からフレームワークに丸投げした方が合理的なんだよ。
だから、レイヤーが低い記述が出来るのなら、その手間に見合うだけの価値がないと意味無いんだけど、それがないでしょ、って話。
平行並列周りの研究をしてていじくり回したいだけの人＝そのプログラムがその時動けばいいだけの人
にとっては言語が直接サポートしてるのは便利だけど、
製品としてガッツリ動かす為には結局色々全部必要なら、職業プログラマにとってはまるで意味無いよね、という話。
708 名前：デフォルトの名無しさん mailto:sage [2021/11/27(土) 21:15:45.01 ID:w2+KtZN6.net]: >>691
静的に検証ができるっとことだろうな
709 名前：デフォルトの名無しさん mailto:sage [2021/11/27(土) 21:26:58.69 ID:LVgG7qhW.net]: >>696
何の検証？デッドロック？
async/awaitはデッドロックはしないぞ。
(永遠にジョブが終わらずに待たされてるように見えるだけ。メインスレッドは動き続けるし、GUIも動く)
710 名前：デフォルトの名無しさん mailto:sage [2021/11/27(土) 21:42:40.45 ID:bJFd+1Ko.net]: 一生懸命にRust坊が荒らしてるｗｗ
711 名前：デフォルトの名無しさん mailto:sage [2021/11/27(土) 22:37:45.64 ID:Cem9Q3+A.net]: いやこれはMSのC#おじさんだね、チャネルの話ならまだ良いがGolangの設計にありえないasync/awaitとフレームワークを交えながら意味不明なことを呟き続ける。
普通にデッドロックするしフレームワークってなんやねん（笑）Web系なんて共有すべきデータが無いんだからシコシコ糞コード書いてろよ？
おまえの競争相手はJavaとかPHPとかRailsだから、そっちに噛みついてこい、C#なのかRustなのかどうでも良いけど頭おかしいことは確か
712 名前：デフォルトの名無しさん mailto:sage [2021/11/27(土) 22:51:09.81 ID:w2+KtZN6.net]: >>697
そういう意味ではモデルの記述力か。
async/awaitは動作モデルを単純化することで安全性を保証できるようになったけど
食事する哲学者問題みたいなものを記述することができない。
713 名前：デフォルトの名無しさん mailto:sage [2021/11/27(土) 22:58:09.67 ID:AWnsIzD4.net]: async/awaitみたいな使い方ができないのはヤダヤダってことなんだろうな
714 名前：デフォルトの名無しさん mailto:sage [2021/11/27(土) 23:25:17.01 ID:Oiaj8YVV.net]: >>688
どの手段も場合毎に安全では無いし、それ故に画一的な標準的手段にはなり得ないから、それだけバリエーションがあるんよ。
Goはそのあたり多様性をネグって「こういう場合はこういう事に気をつけようねぇ！！」という脳筋的解決を図ってるの。
愚直だけどシンプルよ。
715 名前：デフォルトの名無しさん mailto:sage [2021/11/27(土) 23:26:48.32 ID:Oiaj8YVV.net]: Taskをスレッドプール使ってやりくりするより、はるかに早いんよな…goroutine。
716 名前：デフォルトの名無しさん mailto:sage [2021/11/27(土) 23:31:12.50 ID:B7MvCGlK.net]: 若い人にC#じゃなくてGoにしましょう言われたんかな？可哀想だから代替えとしてこういうのもありますよ
https://hackernoon.com/asyncawait-in-golang-an-introductory-guide-ol1e34sg
https://github.com/Joker666/AsyncGoDemo
https://github.com/StudioSol/async
717 名前：デフォルトの名無しさん mailto:sage [2021/11/27(土) 23:40:22.05 ID:jawpS72C.net]: >>704
お、こういう情報の提供はありがたい。
718 名前：デフォルトの名無しさん mailto:sage [2021/11/28(日) 00:00:58.18 ID:s59YsBRT.net]: むしろ定年間際な俺みたいなCで育った奴の方にウケてないのか？
719 名前：681 mailto:sage [2021/11/28(日) 00:22:11.00 ID:Z9Xk/5kf.net]: Go以外の並行処理のことはよくしらんけど、「Go言語による並行処理」を一通り読んでからは、並行処理でバグることへったよ
他の並行処理モデルだともっとうまいこといけるんか？
720 名前：デフォルトの名無しさん mailto:sage [2021/11/28(日) 07:47:32.52 ID:s59YsBRT.net]: 別の言語じゃ主にメモリを共有して排他処理して使ってる
ガバガバだけどミスには寛容なのでわりかし安心ではある
Goでもガバガバにキャパシティ増やしとけばそんなにデッドロックしないと思うんだけど
デフォルトだと一個でもキューされてると次の送信がwaitになる優しくない仕様を問題視してるんじゃないかな？
721 名前：デフォルトの名無しさん mailto:sage [2021/11/28(日) 08:51:48.67 ID:Abxhe3pm.net]: >>700
> 食事する哲学者問題
これを記述出来たとして、何が嬉しいんだ？

並列は結局のところ、処理能力の増大を目指してる。
シングルスレッドに無限大の処理能力があれば、誰も並列なんて使わない。
現実的にはこれはないから、様々な方策を用いて何とかするわけだ。

そこで、ジョブを他CPUに投げれれば事足りますね、で単純化したのがasync/awaitで、実際確かにこれで済む。
マルチスレッドの諸問題と解決策等、プログラミング界で経験値がたまった結果の、現段階の最適解だ。
これを実装してなくてどうする？と思うが。

スレッド周りの問題をいじくり回したい研究者には向いてるのだろうけど、それだけだよね。
やりたければ他言語でも生スレッドは使えるから、いくらでも出来るけど。
逆にGoroutineではチャネル接続タイプしか記述出来ないから、そこを越えた研究には向かないよ。
とはいえ現段階ではチャネル接続の優位性が覆る事はなさそうだが。

多分な、
・チャネル接続にすればマルチスレッドの諸問題が解決するかも？
という見積もりが外れただけなのだと思うよ。だからGoはメジャーになり損ねた。

なおJSは逆に、
・シングルスレッドに無限大の処理能力があれば、誰も並列なんて使わない。
　→ならシングルスレッドの処理能力を無限大にすればよくね？引っかかってるところ全部I/Oだろ
でI/Oをすべて切り離して非同期にした結果、これが大当たりして、あらゆる所に蔓延ってる。
当時メジャーでなかったクロージャの利便性を知らしめたとか、GUIにはプロトタイプが向いてたとか、他にも色々あるけど、
根本の言語設計が素晴らしかったから結果的にでも大当たりしたのは事実だよ。
722 名前：デフォルトの名無しさん mailto:sage [2021/11/28(日) 09:40:53.84 ID:CHeWGBnC.net]: >>708
というより、本来チャネルよりも適した抽象化がある場合でもチャネル使わなきゃいけないことが問題じゃないかな
たとえばpromiseで一つの値を返せたらいいだけのケースでチャネル使っちゃうと、
そこに処理は単一の結果の生成をもって完了するというセマンティクスは全く残らないわけよ
で誤って値を2回取り出そうとしたらデッドロックだ
723 名前：デフォルトの名無しさん mailto:sage [2021/11/28(日) 09:52:08.42 ID:zNq1hAJ3.net]: ていうかgoでもロックとか
サードパーティのロックフリーキューのライブラリは使えんじゃね？
しらんけど
724 名前：デフォルトの名無しさん mailto:sage [2021/11/28(日) 10:03:56.17 ID:Abxhe3pm.net]: >>710
ちなみにPromiseも俺は不要だと思ってるんだけど、
Promiseが無いと書けない何かってあるか？
C#はPromise見えてたけど採用しなかったし、実際async/awaitで足りてる感じだし。
725 名前：デフォルトの名無しさん mailto:sage [2021/11/28(日) 10:08:04.10 ID:CHeWGBnC.net]: >>712
async/awaitで使用されるTaskはpromiseの一種だよ
726 名前：デフォルトの名無しさん mailto:sage [2021/11/28(日) 10:23:44.01 ID:Abxhe3pm.net]: >>713
それはJSerの言う「Promiseが有ったからこそのasyncだ」という言い訳だろ。
Promiseという界面を露出させなくても問題ないと踏んでasync/awaitだけにしたのがC#。
勿論それ以前にC#だと生スレッドも使えるから最悪何とでもなるという保険はあったにしても。

C#erも同種の言い訳、つまりthread→backgroundWorker→Task→asyncと進化したのであって、
これがなかったら無理だった、という事を言うけど、これもやっぱり無理筋で、
2000年時点で「技術的に」asyncが実装出来なかった理由は見あたらない。
結局、思いつけなかっただけだと思うんだよね。

実際、2000年当時のCPUでも今のasync/awaitのコードは動くだろうし、
今現在Task界面も露出する意味無いだろ。
2000年当時にC#がいきなりasync/await実装してデビューしてたら神だったと思うよ。
727 名前：デフォルトの名無しさん mailto:sage [2021/11/28(日) 10:37:05.48 ID:CHeWGBnC.net]: >>714
async/await自体もpromiseの実装だよ
https://ja.m.wikipedia.org/wiki/Future_%E3%83%91%E3%82%BF%E3%83%BC%E3%83%B3
なおasync/awaitで事足りるpromiseのユースケースにおいては、Goではチャネルなんか使わず普通にgoroutine内で同期処理すればいいので、今の話題とは無関係
728 名前：デフォルトの名無しさん mailto:sage [2021/11/28(日) 10:53:27.71 ID:Abxhe3pm.net]: >>715
それはPromise中心主義的な考えであって、
実際async/awaitの理解にはPromiseの理解は不要だろ。
「そこで一旦止まって、非同期Jobが終わり次第、次を実行」で済むのだから。

実装でPromise型にするのも一つの手だけど、forkでも実装出来るのだし、(むしろforkの方が簡単）
> async/await自体もpromiseの実装だよ
これは買いかぶりすぎで、async/awaitとPromiseは直接の関係も必然性もないよ。
729 名前：デフォルトの名無しさん mailto:sage [2021/11/28(日) 11:07:43.63 ID:Abxhe3pm.net]: >>715
そういえば脱線を嫌ってるのか？なら戻しておくと、

Goはgoroutineで並列平行をお気楽に書けるようにしたが、
並列は今のところasync/awaitで決まりなので、目論見は外れた。
平行は…async/awaitではなさそうだし、まあチャネルだろうし、goroutineかも？
730 名前：デフォルトの名無しさん mailto:sage [2021/11/28(日) 11:15:38.54 ID:Abxhe3pm.net]: >>715
716（脱線側）補足

× > async/await自体もpromiseの実装だよ
○ async/awaitの実装の一つがpromise

async/awaitはただの記法であって、その実装にpromise方式も使える。
つまりasync/awaitの方が上位概念だよ。同一レイヤーではない。
731 名前：デフォルトの名無しさん mailto:sage [2021/11/28(日) 11:16:48.98 ID:7hiPfTRd.net]: >>714
Taskなしのasync/awaitだけじゃ並列処理できないんじゃないの？
732 名前：デフォルトの名無しさん mailto:sage [2021/11/28(日) 11:38:24.51 ID:Abxhe3pm.net]: >>719
何で？
Jobを投げ込むのにTask型を使ってるだけで、要は関数のエントリポイントが有ればいいだけだし、実際JSはそうだろ。

> async function asyncCall() {
>
console.log('calling');
>
const result = await resolveAfter2Seconds();

> console.log(result);
>
// expected output: "resolved"

> }
>

asyncCall();
> https://developer.mozilla.org/ja/docs/Web/JavaScript/Reference/Statements/async_function

async/awaitが保証してるのは、
・async関数は非同期で実行される --- (A)
・awaitでメインスレッドは一旦処理が返る。その後、async関数が終わり次第続きを実行する。
であって、(A)をスレッドプールから実行するようにしたのがC#で、並列されるし、
そうしてないだけ、つまり非同期を同期的に書けるようにしただけなのがJSだろ。
だから逆に、JSでも(A)をWorkerスレッドに振るようにしたら並列するようになるだけだよ。
733 名前：デフォルトの名無しさん mailto:sage [2021/11/28(日) 11:56:27.00 ID:7hiPfTRd.net]: awaitで待っている側はその間止まっているわけだから並行処理ではあっても並列処理じゃないでしょ。
まぁTask.WaitAllのように複数同時に投げられるようにするならそれでもいいだろうけど。
734 名前：デフォルトの名無しさん mailto:sage [2021/11/28(日) 12:21:57.96 ID:s59YsBRT.net]: async/await ってPromiseの糖衣構文にしか見えなくて大いに疑問が(知らないだけ？
糖衣構文で言語仕様を膨らませて、こんなに簡潔に書けるようになりました！とかもう子供かと
言語仕様が増えても出来ることが簡潔に書ける以外で変わらないんじゃ劣化してるだろ

簡潔にと言われるたびに信用を下げる
735 名前：デフォルトの名無しさん mailto:sage [2021/11/28(日) 12:23:22.96 ID:Abxhe3pm.net]: >>721
それは君のawaitの理解が間違ってる。
書いたとおり、awaitで「メインスレッドは一旦処理が返る」から、GUIも反応するんだよ。

メインスレッドはasync/awaitでは止まらない。
awaitでイベントループ(メッセージポンプ)に返されるだけ。
その後asyncが終了したら、awaitの続きから実行される。
この実装の一つとして、Promiseがある。でも動かすだけならforkで実装した方が多分簡単。

メインスレッドは止まってないのだから、asyncジョブはいくらでも「順次」投げられる。
（同時に投げる必要はない）
並列平行したければ好きなだけ投げ込めばいいだけ。
736 名前：デフォルトの名無しさん mailto:sage [2021/11/28(日) 12:45:46.64 ID:s59YsBRT.net]: >>721
俺の理解では
awaitは非同期関数でのawait以降のセンテンスをthenメソッドの処理としてasyncを実行する
thenのネストを平らにして、単に簡略に書けるだけの糖衣構文
737 名前：デフォルトの名無しさん mailto:sage [2021/11/28(日) 12:56:29.36 ID:s59YsBRT.net]: >>724
まー、理解が怪しいんで間違ってたら指摘してくれ
ともかくawaitじゃメインスレッドは停まらない、もしくはメインスレッドではawaitは呼べない(はずじゃなかったか？)、という程度の理解
738 名前：デフォルトの名無しさん mailto:sage [2021/11/28(日) 12:59:08.05 ID:Abxhe3pm.net]: >>722
簡単�
739 名前：ﾍ正義だろ。 無駄に仕様が膨らんでいるのは、紆余曲折しすぎたからだ。 Promiseが便利だとされているのはPromise.all位で、つまりjoinだが、 今のasync/awaitはこれを直接的に解決する手段を提供してない。 だからここが何とかなれば、async/await以外は廃止方向だと思うぜ。今のままなら。 JSの場合はasync/awaitが見えてたのにPromise導入に踏み切った。 俺はあれは判断を間違えてると思うよ。 JSは仕様を廃止出来ないのだから、ムダ仕様を入れる度にオワコン化していくだけ。 逆に、バージョン管理してて仕様を廃止出来るC#は、実験場にも出来るし、今そうなってる感はあるけど、 本来ならもっと軽量級のGoやRubyで色々やるべきだったよね。 Goも登場時の2009にasync/await持ってればもっとメジャーになってたと思うよ。 goroutineも無いよりはましだけど、その程度でしかないから今こうなわけでさ。 []: [ここ壊れてます]
740 名前：デフォルトの名無しさん mailto:sage [2021/11/28(日) 12:59:20.84 ID:7hiPfTRd.net]: >>723
イベントループの存在が前提なのかな。
async/awaitではawaitで待っているTaskが内部でまたawait待ちになった時に
その制御を取得する手段がないから、そのイベントループ自体はasync/awaitとは
異なる機構で実現されてるってことかね。
741 名前：デフォルトの名無しさん mailto:sage [2021/11/28(日) 13:14:08.57 ID:xYHgZ8WY.net]: >>724
>>725
idミスってるぞ
742 名前：デフォルトの名無しさん mailto:sage [2021/11/28(日) 13:18:18.69 ID:Abxhe3pm.net]: >>727
そうだね。少なくともC#もJSもそう。ランタイムがある前提。

要は、asyncジョブが終わった時にメインスレッドをたたき起こす仕組みが必要なだけ。
GUIの場合はメインスレッドはイベントループを回ってるから、そこにイベントとして与えるのが一番簡単だし、そうしてるはず。
コンソールアプリだとイベントループはないので、ランタイム側にメインスレッドをたたき起こす仕組みを付加しないといけない。
けど、goでもこれはやれば出来るだけの話だよね。
743 名前：デフォルトの名無しさん mailto:sage [2021/11/28(日) 13:26:20.41 ID:3qnAFeGl.net]: >>716
違うよ。
全然別の部分からresolveされるPromiseをawaitするっていう、コールバック関数をasync/awaitに変換する事ができたりする。
可換なんよ。
744 名前：デフォルトの名無しさん mailto:sage [2021/11/28(日) 13:28:24.24 ID:Z9Xk/5kf.net]: async/awaitが使われていると、コードのいろんな箇所がどんどんノンブロッキングになっていく傾向がある気がしていて、
多くの人にとってかなり使い心地が良いんだろうな、と思ってる

俺はチャネルとgoroutine好きだけど、よく考えるとみんなうまく使えてないんだよなあ・・・
745 名前：デフォルトの名無しさん mailto:sage [2021/11/28(日) 13:32:08.20 ID:p4O5g5oI.net]: > 俺はチャネルとgoroutine好きだけど、よく考えるとみんなうまく使えてないんだよなあ・・・

太田道灌
746 名前：デフォルトの名無しさん mailto:sage [2021/11/28(日) 13:35:20.14 ID:Abxhe3pm.net]: >>730
出来るのは分かるが、使い道がないんだよ。

俺もPromiseは要は予約を積んでるだけなので無限に動的に積んで色々出来るか？と思った事はあった。
async/awaitはその点ハードコードだからそのルーチンしか処理しないし、狭い範囲で確定的だ。
ただな、Promiseに動的にいろんな場所からPromiseを積み重ねないといけないような状況はないんだ。
単にasync/awaitでまっすぐ書くだけで十分なんだよ。
747 名前：デフォルトの名無しさん mailto:sage [2021/11/28(日) 13:37:04.91 ID:xYHgZ8WY.net]: ダメだ完全に発狂しとる
748 名前：デフォルトの名無しさん mailto:sage [2021/11/28(日) 13:39:44.17 ID:Abxhe3pm.net]: >>731
> 俺はチャネルとgoroutine好きだけど、よく考えるとみんなうまく使えてないんだよなあ・・・
ならお前が上手く使ってる例を布教すればいいだけ。
それが凄く有用で、現行のasync/awaitやPromiseでは実現出来ないものであれば、
Goスゲーって事になるだけ。

JSも2005にXHRが再発見されるまではオモチャ扱いだったし、ワンチャンはあるぞ。
749 名前：デフォルトの名無しさん mailto:sage [2021/11/28(日) 14:03:02.10 ID:cigmxKA5.net]: >>733
めちゃくちゃ使うよ。

既にメモ化されたデータがあればそれを使う、そこに無ければ動的にイベントハンドラー仕掛けておいて、一定時間内にそのイベントが発火したならそのイベントの引数を返すが、発火しなければrejectする、みたいな。

async/awaitしか使わない、CPUをきちんと解放しろ、と言う話なら、Goならランタイムが自動的にやるので気にせず同期型のように書いて良いぞ。
750 名前：デフォルトの名無しさん mailto:sage [2021/11/28(日) 14:08:56.82 ID:Abxhe3pm.net]: >>736
よく分からんからコードで頼む。
君のコードでなくてもいいし、誰かのGitHubでもいいので。

要はその、Promiseでは簡単に出来るが、async/awaitでは無理（または複雑になる)、っていうコードを。
751 名前：デフォルトの名無しさん mailto:sage [2021/11/28(日) 14:10:43.62 ID:Z9Xk/5kf.net]: >>735
おれの知識はほぼほぼ「Go言語による並行処理」だから、これを読め、で終わってしまう・・・
752 名前：デフォルトの名無しさん mailto:sage [2021/11/28(日) 14:37:47.26 ID:VtXew58l.net]: >>737
この説明でわからなければ、どーせメリットもわかんないだろうから「めんどくさいコード書くな」で終わるでしょw
実際に使ってる自分のリポジトリ晒すのもアホだし、Zennの記事はっとくわ。

https://zenn.dev/uzimaru0000/scraps/b4445cfed8f42f
753 名前：デフォルトの名無しさん mailto:sage [2021/11/28(日) 14:39:55.58 ID:VtXew58l.net]: こんなんも便利よね。
https://qiita.com/jkr_2255/items/628f0507456eb841497c
754 名前：デフォルトの名無しさん mailto:sage [2021/11/28(日) 14:44:16.89 ID:cigmxKA5.net]: async/await(だけ)では面倒で、Promiseと可換だからこそ便利だ、と言ってるんよ。
C#でも皆に臨まれてTask Likeな自作クラスが作れるようになったわけだが、いかんせん大袈裟な作りがいる。
755 名前：デフォルトの名無しさん mailto:sage [2021/11/28(日) 18:42:46.20 ID:Abxhe3pm.net]: >>739-741
うん、分からんね。ただ君の説
> Promiseと可換だからこそ便利だ
についてはC#はそうなってないからじきに結果は出るだろう。
とはいえヘルスバーグは知っててPromiseは不要だと判断したのだし、俺もそう思えるのだけど。
(ヘルスバーグについてはインタビューがあったはずだがググっても出てこない）

一応各URL内容に対し回答しておくと、
> await click().then(click).then(click)
については、
await click();
await click();
await click();
で、すさまじく馬鹿っぽい事以外の問題点はない。

> 遅れてのセット…Promise#thenはresolve前でもresolve後でも問題なく動く
についてはまあそうなんだけど、これはどちらかというとonload系イベントの問題で、
この方法でも根っこの部分、つまり最初のPromiseを設定する時点で既に onload 済みなら発行されない問題が解決出来ておらず、
結局ユーザー側が onload 済みかチェックする、または絶対に onload 未発行の時点で実行する必要がある。
だから onload 系のイベントが最初から全部 Promise だったら綺麗に解決してたのだろうけど、実際そうじゃないので言うほど利益がない。
Promiseが残るか自前でonload発行をチェックしたフラグが残るか程度だ。

> 複数の条件…Promise.allで取れる
これはその通りなのだけど、馬鹿っぽくてよければ同様に await 縦積み、
await sumefuncA();
await sumefuncB();
await sumefuncC();
で行ける。(C#はこれでいけるはず。JSはもしかしたら駄目かも）
756 名前：デフォルトの名無しさん mailto:sage [2021/11/28(日) 19:04:46.48 ID:Abxhe3pm.net]: 742最後補足＆訂正
JSの場合も縦積みは出来るが書き方が違うようだ。
(というかC#も間違えていたので書き直すと）

await someAsyncFuncA;
await someAsyncFuncB;
await someAsyncFuncC;

となる。以下は https://developer.mozilla.org/ja/docs/Web/JavaScript/Reference/Statements/async_function より。(720で貼り損なったので)
async function concurrentStart() {
console.log('==CONCURRENT START with await==');
const slow = resolveAfter2Seconds() // ただちにタイマーを起動
const fast = resolveAfter1Second() // ただちにタイマーを起動

// 1. これは即時実行される
console.log(await slow) // 2. これは 1. の 2 秒後に実行される
console.log(await fast) // 3. fast はすでに解決しているので、これは 1. の 2 秒後 (2.の直後) に実行される
}
757 名前：デフォルトの名無しさん mailto:sage [2021/11/28(日) 20:06:47.00 ID:s59YsBRT.net]: 推してる癖に間違えるくらい千差万別なのね
758 名前：デフォルトの名無しさん mailto:sage [2021/11/28(日) 20:25:18.89 ID:Abxhe3pm.net]: >>744
間違えたのは俺の問題であって、C#もJSもawaitの書き方は同じ。
https://developer.mozilla.org/ja/docs/Web/JavaScript/Reference/Statements/async_function
https://docs.microsoft.com/ja-jp/dotnet/csharp/programming-guide/concepts/async/task-asynchronous-programming-model
759 名前：デフォルトの名無しさん mailto:sage [2021/11/28(日) 20:31:19.41 ID:AhuL0Pkx.net]: >>710
一回だけ使うはずなのを二回以上使うと不具合があるのが問題とか言い出したら
副作用のある関数の呼び出しも問題ってことになるよな
「単一の結果の生成をもって完了するというセマンティクス」というのもないし
760 名前：デフォルトの名無しさん mailto:sage [2021/11/28(日) 20:36:54.41 ID:Xc/smr1I.net]: まあゴル同士で複雑なハンドシェイク的な値のやり取りはしない方が良いね
少なくとも俺はバッドパーツ認定してる
結果をkey-value storeに吐くとかそういう使い方しかしてない
761 名前：デフォルトの名無しさん mailto:sage [2021/11/28(日) 22:35:18.85 ID:igoyS+tp.net]: >>746
そうだね
副作用があって2回呼び出したら死ぬ関数より、冪等な関数の方が望ましいよね
だから単一の結果を生成するだけの処理にchannelを使うのはクソだよね
762 名前：デフォルトの名無しさん mailto:sage [2021/11/28(日) 23:26:53.57 ID:m82RP4Nz.net]: >>748
副作用のある関数もクソということになるだろうって話だがな
呼び出すべきじゃないところで誤って呼び出すと不具合があるから問題だと言い出すんだから
763 名前：デフォルトの名無しさん mailto:sage [2021/11/29(月) 00:36:52.64 ID:M92LX90q.net]: C#おじさんの大暴れ回
764 名前：デフォルトの名無しさん mailto:sage [2021/11/29(月) 02:15:08.24 ID:JPr9HHY7.net]: >>742
C#もそうなりましたが…。
https://qiita.com/inasync/items/6417933e258b53b5bbd3

こっちでは似たような事やってるね。
https://www.buildinsider.net/column/iwanaga-nobuyuki/009

あんまり知らんだけでは？
765 名前：デフォルトの名無しさん mailto:sage [2021/11/29(月) 09:11:23.82 ID:kiCwAGEX.net]: >>749
それはその通りで、一般論として、副作用のない関数より副作用のある関数のほうが相対的にはクソだろ？
本来副作用の必要がない場合でも常に副作用のある関数として実装しなければならないとしたら、本来例えば半分程度で済むはずが全てクソ関数になっちゃうじゃん
それがchannel
766 名前：デフォルトの名無しさん mailto:sage [2021/11/29(月) 11:31:15.42 ID:Ulxk0pae.net]: まあGoの設計思想的としてはそもそも非同期関数を作っちゃいけないんだろうな
常に非同期で使用することが明らかな場合でもchannelを引数に取るような関数をパッケージ外に公開するような設計はすべきじゃなくて、
普通に同期関数にしといて使う側で必要に応じてgoroutine使えということなんだろう
767 名前：デフォルトの名無しさん mailto:sage [2021/11/29(月) 12:15:00.68 ID:ofvG7nI/.net]: え？goroutineにチャネル渡さなけりゃクロージャで渡すしかないから共通関数にできんし
ちょっと何を言ってるのか分かりませんね
768 名前：デフォルトの名無しさん mailto:sage [2021/11/29(月) 12:15:45.71 ID:ofvG7nI/.net]: 外部関数
769 名前：デフォルトの名無しさん mailto:sage [2021/11/29(月) 12:23:12.94 ID:ofvG7nI/.net]: ツアーでもチャネル渡すコーディングしてるよ
https://go-tour-jp.appspot.com/concurrency/2
770 名前：デフォルトの名無しさん mailto:sage [2021/11/29(月) 12:35:27.53 ID:O0SZji1w.net]: tourはあくまで機能の紹介だろ。
hello worldを実務で書くか？

channelの何が気に食わんの？デッドロックするところ？
別に後続の関数投げても良いんだぞ。
771 名前：デフォルトの名無しさん mailto:sage [2021/11/29(月) 12:39:01.25 ID:g6qk7DwE.net]: >>754
>>753 が言ってるのはライブラリの公開関数の話で、753のコメント通りでしょ
goroutine使えば同期関数を簡単に非同期にできるから、ライブラリの高階関数は同期にせよ、っていう思想っぽい

標準ライブラリにもチャネルを受け渡しするやつはあるのかもしれないけど、少なくとも俺はしらない
772 名前：デフォルトの名無しさん mailto:sage [2021/11/29(月) 12:46:47.06 ID:ofvG7nI/.net]: 標準のライブラリは低レベル機能しか持たせてないじゃん
だからといって、非同期に使うことは好ましくないという設計思想だとかかなり無理があるだろ
ツアーは基本的な使い方のサンプルなんだから、基本的に非同期で動かす関数を書くにはチャネルを渡しましょう！と大々的に宣言してる証拠じゃないのか？
773 名前：デフォルトの名無しさん mailto:sage [2021/11/29(月) 13:18:56.71 ID:rw4mU1bL.net]: まだやってた
774 名前：デフォルトの名無しさん mailto:sage [2021/11/29(月) 13:51:14.56 ID:DbScqZpC.net]: 好きだよね～
775 名前：デフォルトの名無しさん mailto:sage [2021/11/29(月) 14:19:10.41 ID:O40DgaQc.net]: >>752
>本来副作用の必要がない場合でも常に副作用のある関数として実装しなければならないとしたら

そんなのがどこから出てきたんだか。
呼び出すべきじゃないところで誤って呼び出すと不具合があるからクソだと言い出すなら
入出力とか、副作用を持つ関数もクソということになるって話だがな
戻り値を変数に入れて置けば良いだけなのにそれを出来ずに
2回呼び出すと不具合が起こると文句を言ってるんだよな
776 名前：デフォルトの名無しさん mailto:sage [2021/11/29(月) 16:44:46.78 ID:M92LX90q.net]: チャネルが理解できないC#おじさんがID変えて自己弁護しながら暴れてるだけ
>>752
「副作用のない関数より副作用のある関数のほうが相対的にはクソ」
一般的には手続き型言語であればサイドエフェクトがある関数が普通で、純関数言語のようなほとんど副作用の
無い関数などはI/O処理などでビックロックなどで誤魔化してるに過ぎない。
>>753
そもそもGoは全部が非同期・並列だから逆。メインでさえgoroutineの１つで、デフォルトでGOMAXPROCS
「channelを引数に取るような関数をパッケージ外に公開するような設計はすべきじゃなく」これも逆です。
structには本来はchannelやcontextを含めるべきではなく、引数に取ることが推奨されている
>>759
「標準のライブラリは低レベル機能しか持たせてない」最近の言語は、標準のライブラリという重大なクソを
薄く小さくするのが流行り、なぜなら稚拙な標準のライブラリをリリースしてしまい、後からもっと効率的で
理論に裏付けされたライブラリが出てくる。そしてクソな標準が互換性のために直せない。薄くて小さい
ライブラリは速く、メンテナンスも容易で、依存性も少ない。
逆に、標準のライブラリに重厚長大を求めるのは何かが間違ってる。チャネルを渡すことを使う事を禁忌したい
気持ちが奥底にあるから「証拠」なんて言葉が出てくる。Tourなどのパイプライン処理とかを見ればチャネルを
受け渡すことの効率性と高い非依存が良くわかる。aync系の言語でやろうとしたらミューテックスでロックして
処理の終わりでwaitしてなど極めて並列度が低く、依存性が高く、ゴミのような自己満足が広がる
だから遅くて成果物はデカい
777 名前：デフォルトの名無しさん [2021/11/29(月) 19:32:28.88 ID:TPDpg4yk.net]: まぁまぁ、顔真っ赤にして投稿するのやめよ？落ち着こうな
778 名前：デフォルトの名無しさん mailto:sage [2021/11/29(月) 20:00:58.25 ID:rw4mU1bL.net]: 昨日からなにが言いたいのかさっぱり
自分でも頭おかしくなってるんだろうか
779 名前：デフォルトの名無しさん mailto:sage [2021/12/20(月) 18:58:52.11 ID:S0D0uK3y.net]: Go 1.18 Beta 1 is available, with generics, 14 December 2021
780 名前：デフォルトの名無しさん mailto:sage [2022/01/07(金) 00:14:05.77 ID:l4f7h5d/.net]: ちょっとかじってみたニワカの感想なんだけど
Go言語ってBetter Cって感じだな。
781 名前：デフォルトの名無しさん mailto:sage [2022/01/07(金) 00:38:05.83 ID:j/jugqL+.net]: >>763
チャネルを渡すことに積極的な>>759に、真っ赤になってチャネル渡すコーディングを語ってて草
782 名前：デフォルトの名無しさん [2022/02/06(日) 12:21:06.60 ID:SQRLIZAc.net]: GoのジェネリックがGo 1.18 Beta 1でデビュー
https://www.infoq.com/jp/news/2022/01/go-generics-beta/

func SumIntsOrFloats[K comparable, V int64 | float64](m map[K]V) V
type Number interface { int64 | float64 }
783 名前：デフォルトの名無しさん mailto:sage [2022/02/07(月) 09:14:37.90 ID:YCtDYJO4.net]: お前らが煩いから…
784 名前：デフォルトの名無しさん mailto:sage [2022/02/19(土) 10:13:03.12 ID:AG6SdX6W.net]: 最近goよりrustが気になってきた
コンパイラ型の早いモダンな言語ということで安易にgoやってたけど
rustにすべきだったか
785 名前：デフォルトの名無しさん mailto:sage [2022/02/19(土) 11:35:19.56 ID:R5yjbcGL.net]: rustは学習時間がかかる
786 名前：デフォルトの名無しさん mailto:sage [2022/02/19(土) 13:51:37.16 ID:u5oa6W2x.net]: 利用範囲というか得意範囲が違うから興味はない
まして癖が強いんで覚えなきゃならんことが多すぎる
出始めのJavaより癖が強くないかあれは
今は皆が馴染んだけどJavaのIO周りとか、解らねぇ！という声が多かった記憶
だから少なくとも10年は待つのが正解
787 名前：デフォルトの名無しさん mailto:sage [2022/02/19(土) 15:23:37.32 ID:AlOKsuc0.net]: >>771
用途が違うんだから、両方やればよろし
788 名前：デフォルトの名無しさん mailto:sage [2022/02/19(土) 16:39:42.26 ID:lVeS0ElI.net]: Goは向いている適用範囲が狭い
他の言語も併用せざるをえない
789 名前：デフォルトの名無しさん mailto:sage [2022/02/19(土) 19:00:07.51 ID:ZkbC0IWU.net]: それでいいんだよ
790 名前：デフォルトの名無しさん mailto:sage [2022/02/19(土) 23:50:48.59 ID:xGD28DxW.net]: Go 1.18 Release Candidate 1 is released 2022/02/18 2:04:17 (昨日)
https://groups.google.com/g/golang-announce/c/QHL1fTc352o/m/5sE6moURBwAJ
791 名前：デフォルトの名無しさん mailto:sage [2022/02/20(日) 11:21:21.17 ID:VbAVfRtD.net]: > 早いモダンな言語
速くもないしモダンでもない
792 名前：デフォルトの名無しさん mailto:sage [2022/02/20(日) 12:17:41.07 ID:1fyiha6j.net]: 1.18 finalは3月に持ち越しか
793 名前：デフォルトの名無しさん mailto:sage [2022/02/20(日) 12:35:50.50 ID:coxlbRTF.net]: 単体のマシンで並列処理をひたすらに行うという涙ぐましい用途特化よね
無駄金がありゃ分散化してロードバランサ使ってしのぐと思う
794 名前：デフォルトの名無しさん mailto:sage [2022/02/20(日) 13:24:25.85 ID:QnKhevyf.net]: Goは並列処理が書きやすい簡単な静的型付け言語って感じよな
Goの文法はモダンとはとても言えないけど、わりと早いビルド、gitとの連携、fmt、とかもろもろのエコシステムを総じて言えばモダンと呼べそうではある

逆に、例えばD言語は文法が良いのにエコシステムがウンコだったから人気出なかったんだと思う
795 名前：デフォルトの名無しさん mailto:sage [2022/02/20(日) 15:45:27.00 ID:coxlbRTF.net]: 分散しないでも程よく性能が出るって点から、ネットワーク関係の組み込み機器(ルータとか)に向いてるような気もする(気がするだけ)んだけど、特に席巻してるとも聞かないから使われてないのかな
796 名前：デフォルトの名無しさん mailto:sage [2022/02/20(日) 15:47:35.30 ID:coxlbRTF.net]: busybox的な作りならメモリも圧迫しないだろという考え
797 名前：デフォルトの名無しさん mailto:sage [2022/02/20(日) 18:28:36.22 ID:VbAVfRtD.net]: >>782
ルータの中身なんてlinuxでCだろ
組み込みはCPUパワーと消費電力に厳しいのでC以外に現実的に解がない
逆に言えば、C以外で組んだ時には価格と消費電力でその商品に訴求力が無くなる
Cでは実現不可能な程のファームウェアアップデートの頻度が必要な商品もないだろ
798 名前：デフォルトの名無しさん mailto:sage [2022/02/20(日) 18:35:18.72 ID:Y1MJvTk4.net]: Google的には組み込み向けはFlutter/Dart
799 名前：デフォルトの名無しさん mailto:sage [2022/02/20(日) 18:37:32.10 ID:VbAVfRtD.net]: >>781
goroutineが正解だと間違えた失敗言語だろ
このチャレンジ自体は良い事だが、正解はasyncだった

複雑になりすぎたC++を嫌い、またWeb系での最速を求めた連中はRustに行った
型を知らなかったWeb系の馬鹿共には丁度良かったが、そいつらはTSに行った
ast木がデフォで出るのは面白いが、あれはプログラマ的にはレベルが低すぎて使えない（自前で正規表現でやるよりはまし程度でしかない）
ならいっそのことあれこれやりまくる実験言語にしてもいいとは思うが、仕様の追加は他言語と比べても遅い

現在新規でGoをやる意味はないから、あとは廃れるだけだろ
800 名前：デフォルトの名無しさん [2022/02/20(日) 20:11:46.12 ID:uXMwiVcI.net]: web系のバックエンドである程度速度求める層には使われてくんじゃないかな。楽だもん。
個人的にはnull安全じゃない点でもういいやって感じだけど。
801 名前：デフォルトの名無しさん mailto:sage [2022/02/20(日) 21:46:42.94 ID:VbAVfRtD.net]: >>787
> ある程度速度求める層
これは基本的にない。
速度が問題になると分かっていて、チームがRustを使える場合、100%Rustを選択する。
Rustが使えない場合、今現在の第一選択肢はTSだろ。
そこそこ速いし、最悪はJSエンジニアを流用可能だし、全く新規に教育するにしてもフロントエンドでも使えるし。
Web系の現場でGoをわざわざ教育する意味はない。

（飽和した市場においては）商品は尖ってないといけないとよく言われるが、Goは今現在尖ってないんだよ。
速度が欲しくてガッツリ組みたければC#でもいいし、実際にASP.NETのシェアは7.9%でPHPに次ぐ第2位だ。(なおGoは0.0007%、Rustはそれ以下）
https://w3techs.com/technologies/overview/programming_language
TSよりはGoが速いのも事実ではあるが、
https://atmarkit.itmedia.co.jp/ait/articles/1909/13/news133.html
googleがrubyを切った時のようにチーム内で言語を統一するなら、今ならJSかTSになる。Goはあり得ない。
今現在もシェアが低い＝使える奴が少ないのだから、このままだと数多のマイナー言語と同様にポシャって終わり。

バックエンドで速度を求める際、最速はRustだけど、これが嫌ならC#で、ここで終わってしまう。
C#の駄目な点は仕様が重量級で勉強するのが大変な事位で、速度も安全性も生産性もGo以上だから。
Goは、速度がある程度必要だが最速である必要はなく、RustやC#は絶対に勉強したくない層向けになるが、これは現実的に無い。
802 名前：デフォルトの名無しさん [2022/02/20(日) 22:04:59.75 ID:uXMwiVcI.net]: >>788
なるほどね。
803 名前：デフォルトの名無しさん mailto:sage [2022/02/20(日) 22:33:50.88 ID:uSEnVnLU.net]: >>788
JS/TSの人材がNode/Denoでサーバーサイドもいけるからね
そしてそれでは性能面リソース面で満足できないならRustが記述しやすくていい
804 名前：デフォルトの名無しさん mailto:sage [2022/02/20(日) 22:37:24.33 ID:x/Ldx69r.net]: Rustが使えない場合で、かつ速度が必要な場合にTS使う訳無いだろ。
C#はわかるが。
マルチコアに弱すぎるわ。
C#ではなくGo選ぶケースってのはGoならではのメリットがあるシーンが多い。
805 名前：デフォルトの名無しさん mailto:sage [2022/02/20(日) 23:21:45.49 ID:VbAVfRtD.net]: >>791
> Goならではのメリット
だからそれは何？って話だろ。

C#で駄目でGoってのは学習コストくらいだが、学習コストが問題ならWeb系ならTS/JSで決まりだよ。
Goはgoroutineかgo generateが大当たりすれば良かったが、そうでない以上、C#に勝てる仕様がない。
現在シェアでボロ負けしてて光る仕様もなければ、このまま沈没以外にない。

Rustを考えれば分かりやすいが、シェアでボロ負けしててもC#に速度で勝てるし、
安全性も一応最高を目指してるから、選ぶ理由はあるだろ。
GoはRustが出てきた時に身の振り方を考えなければならなかったんだよ。
806 名前：デフォルトの名無しさん mailto:sage [2022/02/20(日) 23:56:31.79 ID:KcoG54wC.net]: >>792
そのGoroutineだよ。観測範囲狭いのでは…？
C#のasync awaitとスレッドプールは詰まる。
807 名前：デフォルトの名無しさん mailto:sage [2022/02/21(月) 00:13:42.23 ID:lBTJyZA6.net]: >>793
asyncな関数を呼べばスケジューラに戻るわけだから
長時間ループで計算のみを続けることでもない限り詰まることはないでしょ
808 名前：デフォルトの名無しさん mailto:sage [2022/02/21(月) 00:16:41.00 ID:GbKjQqyn.net]: >>793
詰まるって何が？
これ？なら仕様を知らないだけだね
https://oita.oika.me/2016/02/18/task-and-threadpool/

まあいずれにしても、C#で問題があれば、速攻対策されるよ
809 名前：デフォルトの名無しさん mailto:sage [2022/02/21(月) 00:26:24.14 ID:GbKjQqyn.net]: あとこんなんも出てきた
https://www.rox-note.tech/?p=30

まあスレッドプールはそういう設計なのだから、デフォで問題ない使い方をしないのなら自前で設定してやらないと駄目だね。
でもスレッドプールはプールであって、goroutineみたいにスレッド占有（スタック保持）ではないので、
動いてないスレッドはプールに返されて結果的にCPUは最速で動くはずだけど。
810 名前：デフォルトの名無しさん mailto:sage [2022/02/21(月) 01:57:33.27 ID:889Qm57n.net]: 長時間、膨大なタスクを動かしたいんだよ。
811 名前：デフォルトの名無しさん mailto:sage [2022/02/21(月) 01:57:59.42 ID:889Qm57n.net]: Go使う前はErlang使ってた案件。
812 名前：デフォルトの名無しさん mailto:sage [2022/02/21(月) 02:23:44.32 ID:YbXysJZO.net]: C#ってサーバというかバックエンドで使えるのか
知らなかった
813 名前：デフォルトの名無しさん mailto:sage [2022/02/21(月) 03:00:09.00 ID:lBTJyZA6.net]: >>797
膨大なタスクでも途中で何らか入出力すればスケジューラに戻るからタスクが切り替わる
入出力ゼロならばそれは延々と算術計算するだけなのだから別スレッド立ち上げればよい
814 名前：デフォルトの名無しさん [2022/02/21(月) 03:32:12.85 ID:zbwL0D6l.net]: goroutineが理解できないC#おじさんがのC#のasyncで騒いでるだけ
こいつは数多くの言語が採用してるchannelの原理も理解できない。
815 名前：デフォルトの名無しさん mailto:sage [2022/02/21(月) 08:43:31.09 ID:889Qm57n.net]: >>800
スレッドだと必要な数が多すぎて回らない。
シミュレーションの類やってる。

あとバッチで集計処理していくとかも作ってるけど、これも一億行百万ファイルとかが対象。
816 名前：デフォルトの名無しさん mailto:sage [2022/02/21(月) 08:44:21.18 ID:889Qm57n.net]: >>801
なるほど。説明しても理解できてないから無駄だし、
理解する気が無いのか。
817 名前：デフォルトの名無しさん mailto:sage [2022/02/21(月) 17:01:09.43 ID:GbKjQqyn.net]: >>802
まず、論理CPU数よりも多いスレッドを立ち上げても余計に遅くなる。
だから長時間膨大なタスクの結果を最速で得るためには、
論理CPU数と同じスレッド数で順に処理する事であり、
当たり前だがC#も含めてスレッドプールはこういう設計になる。

膨大なジョブを論理CPU数よりも多いgoroutineでカバーするのは、一般論としては組み方が悪い。
それで速くなる事はないから。
一般的にはその場合はスレッドではなくただのデータオブジェクトとし、論理CPU数と同じスレッド数で回す。

例えば有限要素法のシミュレーションを行う場合、当然データは100万個とかになるが、
CPUが10個なら10分割して、内部は完全に独立して回し、
他CPU担当と隣接してるノードは致し方ないので通信し、CPU10個で協調させながら回す。
これをgoroutine100万個として組むのがGoの思想なのかもしれないが、速くはならないね。
ただし、プログラムは簡単にはなる。

Erlangはだいぶ思想が違う。
あれはスケールアウト時のパフォーマンス低下を回避するために疎結合にしたもので、
実際スケールアウトしてもほぼ性能低下がないのでひたすら物理で殴れるらしいが、
それならErlangでいいよね、でしかない。

尖るってのは、「○○でも出来る」ではなくて、「○○じゃないと出来ない」の事。
Goにはこれがない。
なおC#、.NET4.0の64bit環境では32767個のスレッドが上限らしい。
https://stackoverflow.com/questions/145312/maximum-number-of-threads-in-a-net-app
一般的には、こんなにスレッドが必要な時点で組み方がおかしい、となる。（上記の通り）

> 一億行百万ファイル
普通は10CPUなら10分割して1,000万行10万ファイル*10ジョブにして投入、
レイテンシがバラつくようなら例えばさらに10分割で100万行1万ファイル*100ジョブにする。
これを1,000,000 goroutineで回すメリットは何？
818 名前：デフォルトの名無しさん mailto:sage [2022/02/21(月) 17:23:04.30 ID:889Qm57n.net]: >>804
その考え方が古いでしょ。goroutineは軽量スレッドで実質async await+スレッドプールだよ。

https://zenn.dev/hsaki/books/golang-concurrency/viewer/gointernal

>>804
チャンネルでfan in/fan outしてる。
819 名前：デフォルトの名無しさん mailto:sage [2022/02/21(月) 17:48:23.98 ID:LC1rF3os.net]: >>801
それは例として厳しいかな
C#については全く知らないが
例えばRustではchannelの送受信もasync環境ではasyncとなる
つまりgoroutineのようにchannel送受信だけを永遠にする長時間タスクがあってもタスクは切り替わる
だからそういう例でも大丈夫
おそらくC#でも同じ状況ではないかと推測
820 名前：デフォルトの名無しさん mailto:sage [2022/02/21(月) 18:21:27.64 ID:YbXysJZO.net]: goにおけるチャンネルって、概念的には別スレッドのI/Oにデータ渡して発火させる感じだよね
最大スレッド数は開いているチャンネル数以上になることはないし、
メインスレッドには関係ない

async/awaitで詰まるってのはawaitが文字通りメインスレッドで待つからって話ではなく？
821 名前：デフォルトの名無しさん mailto:sage [2022/02/21(月) 18:35:22.44 ID:VpybQnqn.net]: goroutineも実質スレッドプールなのは事実だね
async/awaitはawaitの区切りでしか中断できないのに対してgoroutineはGoのユーザーコードならどこでも中断できるので、どちらがより詰まりにくいかといえばGoかもしれない
とはいえGoもシステムコールの中断はできないから、現実には差は出ないだろうね
822 名前：デフォルトの名無しさん mailto:sage [2022/02/21(月) 18:56:08.62 ID:shT+MRih.net]: >>804
Erlangは「スケールアウト時のパフォーマンス低下を回避するために疎結合にしたもの」じゃないよ。プロセスが落ちることを前提にしたもので
パフォーマンスなんて考えてないというのは言い過ぎだが、フォールトトレラントでプロセスが落ちるから沢山のプロセスが起動できるようにした
ものであり、スケールアウトによる性能の保持はその結果に過ぎない。
「一億行・百万ファイル」このように初めから総数が分かっていれば分割できますが、総数が分かっていない場合には、「一行・10
823 名前：億ファイル」 かもしれない。この時に「絶え間なく処理結果が欲しい」ような場合だとスレッドを張り付けた処理は、分割された連続処理群が終わるまで 待たねばなりません。GoやErlangだとこのような処理の次に続く処理があった場合、パイプライン処理として処理します。 []: [ここ壊れてます]
824 名前：デフォルトの名無しさん mailto:sage [2022/02/21(月) 19:20:21.68 ID:GbKjQqyn.net]: >>805
> その考え方が古いでしょ
これがGo界隈のキモさだよね。自分らが先進的だと勘違いしてる。
なら、何故その先進的な言語がここまで無視されてるのか考えるべきだよ。
シェアで見たら、誰も使ってない言語だよGoなんてさ。
なおRustはポリコレを持ち込んだ馬鹿がいて同様にウザがられているが。

C#のスレッドは論理CPU数を越える起動用には最適化されてないはず。
だからそういう使い方をするためにはスタックサイズをいじらないといけない。
出来たはずだがやり方は知らん。
ただしそれやっても速くはならないよ。（Goもこの点は同じ）

> goroutineは軽量スレッド
これも嘘で、今探しても出てこないが、ラズパイ環境でゴミだったからNodeに戻ったというブログが有ったはず。
512MBのRAMで4kB/goroutineでは十分な量のgoroutineを起動できず、(なお今は2KB/goroutineも選べるんだっけ？)
Nodeでシングルスレッドで処理した方が断然速かったというもの。
Go信者はgoroutineのコストがゼロだと仮定しているが、まったくそうじゃない。
メモリも食うし、空間が別なんだからキャッシュの張替えも発生する。
(Cが地味に速いのはキャッシュにひたすらヒットするから、というのもある）

> チャンネルでfan in/fan outしてる。
意味分からんが、ハードウェアのゲートみたいに各チャネルが複数の入力/出力を持っててネットワークが割と複雑だって事か？
ただこの場合はイベントドリブンで組むことになってて、一応それが一番速いはず。
ハードウェアのゲートを１対１でgoroutineにすることはプログラムとしては記述出来るが、
1億ゲートとかだから4kB/goroutineではオーバースペック過ぎて無駄だ。
ゲートシミュレーションなら精々64Byte/goroutineとかじゃないと駄目だ。だけどこれは無理だろ。
(4kBに縛られてるのはCPUのページサイズに因っているから)
825 名前：デフォルトの名無しさん mailto:sage [2022/02/21(月) 19:28:42.96 ID:shT+MRih.net]: >>804
それに「Goにはこれがない。なおC#、.NET4.0の64bit環境では32767個のスレッドが上限らしい。」という中途半端な知識表現に
ついても一般的なOSではスレッドの上限は16bitの域を出ないで少ないのは当たり前で、それはスレッドがあまりにもOSにとっては
重すぎるから。(メモリやコンテキストスイッチなど払う代償が大きい）
Erlangはだいぶ思想が違うのはその通りだけど、GoはErlangほどではないが、小さいコストで多数の軽量スレッドを用意したもので
あり、これが何のために「Erlangで良いよね？」にならなかったのかといえば、背景にあるのは多数コアを搭載した近年のハードウェアを
生かし切れていない言語が溢れていたから
じゃあGoの役割はなんなのと言えば、Erlangはプロセスがネットワーク分散を簡単にできるが（その分遅め）、Goはコンパクトな
1つのマシンの中で上記のようなパイプライン処理をコンパクトに「なるべく早く」出来るよう考えられた。
826 名前：デフォルトの名無しさん mailto:sage [2022/02/21(月) 20:10:22.24 ID:shT+MRih.net]: >>810
あんたのほうがキモイけど、C#の先進性なんて何があるの？俺スゲーのシンタックスシュガーだけでしょ？C#がスタックサイズなんて
弄るのはJavaと同じで基本がClassであり、さらには意味不明な意識高いバカが再帰処理などでメモリーが足りなくなるからです。

シングルスレッド言語とマルチスレッドでメモリ量を比べて起動できないなんて意味ありますか？当然作り方次第でご自慢のC#も
同じになるはずですし、RustやCでも同じことが起こりえますが？逆に言えばGoであってもgoroutine数を少なめにして、スレッドで
アフィニティを設定して使用するCPUをPinningしてやればほぼシングルスレッドと同じ状態を維持できるはずです

「Go信者はgoroutineのコストがゼロだと仮定」これもダウトです、Goを始めたばかりの人だけです。こんなことを言っているのはｗ

膨大な配列を処理するときにCPUのコア数にきっちり分割して、間にコンテキストスイッチなどを挟まないほうが速いのは当たり前で
鬼の首を取ったように書かなくても多くの人はわかります。だが、Goの開発目的はそうではありません。同様に、Erlangのように
プロセスが落ちる前提で高い耐故障性を前提にするためでもありません。
また今はデフォルトは2kのスタックであり、「4kBに縛られてるのはCPUのページサイズに因っているから」とか、どこの知識なのか逆に
問いたいぐらいです。世の中いろいろなCPUアーキテクチャがありますが？現に多くのCPUは4kですが、s390は2kです

最速を求めるのであればGoもC#でもRustでもなく、ランタイムチェックのないCやアセンブラで書いてなさい。またCが速いのは
「キャッシュにひたすらヒットするから」ではありません。ランタイムチェックが無いからです、近年のマイクロベンチマークを１回でも
見たことありますか？近年のCPUのキャッシュサイズはMB級あるのを知っていますか？
827 名前：デフォルトの名無しさん mailto:sage [2022/02/21(月) 20:13:57.83 ID:889Qm57n.net]: >>810
お前読んでるか？
828 名前：デフォルトの名無しさん mailto:sage [2022/02/21(月) 20:27:03.44 ID:/1Q8PAGZ.net]: Goのランタイムのフットプリントはかなりでかいし、GCだけでなくそういうコストも許容できる贅沢な環境で、手抜きをして並列処理を書ける言語だよ

ようするに、RustやCで書くのはめんどいしメモリ食われてもいいけど楽してM:Nスケジューラ使いたい、みたいなときには適してる、っていえる言語ではないかと
非同期シングルスレッドしか使わない、っていうんならいろんな言語が選択肢に入りそう
829 名前：デフォルトの名無しさん mailto:sage [2022/02/21(月) 20:29:37.24 ID:LC1rF3os.net]: >>812
>「Go信者はgoroutineのコストがゼロだと仮定」これもダウトです

これ確かにGoroutineがコスト高いことを知らない人たちが意外に多い
例えばRustのタスクなんかはGoroutineに比べたら本当にコストゼロ
スタックレスであるし素朴な状態マシンとしてコルーチンとして機能するだけ
だからGoroutineよりリソース的にも軽いし起動も軽いし
巨大なランタイムを必要とするGoと違って非常にシンプル
830 名前：デフォルトの名無しさん mailto:sage [2022/02/21(月) 20:46:25.71 ID:GbKjQqyn.net]: >>809
いやErlangは電話交換機用に開発された言語で、メタル回線時代だから最初から物理で殴る前提だ。
（収容数が増えたらラックを増やすしかない）
プロセスどうのこうのはOSの話だ。ただしErlangが生まれた80年代はそこまで綺麗に分離してなくて、
ErlangのランタイムがOS扱いだったのだろうけど。
フォールトトレラント性も多分最初から考えられていたのだとは思う。

> 「一行・10億ファイル」
論理CPU数を数万倍越えるジョブがあると分かっているのなら、纏めればいいだけの話。
単に1ジョブ毎に放り込むのではなく、100ジョブ纏めて取ってきてから放り込めばいい。
原理的にはgoroutine*100と同じ速度が出る。
831 名前：デフォルトの名無しさん mailto:sage [2022/02/21(月) 20:54:53.07 ID:GbKjQqyn.net]: >>811
> 一般的なOSではスレッドの上限は16bitの域を出ないで少ないのは当たり前
そうじゃなくて、そういう風に作ってないだけ。
つまり、現行のOSでは、スレッドはそこまで使わない前提、そういう風には使わない前提だ。

> 小さいコストで多数の軽量スレッドを用意したものであり、
これをどう見るかだが、本来ならそれ用のOSを作らないといけないんだよ。
ただし実際はGoのランタイムでどうにかなる（=ハードウェアサポート無しでいい）から
そういう動きもないのだろうけど。

> Erlangはプロセスがネットワーク分散を簡単にできるが（その分遅め）、
> Goはコンパクトな1つのマシンの中で
これはその通り。Erlangは疎結合にしすぎてて、近年のハードウェア向きではない。
とはいえGoもまた行きすぎだよ。
論理CPU数を遙かに越える数のgoroutineを起動しても、速くはならない。
(ただ、コードは簡単に書けるだろうけど)
832 名前：デフォルトの名無しさん mailto:sage [2022/02/21(月) 21:16:05.40 ID:GbKjQqyn.net]: >>812
一応言っておくが、俺はC#書いてないぞ。

> C#の先進性なんて何があるの？
いや色々ありまくりだろ。asyncもlinqもそれ以外も色々有ったと思うけど。
今現在メジャー言語で一番先頭走ってるのはC#だろ。
それぞれの機能は他マイナー言語で既にあった物を取り込んだだけなのかもしれんけど。

> C#がスタックサイズなんて弄る
基本いじらないけどね。
デフォで2Mのはずで、少々アホな再帰をやったところで埋まらない。

> シングルスレッド言語とマルチスレッドでメモリ量を比べて起動できないなんて意味ありますか？
これは書き方が悪かったか？
要はラズパイみたいに貧弱なハードウェアだとGoは機能せず、Nodeの方が速いというだけの話。
goroutineで楽して速いってのは贅沢なハードウェアありきの話。
なおJSはCPUをひたすら突っ走らせる構造にすることをプログラマに強制するから、
その分CPUは無駄なく動く(スタックとかが小さくて済む)ので
同一ハードウェアだと他言語でシングルスレッドにするよりは原理的に速いけど。
(実際は動的言語の分遅いが、TSコンパイラとかが出てくれば面白くなるとは思う）

> s390は2kです
ほう、メインフレームのはそうなんだ。初めて知ったよ。
ただ知ってるつもりなら、現行で普通に使われてるCPU、例えばx86なりARM等で4kじゃない奴を挙げてみろよ。
ないと思うぜ。

> 「キャッシュにひたすらヒットするから」ではありません。ランタイムチェックが無いからです
違うぞ。ランタイムチェックがないのも要因の一つで、RustやJavaの連中の言い訳になってるが、
それだとCとC++でCの方が速い理由を説明出来ないだろ。
833 名前：デフォルトの名無しさん mailto:sage [2022/02/21(月) 21:18:38.69 ID:NEAxhla5.net]: で、Rust vs GoだとConcurrencyどっちがすごいんよ？
https://deepu.tech/concurrency-in-modern-languages-final/
https://i.imgur.com/JGoa8Xe.png
これだとRustがさいつよらしいけど
834 名前：デフォルトの名無しさん mailto:sage [2022/02/21(月) 21:25:14.63 ID:/1Q8PAGZ.net]: そら最速を求めるならクソデカランタイムが仕込まれてるGoが勝てるわけがない
835 名前：デフォルトの名無しさん mailto:sage [2022/02/21(月) 21:25:40.43 ID:GbKjQqyn.net]: >>813
ああすまん、リンクは完全に失念してた。

で、読んだが、何だ？知ってたような内容しか書いてないが。
わざわざ指摘してくるのだから、fan in/fan out の説明があるのかと期待したが。
836 名前：デフォルトの名無しさん mailto:sage [2022/02/21(月) 21:51:34.63 ID:889Qm57n.net]: 書きやすさ&ビルドのしやすさ、なんてのも実務的には大切。
ザクッと書いてクロスでコンパイルして大量のサーバに撒く、がめちゃくちゃ楽だよ。
837 名前：デフォルトの名無しさん mailto:sage [2022/02/21(月) 21:52:17.85 ID:889Qm57n.net]: >>821
実際、軽量スレッドな事は知らなかったじゃん。
知ってたような事が書いてたけど誤解してたの？間抜けだな。
838 名前：デフォルトの名無しさん mailto:sage [2022/02/21(月) 21:56:26.38 ID:NpsKB2au.net]: >>819
フレームワークを使うともっと速くなるみたいで、最初はRust負けててactix使ったら勝ったらしい
フレームワークのベンチならこっちにある
https://www.techempower.com/benchmarks/
フレームワークを使わないケースだと、同じような実装にする努力の跡は見えるが、結果が言語単品の性能を表しているのか標準ライブラリの質を表しているのか、はたまた測り方なのか、何を表しているのかは知らない
839 名前：デフォルトの名無しさん mailto:sage [2022/02/21(月) 22:05:32.26 ID:GbKjQqyn.net]: >>823
いや知っててあの内容だが？
それで納得出来ないのならそれでいいが、
goroutineは軽くはないし、ゼロコストでは全然無いよ。
840 名前：デフォルトの名無しさん mailto:sage [2022/02/21(月) 22:10:46.33 ID:jpP0Lzmf.net]: >>819
サンプルコード見たけど酷いな
言語そのものの速度を比較するためのものとは思えない
典型的スクリプトキディのおじさんだ
841 名前：デフォルトの名無しさん mailto:sage [2022/02/21(月) 22:19:17.65 ID:GbKjQqyn.net]: >>819
本文は全部読んだ。(コードまでは見てない)

まずグラフがどうかだが、これを信じるなら、
Rusr/Java/Goは妥当、異様なのはJS(multi-threaded)の速さだよ。

詳細は本文に書いてあるけど、色々苦労してる。
問題はGo(HTTP)がぶっちぎりに速かったので、これは何だ？って事で、
どうやらライブラリの最適化に因るらしく、
わざわざ他言語でも最適化ライブラリを持ってきて比較し直してる。
で、Rustの方がGoの倍速く、JavaはRustと同程度（微妙に速いが）とかなってる。

ただこれ見る限り、CPU時間とかバラバラだし、
最適化ライブラリを用いたらRust/Java/Goどれも6倍になってるので、
言語の差よりもライブラリの最適化の方が断然重要って事になる。
本人は言語の実力の差をベンチマークしたかったのだろうけど、
ライブラリの最適化で6倍も変わる状況で言語での差をあぶり出すのは難しい。

本人が結論に書いてある事はまあ同意。なお、
> The community consensus when it comes to concurrency performance is quite split.
> For example, both Rust and Go communities claim to be the best in concurrency performance.
842 名前：デフォルトの名無しさん mailto:sage [2022/02/21(月) 22:26:10.00 ID:889Qm57n.net]: Goは何も考えんでも、公式の実装がハズレ無いのでオーダーさえ考えて実装してれば間違いは無い。
まぁ、そもそもオーダーの計算を失敗しがちなmapとかflatMap無いからな。全部ループ。
そのおかげでめちゃくちゃキャッシュにきれいに載るというのもある。
思ってるより早いよ。
843 名前：デフォルトの名無しさん mailto:sage [2022/02/21(月) 23:09:18.19 ID:NpsKB2au.net]: まあ一応書いておくと、最適化云々言ってるけど、標準ライブラリのコンパイルオプションを変えたのでなく、標準ライブラリをactixで書き換えただけな
■標準ライブラリ版(遅い)
https://github.com/deepu105/concurrency-benchmarks/blob/nosleep/rustws/src/main.rs
https://github.com/deepu105/concurrency-benchmarks/blob/nosleep/rustws/src/lib.rs
■actix版(クソ速い)
https://github.com/deepu105/concurrency-benchmarks/blob/nosleep/rust_actixweb/src/main.rs
844 名前：デフォルトの名無しさん mailto:sage [2022/02/21(月) 23:34:23.82 ID:58fVbJqw.net]: >>819
.NET他環境の半分程度の性能しか出ないのかよ
C#おじさんのご高説はなんだったの？戯言？
845 名前：デフォルトの名無しさん mailto:sage [2022/02/22(火) 00:01:25.72 ID:ZREIq5yi.net]: >>830
Goも同程度に遅いけどな。
と言うかこれはUndertow(Java)がずば抜けて速いんだよ。これは本人も書いてるとおり。

本来は

Rust(ネイティブ、ランタイム無し)
Go(ネイティブ、ランタイムあり）
Java/C#(VM)

の順になって然りで、VMと同レベルになってしまってるGoは遅すぎ。
C#は一応ネイティブにする方法はあるらしい。
VMからネイティブにすれば本来は1.5～2倍速程度は期待出来る。
https://docs.microsoft.com/ja-jp/windows/uwp/dotnet-native/
現在これが現実的に使えるものなのかは知らん。

ただまあ、同速しか出ないのなら、Goを選択する理由はないだろ。
まともな頭ならC#を選択する。
サーバーシェアだけでも10,000倍違うし、しかもC#の主戦場はunityであって
ASP.NETなんて連中からするとオマケかもしれない状況でこれだ。
ただしC#は重量級であって、日曜大工でやろうというものではないが。
846 名前：デフォルトの名無しさん mailto:sage [2022/02/22(火) 00:59:20.84 ID:5DTzEoeU.net]: >>831
C#のAOTはこのケースにはあんまりきかないない。
なおそこてはなくてこっち。
https://github.com/dotnet/runtimelab/blob/feature/NativeAOT/docs/using-nativeaot/README.md
刺さるときはめちゃくちゃ刺さる。制約にひっかからないかぎりよく使うよ。
ただこれでもダメならGo書いた方が楽。

Goらしいコードが書けてないのでは？と言う印象だな。

C#の主戦場はUnityは言い過ぎでは？
お前業務システムエアプ勢か？
847 名前：デフォルトの名無しさん mailto:sage [2022/02/22(火) 01:39:15.30 ID:RKLGE56l.net]: >>831
コネクション増える程.NETの性能悪化してgoとの差開いてるだろ
都合の悪い所は見えなくなるのか？
848 名前：デフォルトの名無しさん mailto:sage [2022/02/22(火) 02:23:56.90 ID:UcWMEN5O.net]: >>819
なんでこれdotnetはDebugビルドで実行してるの？？
849 名前：デフォルトの名無しさん mailto:sage [2022/02/22(火) 10:13:55.17 ID:Ixlcctuc.net]: >>818
「ランタイムチェックがないのも要因の一つで、RustやJavaの連中の言い訳になってるが、それだとCとC++でCの方が速い理由を説明出来ないだろ。」

おまえ酷い言い訳ばっかだな？ C#のLinqなんて正にシンタックスシュガーだろ。2MBもスタックとってる糞言語やってて口だけ饒舌でよく恥ずかしくないね？
「貧弱なハードウェアだとGoは機能せず」そんなことはありません、ラズパイのようなハードウェアを使ってGoogleはkubeクラスターと似た機能をN1クラスタで
使ってGoやRustで使用しています、ハードウェア使用効率の良くないNodeでなんか（ほとんど）使用していません。

Nodeが早いのはV8が速い（=Cで書かれている）からであり、「JSはCPUをひたすら突っ走らせる構造にすることをプログラマに強制」などと
いう嘘出鱈目で相手の反応を誤魔化すためではありません。JSが言語特性として速い訳ではありません。どう見ても言語に型が本来は無い
言語に速くなる要素があると考えられますか？TSが型を持った言語だとしてもしょせんはJSへのトランスレーターです。

さらにJSの次に使用されているwasmはページサイズは64Kでありx86なりARM等であっても2kに比べたら非常に大きなメモリー管理をされています。
あなたの言う4k/2kでもデカい64Bじゃないとと比べると実に1000倍です。「挙げてみろよ。ないと思うぜ。」こういう態度があなたを周りの人から
敬遠される１つの要素です。自分で調べもせず、コードで計測したこともなく、伝聞で偉そうな態度は馬鹿にされる要素の１つでしょう

また「CとC++でCの方が速い理由を説明出来ない」これがキャッシュのおかげにして説明できないのはあなたがプログラムをほとんど書いたことが
無いからです。配列などの連続するデータをループ処理するときに、if文などのCMP命令が1つ挟まれば、プログラムは低速化します。ループ１回に
付きCPU命令1つで済む処理では、if判定するために2つ以上になるため、多くは2倍程度低速化します。
これは、GoやRustなどは、範囲外にアクセスしてないか常にRange Bounds checkingで行っています。unsafeコードでも外せません。決して
キャッシュおかげでも、あなたの足りない語彙のせいでもありません。
850 名前：デフォルトの名無しさん mailto:sage [2022/02/22(火) 11:00:46.11 ID:Ixlcctuc.net]: >>827
>>831
また多くのweb系のベンチマークの使用にされているRequest/Secは速さの指標の１つですが、本来は現実的にユーザーに利益のある
レテンシー速度のほうが近年は重要視されます。Javaや比較的昔からあるメジャー言語が速くみえるのは、歴史を積み重ねて最適化が
施されているからです。決して言語特性として速い訳でありませんし、Request/secを主眼とした速さの議論は、海外でも馬鹿にされます

RustがRequest/secで多く処理できるのはベンチマークなどの超高負荷環境においてgcが走らないからです。現実的にいえばそのような
環境で運用するのではなく、分散させてサーバーを複数立てるのが本来望ましい。上にあげられたような条件も見えない画像で判断する
のではなく、重要なのは99%タイルにおける高並列において応答のレテンシーが数秒以内に収まり、なおかつRequest/secが出せることで
あり、50%の応答速度が最悪、20秒になってしまうような使い物にならないものを比べるべくもありません

https://web-frameworks-benchmark.netlify.app/compare?f=fiber,aspnetcore,express,actix
851 名前：デフォルトの名無しさん mailto:sage [2022/02/22(火) 12:57:29.93 ID:G6nBeheJ.net]: 一応訂正しておくよ。以前書いたフレームのベンチでも
https://www.techempower.com/benchmarks/#section=data-r20&hw=ph&test=plaintext
このベンチが一番近いはずだが、nodejsは決して速くない。
js勢だとjustが速い。
852 名前：デフォルトの名無しさん mailto:sage [2022/02/22(火) 20:04:57.30 ID:B2H8wIkZ.net]: > Goらしいコードが書けてないのでは？と言う印象だな。

ある程度書いてないとらしさみたいなもんは分からんわな
どんな言語でも
よってここに天下一武道会を開催する
各言語のらしさの粋をあつめたコードで
Concurrencyの雌雄を決したい
853 名前：デフォルトの名無しさん [2022/02/22(火) 20:10:03.17 ID:Y6BYhUSt.net]: >>837
nodejsはフレームワークとは言えんような。
justはnodeインストールしてなくても動くのかい？
854 名前：デフォルトの名無しさん mailto:sage [2022/02/22(火) 20:45:10.67 ID:WirMN8li.net]: >>838
まずはぜひGoらしいコードを叩き台として出して
855 名前：デフォルトの名無しさん mailto:sage [2022/02/22(火) 20:59:43.80 ID:G6nBeheJ.net]: 自分で手を動かせ
誰かに何かを「やってもらう」ところじゃねーんだよ
自分でできないやつは書き込むな
856 名前：デフォルトの名無しさん mailto:sage [2022/02/22(火) 21:28:03.19 ID:ZREIq5yi.net]: >>835
なるほど君が色々分かってないのは分かった。
が、まあ、これは後日だ。

>>836
その比較見てもGoが.NETに勝ってるようには見えないよ。
スループットは劣るが、レイテンシなら.NETの方が伸びないようにチューニングしてある。
そちらの主張するようにレイテンシの方が重要なら、.NETの方がいい。

GoとJSの比較のつもりなら、どうせならNANOexpressを使ってみては？
https://web-frameworks-benchmark.netlify.app/compare?f=fiber,aspnetcore,actix,nanoexpress
ほぼ全部のグラフでJSの方が上になってしまうが。
home見れば分かるけど、fiber(Goで最速)、.NET(C#で最速)、actix(Rustで最速）でexpress(JSでは27番目)は比較として酷いだろ。
知名度で選んだだけかもしれんけど。
nanoexpressが使えるレベルの仕上がりかどうかは知らんが。
857 名前：デフォルトの名無しさん mailto:sage [2022/02/22(火) 21:46:51.86 ID:ZREIq5yi.net]: >>832
> > 制約にひっかからないかぎり
> 動的ロード無し
> evalなし
> COM/WinRT相互サポート無し
> リフレクション無し
まあ普通に静的言語のノリで書いてたら大丈夫だとは思うが。

>>837
俺はサーバー系JSの総称としてNodeと言ってた。
フレームワークを正確に識別する気だったらすまん。

justだとNodeの10倍なら、819のベンチで他言語が6倍速になってるのと同様だから、それなりの値になるのだろう。
いずれにしても言語の特性なんてフレームワークの最適化の陰に隠れてほぼ見えないね。

>>839
just-jsは多分これ。
https://github.com/just-js/just
> A very small v8 javascript runtime for linux only
というわけでNodeの代わりだな。ただしドキュメントがないので実体は不明。
justというほぼ同じ名前の、ただしGitHub垢は別の物があるのだけど、これと組み合わせて使うのかな？
https://justjs.github.io/
858 名前：デフォルトの名無しさん mailto:sage [2022/02/22(火) 21:49:46.37 ID:5DTzEoeU.net]: 別に.netをディスってる訳では無いんだが、代理戦争みたいな真似する理由がわからん。

GoがWebフレームワークのベンチマーク弱い理由はだいたいこの記事にまとまってる。
https://zenn.dev/nobonobo/articles/e651c66a15aaed657d6e
同じ事したら他のフレームワークと同じかもう少し早い。

ヘイトに関してはだいたいこれじゃん。
https://zenn.dev/nobonobo/articles/74808a8d5e6f1e
859 名前：デフォルトの名無しさん mailto:sage [2022/02/22(火) 21:50:53.96 ID:5DTzEoeU.net]: >>843
ホントにやってみて言ってるか？ひっかかるぞ。
860 名前：デフォルトの名無しさん mailto:sage [2022/02/22(火) 22:01:34.94 ID:ZREIq5yi.net]: >>845
リフレクションを常用してるのなら、それは基本的にお前の組み方が悪い。
861 名前：デフォルトの名無しさん mailto:sage [2022/02/22(火) 22:03:10.10 ID:WirMN8li.net]: >>844
「GoがWebフレームワークのベンチマーク弱い理由」が書かれていない記事に見えるがリンク合ってる？
862 名前：デフォルトの名無しさん mailto:sage [2022/02/22(火) 22:43:58.08 ID:jMOKvXgm.net]: >>834
これ。Debugビルドでやって何の意味があるの？そりゃあ最適化されてなかったら遅いわ…
863 名前：デフォルトの名無しさん mailto:sage [2022/02/22(火) 23:07:19.97 ID:B2H8wIkZ.net]: >>844
> https://zenn.dev/nobonobo/articles/74808a8d5e6f1e
> Rob Pike氏はあらゆる既存のプログラミング言語が互いに発案した特徴を取り込みあって、
> あらゆる言語が同じような言語に向かっていることに異を唱え、そうではない言語を作ろうとして
> (略)
> Goのアイデンティティのひとつに「厳選された必要十分な機能セット」というものがあり、
> 過去ここを壊すような多くの提案には「No!」が突き付けられてきました。

Goはなんか言語としてのウリが弱くて
逆に言語としての機能不足を非難されたりするけど
ここにC++を持ってくると急に腑に落ちるな
ブヨブヨに肥大したC++の現状の惨状を見ると
そらロブの言いたいことも分かるってもんよ
Goに対する一部の批判はそら的外れってもんよ
864 名前：デフォルトの名無しさん mailto:sage [2022/02/22(火) 23:13:49.19 ID:S7d5HFwX.net]: かなり後発のRustが先発言語たちから厳選された機能を洗練して上手く採り入れていって
純粋に言語としての比較ではGoを抜き去って行った感がある
865 名前：デフォルトの名無しさん mailto:sage [2022/02/22(火) 23:17:51.21 ID:6QeruhOo.net]: 個人的に趣味でゲーム作ってて、
（仕事はPythonとかのスクリプト言語）
そのバックエンドに高速そうなGo使おうと思って勉強してるんだけど
そういうレベルの俺からするとRustはものすごく難しそうというか、厳しそうに思えてしまうんだよな
メモリリークって一番やりそうだもん
866 名前：デフォルトの名無しさん mailto:sage [2022/02/22(火) 23:25:51.36 ID:WirMN8li.net]: >>851
何か勘違いしてない？
RustはC言語と違って
使われなくなった瞬間に自動的にメモリ解放してくれる言語
867 名前：デフォルトの名無しさん mailto:sage [2022/02/23(水) 00:01:15.68 ID:LYKR6qmH.net]: >>846
リフレクション以外もひっかかる。
試してから言え。

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

実際、Goのサードパーティライブラリ「fasthttp」はHTTPヘッダパース遅延評価機能を持っており、この場合ベンチマーク結果の数値は最速実装にかなり近づきます。しかし、HTTPヘッダは実用の現場の場合、評価しないわけにはいかないので実用上の性能は標準のnet/httpと大差ないということが実際にあり得ます。
868 名前：デフォルトの名無しさん mailto:sage [2022/02/23(水) 00:49:45.29 ID:eS2QASPG.net]: >>852
ガベージコレクションが無いって事しか知らない
違うのか
ってかスレチかもすまん
869 名前：デフォルトの名無しさん mailto:sage [2022/02/23(水) 06:07:59.41 ID:hfe0Ou5T.net]: >>854
Rustは使われなくなったら即座に自動的にメモリを解放してくれるため
ガベージコレクションを必要とせず速い
870 名前：デフォルトの名無しさん mailto:sage [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なんて
恥ずかし気もなく言い出せる。オープンソースなんだからコードぐらい追えよ？
871 名前：デフォルトの名無しさん mailto:sage [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の熟練者になる必要はない。ただ、知っておく必要はある。

この辺最近、こいつらはこの処理が何故重いのか全く理解出来てないんだな、と感じ
872 名前：る事が多い。 これはコンピューターが複雑化した事もあるが、コンピューターの物理面を知らないで済ませようとしてるからだ。 （論理的なプログラミングに留めている。それを目指したのがJavaでもあるのだが） だからベンチマークに頼らないといけなくなる。何故それが速いか遅いかを自分で判断出来る能力がないからだ。 だからこの辺、自分で判断出来る能力が欲しければCをやるべきだし、 とはいえ現実的にはフレームワークを使うわけで、フレームワークが最適化されてればそれで良し、駄目なら駄目、 と一生ベンチに頼るのもありだし、現実的にこれでも大した問題がないのも事実だろう。 この場合はCなんてやるだけ無駄、ってことになる。だからどういう能力が欲しいかを自分で考えるべきだね。 ちなみにRustもTSもNodeも無かった時代に同じ事を聞かれるとGoと答えただろう。 Go界隈の最大の問題はここで、最初に運良くブーストした？のに浸ってる。 今はもう違う事を認識出来てない。 []: [ここ壊れてます]
873 名前：デフォルトの名無しさん mailto:sage [2022/02/23(水) 09:13:45.39 ID:hfe0Ou5T.net]: >>857
なぜ不便なCを勧めるのか理解できない
Cをやるくらいなら自動的にメモリを解放してくれるRustが楽で良い
スクリプト言語と似た感じで便利にプログラミングできる点も良い
874 名前：デフォルトの名無しさん mailto:sage [2022/02/23(水) 09:22:59.07 ID:bUSsBe0W.net]: Cもなんだけど、TSなんか特に。
マルチコア使うのがめちゃくちゃ下手な言語を、どうしてGoの対抗馬に持ってこれるの？
それら全ての言語を使ってないのでは？

nodeはnodeで便利だがGoと代替にはならんよ。
RustはRustで早いけどGoの代替には簡単にはならない。
875 名前：デフォルトの名無しさん mailto:sage [2022/02/23(水) 09:27:29.73 ID:3VU0Qb68.net]: objective-c: objectiveが売りなんで頭にもってきたネーミング
c++: cのフリしつつ拡張するつもりの邪悪なネーミング
go: いちにーさんしーごーでシンプルにしーの後に躍り出る命名
876 名前：デフォルトの名無しさん mailto:sage [2022/02/23(水) 09:46:33.29 ID:7ZO0r/jE.net]: >>858
モロクソ書いてるだろ。3行しか読めない馬鹿か？

オレオレゲーム鯖立てるつもりならJS/TS、個人ゲーで負荷的に無理になることはまず無いし、フロントエンドでどのみち使うし。
コンピューターについて学ぶつもりならC、Rustを先にやったところでRustを使えるようにしかならない。
現段階でGoを選ぶ理由がない。Goを学ぶ事が目的ならどうぞだが。
877 名前：デフォルトの名無しさん mailto:sage [2022/02/23(水) 10:36:48.23 ID:EqZ7VJsi.net]: フロントエンドなら最近はWASMが増えてきて記述言語で一番適していて多数派がRustといった状況
もちろんサーバーサイドもRustで行ける
Goは巨大ランタイムのせいでWASMと相性がよくない
878 名前：デフォルトの名無しさん mailto:sage [2022/02/23(水) 11:07:50.59 ID:bUSsBe0W.net]: >>862
そもそもGoは外部と相互運用する事を前提としてない言語だと思う。
少し互換性は失われるけど、isomorphicにしたいならTinyGoかなぁ。
879 名前：デフォルトの名無しさん mailto:sage [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);}));})();
が普通に実行できる。並列かどうかは知らない。
880 名前：デフォルトの名無しさん mailto:sage [2022/02/23(水) 12:45:46.30 ID:gMbnXrXW.net]: JSである以上、asyncなんて書いてもコールバックであり並列でもなければ、平行ですらありません。というかほんの数年前のJS使いなら
setTimeout()と書いて非同期タイマー呼び出しぐらい理解してるはずなんだが？今では、Nodeなら、nextTick()だろうけど
普通に実行できるとか、そりゃ言語仕様としてGoogleが携わってるV8使ってんだから出来るでしょうよｗ
just-jsおじさんｗ
881 名前：デフォルトの名無しさん mailto:sage [2022/02/23(水) 13:09:37.82 ID:bUSsBe0W.net]: JavaScriptのアーキテクチャが良いと言うのもよくわからんよな。
シングルスレッドだし、別プロセスは前から立てれたが、別スレッドを満足に立てられるようになったのは最近。

epoll使ったイベントループの事を褒めるのであれば、それこそGoのselectの方が賢いんだし。
882 名前：デフォルトの名無しさん mailto:sage [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が使えることを示した。
並列になることを期待している可能性もあったが、コードを追って確認したわけではないので、単に「知らない」と書いた。
883 名前：デフォルトの名無しさん mailto:sage [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でも出来るはずだが、やろうとした事はなかったな…)
884 名前：デフォルトの名無しさん mailto:sage [2022/02/23(水) 15:51:46.27 ID:vCUIsgzX.net]: >>868
just-jsのjustコマンドはnodejsのnodeコマンドに相当
consoleオブジェクトがないなど癖が強いので、一般利用なら個人的にはnodeでいいと思う
885 名前：デフォルトの名無しさん mailto:sage [2022/02/23(水) 19:44:15.21 ID:bUSsBe0W.net]: >>868
はびこってるのか理解できないと言うのは誰かと間違ってないか？
俺はnodeはnodeでアリだがGoの分野とは相容れないと言ってるんだが。
考えないと早くならないcppやrustと対比させてるのであって、jsとは全く対比させてない。
886 名前：デフォルトの名無しさん mailto:sage [2022/02/23(水) 21:47:24.05 ID:EqZ7VJsi.net]: >>865
それはJavaScriptに対してあまりにも無知すぎる
async/await登場以前からJSは並行プログラミング言語
async/awaitはどの言語でも同じだがそれを同期して同期風に記述できる付加機能
ちなみにworkerによってJavaScriptは並列プログラミングも可能
887 名前：デフォルトの名無しさん mailto:sage [2022/02/24(木) 02:41:19.56 ID:aoL+Ya6Q.net]: >>871
上の「 (async()=>{await Promise.all()」がどこに並列があって、関係のないworkerに話が飛ぶんだｗ誤魔化しマウント野郎ｗ
ウッホウッホホ、ドラミングｗ
おまえのご自慢のnanoexpressとかjust-jsのどこにworkerが使われてるんだ？
888 名前：デフォルトの名無しさん mailto:sage [2022/02/24(木) 02:56:09.99 ID:aoL+Ya6Q.net]: >>868
使ったことないのに言い出す奴ｗｗｗ
「JSが何故ここまで蔓延ってるのか」C#おじさんの全方位敵対ｗ
889 名前：デフォルトの名無しさん mailto:sage [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関連の並行性について話をするなら上記の初歩的な知識は必須な基本事項
890 名前：デフォルトの名無しさん mailto:sage [2022/02/24(木) 03:12:11.21 ID:gyy9N0gw.net]: 並行か？ioか無いとスレット取りっぱなしでラ？
891 名前：デフォルトの名無しさん mailto:sage [2022/02/24(木) 03:15:40.31 ID:yGsnJUen.net]: あっそ、じゃあGoスレじゃなくNodeスレで一人語ってくださいね？言語以前に人としてのマナーを学びましょう
892 名前：デフォルトの名無しさん mailto:sage [2022/02/24(木) 03:22:14.88 ID:9O+r6lMK.net]: >>874
Goの適用範囲のメインがウェブ周辺なのにも関わらずそういう基本的な知識すらないやつ時々いるよな
あと他の言語を知らずしてGoの良い点も悪い点も語れないしな
893 名前：デフォルトの名無しさん mailto:sage [2022/02/24(木) 03:28:06.36 ID:z0JbsGq8.net]: >>875
並行と並列の違いも理解できてないから、あんまり相手にしてもしょうがないよ。Goも知らないっぽい・・・
Goはgo呼び出ししなくてもメインルーチェンがgoroutineだし
894 名前：デフォルトの名無しさん mailto:sage [2022/02/24(木) 03:28:15.25 ID:gyy9N0gw.net]: Goのメイン、Webでは無いだろ。
自分の分野がWebだからハンマー釘になってるのでは？
895 名前：デフォルトの名無しさん mailto:sage [2022/02/24(木) 03:29:04.26 ID:gyy9N0gw.net]: >>878
そうよね…なんか凄く脱力感あるわ…。
この文脈でTSを推す理由が全くわからん。
896 名前：デフォルトの名無しさん mailto:sage [2022/02/24(木) 03:36:49.68 ID:QeQ2VGy/.net]: >>878
君が理解出来ていないのではないか
JavaScriptはWorker使わない限り全て並行であり並列ではない
もちろんWorkerを使えば並列も可
まさかと思うがGoではどうなのかも理解できていなかったりする？

>>880
TSなんて書き込みをしたこともないのでそれは別人だぜ
897 名前：デフォルトの名無しさん mailto:sage [2022/02/24(木) 03:41:58.08 ID:dTNpqM+n.net]: 内容ゼロの真逆のことを言い出した…
Goのメインはパイプラインデータ処理のバッチ系のほうが大きいと思うね、確かにメニーコアをあまり無駄なく活用するからwebも使えるけど
898 名前：デフォルトの名無しさん mailto:sage [2022/02/24(木) 03:45:18.78 ID:9O+r6lMK.net]: 自分と異なる意見を書いてるやつは敵であり、敵はそいつ一人
という思い込みパターンは5chではよくあるな
899 名前：デフォルトの名無しさん mailto:sage [2022/02/24(木) 03:48:08.63 ID:6w5SyGQZ.net]: ID:QeQ2VGy/
「JavaScriptは基本的に全て並行プログラミングであって並行に動作する」
「JavaScriptはWorker使わない限り全て並行であり並列ではない」

(笑)解離性同一性障害かなんなのか、当てるスレ。もうさjavascriptもgoもrustも関係ないなあ
900 名前：デフォルトの名無しさん mailto:sage [2022/02/24(木) 03:50:57.70 ID:QeQ2VGy/.net]: >>884
どちらも正しいが何を言いたい？
JavaScriptは基本的に全て並行であって並列ではない
Workerという後から追加された機能を使ったときのみ並列動作が可能
901 名前：デフォルトの名無しさん mailto:sage [2022/02/24(木) 03:54:14.80 ID:9O+r6lMK.net]: おそらくだけど>>884氏は並行と並列の違いをわかっていないために誤読
さらに暴走して解離性なんちゃら言い出しただけかと
902 名前：デフォルトの名無しさん mailto:sage [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なわけです。
903 名前：デフォルトの名無しさん mailto:sage [2022/02/24(木) 07:44:45.85 ID:7j5xGGNI.net]: >>887
jsは自前でsleepしてないから妥当すぎてなんとも
シングルスレッドな言語で自前でsleepしてたらイベントも受けとれんわ
時間が来るまで処理のスイッチがなされないだけ
904 名前：デフォルトの名無しさん mailto:sage [2022/02/24(木) 08:26:03.01 ID:gyy9N0gw.net]: >>881
そうだね。そのWorkerがクソ重いって言ったぞ。
worker跨ぐ並行並列の話では？C#のasync awaitは。

Goはworkerを立てずともなってる。
905 名前：デフォルトの名無しさん mailto:sage [2022/02/24(木) 08:27:43.23 ID:gyy9N0gw.net]: >>887
sleepではなく切れ目無くCPUをガンガンに使う処理入れようか。
906 名前：デフォルトの名無しさん mailto:sage [2022/02/24(木) 08:40:42.53 ID:7t2RQWHZ.net]: >>861
Rust界隈は>>858みたいなバカ多いから……いわゆるゴールデンハンマー。

Rustはもっと学習メソッドと設計思想の解説を強化すべきだと思うわ。一番厄介な所有権についても、実行速度とメモリ安全を両立させるためにどういう管理をしているのか説明すればわかりやすいのに。
907 名前：デフォルトの名無しさん mailto:sage [2022/02/24(木) 08:47:04.56 ID:r4yoOnDZ.net]: sleep自慢なわけです。C#とasyncから始まった今ここに集まってくる奴らは、道具を眺めて優れた何かを作ってない口だけ
自分で作ってもいない日本刀の刀身眺めてニヤニヤしてる気持ち悪いマニアと一緒
908 名前：デフォルトの名無しさん mailto:sage [2022/02/24(木) 08:59:42.43 ID:9O+r6lMK.net]: >>890
スケジューラの類いを作ってことあるプログラマーならば
sleepとは時間が来るまでそのタスクが寝るだけだあって
その間に他のタスクが動くことくらいわかりそうなものだが理解できないのか？

>>888
sleepなどのタイマー類はスケジューリングランタイムが提供すべきものであって自作するものではないぞ
909 名前：デフォルトの名無しさん mailto:sage [2022/02/24(木) 10:19:55.02 ID:gyy9N0gw.net]: >>893
そもそもsetTimeoutで完全にCPUを明け渡してて何が「並行」なんよ。
910 名前：デフォルトの名無しさん mailto:sage [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できる
911 名前：デフォルトの名無しさん mailto:sage [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やる事はほぼ無いからいいんだが。
912 名前：デフォルトの名無しさん mailto:sage [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になってしまうし。
913 名前：デフォルトの名無しさん mailto:sage [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#は変節に変節を重ね、筋が良かったとは言いがたいが、その時の便利機能を取り込み続けた結果、
「今一番生産性が高い」の地位は何だかんだで保持してる。
914 名前：デフォルトの名無しさん mailto:sage [2022/02/24(木) 12:48:03.88 ID:4cQqvqtW.net]: ひたすら独り語り
915 名前：デフォルトの名無しさん mailto:sage [2022/02/24(木) 12:50:56.09 ID:gyy9N0gw.net]: 自分にある引き出しでしか喋ってないのな。
Go書いたこと結局無さそう。

TS早くないってば。
916 名前：デフォルトの名無しさん mailto:sage [2022/02/24(木) 12:53:50.71 ID:rd5PFIsb.net]: 結局最後は速さにこだわりはじめてRustにすればよかったって流れなんだよな
917 名前：デフォルトの名無しさん mailto:sage [2022/02/24(木) 13:24:03.51 ID:QeQ2VGy/.net]: >>901
たしかに速さ目当てでRustにも手を出したが
言語としての機能が豊富でGoよりもプログラミングが快適ということに気付いた
918 名前：デフォルトの名無しさん mailto:sage [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がモロパクしたわけだが。
919 名前：デフォルトの名無しさん mailto:sage [2022/02/25(金) 04:57:49.84 ID:aDhOSI3t.net]: その長い主張はまとめるとこういう主張？
言語機能が貧弱なGoは普通のプログラマーにとっては使いづらいだけの存在だけど
豊富な機能や複雑な機能を使いこなせない劣ったプログラマーにとっては需要がある
920 名前：デフォルトの名無しさん mailto:sage [2022/02/25(金) 05:03:43.53 ID:3Y4Z8gJm.net]: rust良いんだけど特定の種類のプログラム
例えば赤黒木とか二重リンクリストみたいなポインタを操作しまくるようなプログラムは明らかに向いてないんだよな
921 名前：デフォルトの名無しさん mailto:sage [2022/02/25(金) 08:15:32.32 ID:TaGUkQP3.net]: >>905
unsafe使いまくるから、野良ライブラリに任せないで標準ライブラリ用意して欲しいよな。
922 名前：デフォルトの名無しさん mailto:sage [2022/02/25(金) 08:30:45.32 ID:u7rOKKj6.net]: >>906
それは標準ライブラリの位置付けに誤解がある
Rustでは最小限のものしか標準ライブラリに入れない方針を明確にしている
だから各用途ごとの重要なライブラリは全て外部にある
例えばasync/awaitやFutureの枠組みは言語仕様と標準ライブラリにあるが
そのための非同期ランタイムは外部にある

あとunsafeの認識は大丈夫と思うが念のため
unsafeは内部に閉じ込めて安全な公開インタフェースを持つ型(type)やモジュールを作るために存在している
だから標準ライブラリも内部はunsafeだらけだが公開インタフェースを用いる限り安全が保証されるといった具合い
どのような安全なインタフェース体系にするかは用途ごとに異なるためそれぞれに適したライブラリを選ぶか自作すればよい
923 名前：デフォルトの名無しさん mailto:sage [2022/02/25(金) 08:39:36.17 ID:ifNOEbaN.net]: >>903
文系理系の切り方も謎だけど、
「適切なところに適切な道具を持ってくる」というのはエンジニアリングの基本。
誰彼構わずF1マシンに乗っても工数だけかかる。銀の弾丸は無い。

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

もしかしてnodeもエアプなの？
924 名前：デフォルトの名無しさん mailto:sage [2022/02/25(金) 08:47:26.78 ID:apxGtOuK.net]: >>907
その方針がRustのダメなところだという話だよ。goは一応"Build fast, reliable, and efficient software at scale"というコンセプトからはあんまり外れていない。
Rustはメモリ安全性が最大のコンセプトなのに、メモリ安全性から外れる部分をカバーしない方針はコンセプトと矛盾している。
925 名前：デフォルトの名無しさん mailto:sage [2022/02/25(金) 08:55:53.55 ID:u7rOKKj6.net]: >>909
何が問題なのかその文章からはわからないから明確に述べてほしい
RustはC++の方針の失敗を反面教師として上手く機能している
Goの良さはもちろん承知しているがRust視点から見ればGoは言語機能が貧弱なのに巨大なランタイムでGCもあり互いに真逆の立ち位置にいるわけだから
926 名前：デフォルトの名無しさん mailto:sage [2022/02/25(金) 10:29:26.05 ID:JmFlgtI0.net]: >>904
最新のプログラミングをしたい/学びたい層にはGoは駄目だが、
昨今の他言語は常に肥大化しているので、仕様の更新を潔く諦め、
(15年前のプログラミングパラダイムで良ければ、)
『ちょうどいいプログラミング言語』であるGoには一定の需要はあり続けるはず。

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

> 豊富な機能や複雑な機能を使いこなせない劣ったプログラマー
これはわざとだろうがちょっと悪意が酷すぎる。
というか最近の若い奴はどうやら「全機能を使う事＝使いこなす＝有能」と捉えてる感があるが、これは違う。
プログラミング言語はあくまでアプリケーションを作る道具なのだから、
自分が欲しい機能があればそれで十分で、それ以上は必要ないんだよ。
927 名前：デフォルトの名無しさん mailto:sage [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派とは話が噛み合わないかも。
928 名前：デフォルトの名無しさん mailto:sage [2022/02/25(金) 11:17:47.06 ID:9DGl33if.net]: >>912
こういうわかってそうで全くわかってないレスは疲れるわ
929 名前：デフォルトの名無しさん mailto:sage [2022/02/25(金) 11:47:16.86 ID:ydtDuSNe.net]: >>910
「Rustがメモリ安全をコンセプトとするなら、(メモリ安全から外れる)unsafeが必要になる事態を放置するべきではない」ということだよ。
最小ライブラリとかはあくまで開発方針で、コンセプトの根幹となるメモリ安全を犠牲にしてまで優先する話じゃないということ。優先順位付けが間違っている。
まぁ、スレ違いだからこれ以上続けないけど、そういうのを棚に上げてgoを攻撃するのはダサいと思うわ。
930 名前：デフォルトの名無しさん mailto:sage [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は使い物になりません。
931 名前：デフォルトの名無しさん mailto:sage [2022/02/25(金) 12:04:36.06 ID:u7rOKKj6.net]: >>914
それはunsafeを理解していない
unsafeを悪だと勝手に思い込んでいるようだがそれは違っていてunsafeは必要不可欠なもの
まず言語に関係なく「unsafeな操作無しではほとんどの構造を書けないもしくは効率的に書けない」という当たり前の事実がある
そこでRustは「型やモジュールの内部にunsafeを閉じ込めて安全なインタフェースだけを外に出す」という戦略で出来た言語

したがって標準ライブラリか外部ライブラリかに関係なく両方とも
・それらが提供する型やモジュールの内部はunsafeが存在する(もちろんゼロの場合もある)
・それらが提供する型やモジュールの外部インタフェースは安全である(ことが求められる)
932 名前：全てがこの原則で作られている 一方で従来の言語C/C++ではunsafeな操作がプログラム全体に散在してしまい安全性を保証できなかった []: [ここ壊れてます]
933 名前：デフォルトの名無しさん mailto:sage [2022/02/25(金) 12:10:17.45 ID:aDhOSI3t.net]: >>912
RustはGoと異なり非同期タスクをスタックレスで実現している上に
RustはGoと同じくtry-catchを採用していないね
934 名前：デフォルトの名無しさん mailto:sage [2022/02/25(金) 12:34:23.12 ID:ydtDuSNe.net]: >>916
だからスレ違いと言ってるだろ。
しかも「メモリ安全から外れるunsafeが必要になる事態を放置している」の反論になってないし(標準ライブラリで赤黒木とか二重リンクリストを持っている方が結果的にメモリ安全にしやすいのは変わらない)。
これ以上やるならRustスレにコメしてくれ。
935 名前：デフォルトの名無しさん mailto:sage [2022/02/25(金) 13:28:20.21 ID:aDhOSI3t.net]: >>918
それは君の理解不足
unsafeな操作はプログラミングをする際に絶対避けることはできないけど
それをできる限り小さな狭い範囲に閉じ込め、かつ、その外に影響をもたらさないように設計しよう、というのが根幹
次に、二重リンクリストも二分木もRustの標準ライブラリにある
もし万が一その仕様が気に入らないなら他のクレートを探すか自作すればよい
どこに不満があるのかすら君は言うことさえ出来ずに君はイチャモンを付けているだけ
936 名前：デフォルトの名無しさん mailto:sage [2022/02/25(金) 13:54:38.00 ID:kxjR7eze.net]: >>919
go関係なさすぎ
937 名前：デフォルトの名無しさん mailto:sage [2022/02/25(金) 14:00:53.92 ID:9DGl33if.net]: >>919
完全に同意
938 名前：デフォルトの名無しさん mailto:sage [2022/02/25(金) 16:05:49.05 ID:kxjR7eze.net]: >>919
転送しました
https://mevius.5ch.net/test/read.cgi/tech/1644596656/91
939 名前：デフォルトの名無しさん mailto:sage [2022/02/25(金) 16:13:12.03 ID:iu2arc+w.net]: Rustスレでいつもホラ吹いてて隔離されてるやつだからさ
Go vs Rustみたいな隔離スレ立ててかまいたいやつだけが相手してやるといい
940 名前：デフォルトの名無しさん mailto:sage [2022/02/25(金) 16:57:45.37 ID:u7rOKKj6.net]: >>919
同意
その点を彼は全く理解できてないんだよ
そして彼は>>914でも「unsafeが必要になる事態を放置するべきではない」とか意味不明な主張をしてる
941 名前：デフォルトの名無しさん mailto:sage [2022/02/25(金) 17:20:54.95 ID:kxjR7eze.net]: >>923-924
Rustスレでやれ
942 名前：デフォルトの名無しさん mailto:sage [2022/02/25(金) 17:48:16.43 ID:MtnpFyFt.net]: せっかく対処法教えてやったのに
ちなみにそいついつも一人二役で自分のレスに安価付けるからw
943 名前：デフォルトの名無しさん mailto:sage [2022/02/25(金) 21:14:02.35 ID:aDhOSI3t.net]: >>925
俺が>>919で書いたことはRustも書くプログラマーにとっては基本的な常識なのでRustスレにおいては異論すら出ないため無意味だぜ
その基本的な常識を理解せずに間違ったRust批判をこのGoスレでする人がいたから説明したまで
944 名前：デフォルトの名無しさん mailto:sage [2022/02/25(金) 21:35:23.89 ID:dqMip1aQ.net]: このおじさん勢いあるスレならどこにでも湧くな
945 名前：デフォルトの名無しさん mailto:sage [2022/02/25(金) 21:47:06.20 ID:3Y4Z8gJm.net]: こんなおじさん昔はいなかったのにどこから湧いてきたんだろう
946 名前：デフォルトの名無しさん mailto:sage [2022/02/25(金) 21:57:26.52 ID:cRacAjKI.net]: 退職してすること無くて暇なんじゃね？
947 名前：デフォルトの名無しさん mailto:sage [2022/02/25(金) 22:05:54.67 ID:LgZQhCZj.net]: 観察者効果で生まれた
948 名前：デフォルトの名無しさん mailto:sage [2022/02/25(金) 22:10:44.84 ID:31pfTetO.net]: そのおじさん昔からいるぞ
昔はコテハンも使ってたが相手にされなくなったてやめたみたい
Ruby君と並ぶ有名人
949 名前：デフォルトの名無しさん mailto:sage [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
みたいなスレを作るとか
950 名前：デフォルトの名無しさん mailto:sage [2022/02/25(金) 22:52:44.27 ID:S5tvR1Yl.net]: Rust vs その他
みたいなスレにまとめてくれ
951 名前：デフォルトの名無しさん mailto:sage [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とは相性がいい。
（というか、だから当時は異端でしかない「非同期」を採用したのかもしれないが）
952 名前：デフォルトの名無しさん mailto:sage [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だとわきまえてて、ランタイムを自言語で書こうとかいう無駄な事をやってない。
953 名前：デフォルトの名無しさん mailto:sage [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から見れば卒倒しそうな仕様も、解の一つではあると見てる。
954 名前：デフォルトの名無しさん mailto:sage [2022/02/26(土) 06:42:38.06 ID:BX4iLvdt.net]: >>937
JavaScriptの非同期呼び出しでも普通は無視せずPromiseにcatch付けて捕獲するぜ
例: async_func_foo.catch(err => console.log(err))
あとRustの非同期呼び出しもResultが帰ってくるからエラーを捕獲できる
955 名前：デフォルトの名無しさん mailto:sage [2022/02/26(土) 07:29:58.26 ID:xkMoRRzB.net]: Goを叩く為にJavaScriptを使ってるだけで、JavaScriptの理解度かなり浅いなこのおじさん。
しかしこんなおじさんがずっと暴れてんのか、全然議論できないじゃん。対策としてはワッチョイ導入くらいしか無いだろうね。
956 名前：デフォルトの名無しさん mailto:sage [2022/02/26(土) 08:20:49.61 ID:W5JOGvZg.net]: 長い文章ダラダラ書く人ってプログラマーの素質ないよ
文章を短く簡潔に書ける人ってプログラムも同様に書ける
957 名前：デフォルトの名無しさん mailto:sage [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はそれなりに機能するはずだから、不満持ってる奴もそれなりにいるはずだけど。
（そういう連中は既に去ってる気もするが）
958 名前：デフォルトの名無しさん mailto:sage [2022/02/26(土) 09:09:48.94 ID:yRlIqUsp.net]: 発想が違う、どの案件でも、その案件にとって1番だから使う、と言う言葉が伝わってないのか？
俺も十分、言外の言葉は理解できないタイプだが、流石に通じると思うんだが。

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

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

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

実際にはnodeもそうだけど、C#のTaskなんかに関してもめちゃくちゃ解像度甘いのでは？
959 名前：デフォルトの名無しさん mailto:sage [2022/02/26(土) 09:10:48.16 ID:yRlIqUsp.net]: goだと、非同期スタイルで書けるとかでなくて、ブロッキング関数、同期関数を書いたとしてもgoroutine間では適切にスイッチングされて、他の言語で言うawaitがかかってるんよ。常に低コストで。
それはN:M軽量スレッドだからなし得ることなので、他の言語ができてない以上何とも比べづらい。
960 名前：デフォルトの名無しさん mailto:sage [2022/02/26(土) 09:11:12.66 ID:yRlIqUsp.net]: オール想像で喋ってるよな、こいつ。
961 名前：デフォルトの名無しさん mailto:sage [2022/02/26(土) 09:42:59.75 ID:Cq56y6gH.net]: >>939
ワッチョイは浪人生の自演が捗るだけ
962 名前：デフォルトの名無しさん mailto:sage [2022/02/26(土) 09:45:22.81 ID:Zjg02ogZ.net]: ローニンでワッチョイ消してるやつ正規表現で弾けばええやん
963 名前：デフォルトの名無しさん mailto:sage [2022/02/26(土) 09:55:57.50 ID:UdeBSueS.net]: 自演するのにワッチョイ消すバカはおらんやろ
964 名前：デフォルトの名無しさん mailto:sage [2022/02/26(土) 10:07:05.87 ID:xkMoRRzB.net]: 荒らしの手間が増えるだけで十分価値がある
965 名前：デフォルトの名無しさん mailto:sage [2022/02/26(土) 10:19:30.57 ID:kpnhrKVl.net]: >>943
> ブロッキング関数、同期関数を書いたとしてもgoroutine間では適切にスイッチングされて、他の言語で言うawaitがかかってるんよ。
これは普通はマルチスレッドと言う。Thread/goroutineを複数（マルチ）起動して引っかかったらスイッチングさせるだけなのだから。
そして大概の言語はこれを自然に書けるようになってる。

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

これを脳死でgoroutineはコストゼロ、だからgoroutineに切り出す事がプログラマの仕事である、と解釈できれば美しいのだが、
これを実際に試して「思ってたよりも全然パフォーマンスが出ねぇ、これならNodeの方が速ぇ…」となった顛末を書いてたのが何度も言ってるブログ。
これは言語と言うよりはランタイムの問題だけど。
966 名前：デフォルトの名無しさん mailto:sage [2022/02/26(土) 11:28:52.99 ID:nWK21oqu.net]: JSのPromiseは非同期の扱いとしてはかなり好き
967 名前：デフォルトの名無しさん mailto:sage [2022/02/26(土) 12:15:41.10 ID:pDCyYMqI.net]: >>949
N:Mのグリーンスレッドであって単なるマルチスレッドじゃない。
単に引っかかったら切り替えるんでなくてスティーリングまでやるのは他の言語の言語標準機能にはErlangぐらいにしかない。

どこが嘘なんよ。
コストゼロでは無いが、いわゆるスレッドよりは遥かに軽いぞ。
968 名前：デフォルトの名無しさん mailto:sage [2022/02/26(土) 12:16:18.51 ID:pDCyYMqI.net]: 総じて知らんだけでは？
969 名前：デフォルトの名無しさん mailto:sage [2022/02/26(土) 12:35:54.23 ID:Zen8kEK8.net]: わからせようとするのが無駄だって何で気づかないかな
970 名前：デフォルトの名無しさん mailto:sage [2022/02/26(土) 12:41:19.24 ID:D1V+AmSx.net]: >>940
論理構成がしっかりしてて読みやすければ長文でもいいんだけどね
このおじさんはそこが壊滅的だから明らかに素質ないわな
971 名前：デフォルトの名無しさん mailto:sage [2022/02/26(土) 12:50:12.55 ID:xkMoRRzB.net]: 抽象化できず同じ事何回も書く傾向にあるから、凄いコード書きそう
972 名前：デフォルトの名無しさん mailto:sage [2022/02/26(土) 12:58:01.48 ID:862GBE0V.net]: >>955
というか、
短い=良い
もしくは
simple=beautiful
というセンスが欠落している。
あんな汚い長文ぞっとするわw
まあ.{50}でNGにしてるけど
973 名前：デフォルトの名無しさん mailto:sage [2022/02/26(土) 13:27:19.11 ID:fRC8OZTs.net]: Goの(疑似スレッド＋)goroutineのパフォーマンス計測っていいやつないの？
↓見つけたやつ
Goroutines Are Not Significantly Smaller Than Threads
https://matklad.github.io//2021/03/12/goroutines-are-not-significantly-smaller-than-threads.html
974 名前：デフォルトの名無しさん mailto:sage [2022/02/26(土) 13:41:54.09 ID:CoGWNwI7.net]: Goってぶっちゃけ言語機能とか割とどうでもよくて、
・ビルドやデプロイや運用がシンプル
・本家の開発体制が保守的で、長期的に安定したサポートが期待できる
という点がメリット
極力作りっぱなしで放置したい類のものに向いてると思うんだよね
Goしかできない奴やGo大好きで使ってる奴もまずいないだろうし、こんなもん執拗に叩いて何がしたいの
975 名前：デフォルトの名無しさん mailto:sage [2022/02/26(土) 13:51:01.17 ID:bMt+E6tQ.net]: CLIツールはともかく一番使われてるWeb APIは放置したいものとは対極だろう
976 名前：デフォルトの名無しさん mailto:sage [2022/02/26(土) 14:05:08.22 ID:nWQ4XblH.net]: APIはむしろどっちかというと放置したい系じゃね？
フロントと表裏一体みたいなのもあるけど、そういうのにGoはあまり採用されないでしょ
977 名前：デフォルトの名無しさん mailto:sage [2022/02/26(土) 14:21:48.69 ID:yRlIqUsp.net]: 確かにそうだな。わかろうとしないし、伝わらない気がしてきた。
Rust最高とRustスレで言っててくれれば良いか。

>>958
これはあるよね。
1つ前のバージョンどころか、それなりに昔のGoのプログラムですら修正せずにコンパイルできる。
978 名前：デフォルトの名無しさん mailto:sage [2022/02/26(土) 16:17:55.72 ID:kpnhrKVl.net]: >>951
やってないのはやる必要がないから。
他言語も馬鹿ではないので、改善の努力はしてるし、いい点があったら平気でパクってる。

(Goはgreenthreadで全て解決！と謳っているわけではないけども、そうだとしたら）
そのアイデアは面白かったが、現実的ではなかった。
（ただしこれはランタイムの問題だから改善の余地はあるはず）

非同期はコードがうざくなるのは事実だが、async文法でほぼ払拭された。
だからみんなパクってる。

まあ完全にループだし、材料枯渇でここら辺で終わりかな。
そりゃ信者の念仏を何度聞いても翻意する事はないよ。俺は文系ではないし。
こちらの見解では説明出来ないデータが出て来たら、分析して、考えを修正するけど。

>>957
virtualの40MBを単純に合算したら、今は4倍軽くて、4k/goroutine時代は2.5倍軽かったという事か。
フットプリントだけの比較ではあるが。
だから極めて単純に言えば、他言語のスレッドでジョブを4つずつ束ねて処理する運用をすれば、
フットプリントでは並んで、速度は余分なスケジューラが入ってない分勝てる事になる。
979 名前：デフォルトの名無しさん mailto:sage [2022/02/26(土) 17:32:36.09 ID:nY3OEggH.net]: >>960
そりゃWebのフロントエンドに比べりゃなんだって放置したい系になるだろ
Webの場合はバックエンドでもWebフレームワークをサポートバージョンに維持する必要があるから
長くても3〜5年すればコードを変更することになる
980 名前：デフォルトの名無しさん mailto:sage [2022/02/26(土) 17:33:24.82 ID:117KIGn2.net]: >>958
言語機能は本当に20世紀に設計された言語なのかと
疑いたくなるね
ほぼGCがあるCを書いてる感覚に近い
C書けない人が書ける言語じゃないと思う
981 名前：デフォルトの名無しさん mailto:sage [2022/02/26(土) 18:00:31.99 ID:yRlIqUsp.net]: >>962
はい、じゃあ言質も取れたのでRustスレに戻って下さいね
982 名前：デフォルトの名無しさん mailto:sage [2022/02/26(土) 18:06:45.33 ID:yRlIqUsp.net]: >>963
そうか？コアAPIに関してはあんまり手を入れないけどな。
Webフレームワーク次第なAPIってどんなの？
983 名前：デフォルトの名無しさん mailto:sage [2022/02/26(土) 18:16:48.89 ID:nWQ4XblH.net]: >>966
SPAのすぐ裏でUIの要件に合わせて作るようなやつのことじゃね？
そういうのはそもそもGoを採用しないと>>960で書いた通りだ
984 名前：デフォルトの名無しさん mailto:sage [2022/02/26(土) 19:00:50.19 ID:yRlIqUsp.net]: >>967
なるほど。BFF的なやつ。
たしかにGoで書くまでもないし、ノンコーディングもあるよね。
985 名前：デフォルトの名無しさん mailto:sage [2022/02/26(土) 19:13:38.66 ID:nWK21oqu.net]: 正直なんだかんだ言って、学習コストに対しての性能パフォーマンスが異様に高いというところがGoの魅力
言語仕様がコンパクトだからミスしにくい(気がする)のも良い
チャネルに容量があることを忘れるうっかりさん以外には

得意な機能は限られててGUIとかは苦手だけど、そんなもんC#やらに任せとけばいいや
986 名前：デフォルトの名無しさん mailto:sage [2022/02/26(土) 19:41:27.25 ID:cxVkNmoR.net]: Goの魅力はケン・トンプソンなんよ

https://en.wikipedia.org/wiki/Ken_Thompson#2000s
> When the three of us [Thompson, Rob Pike, and Robert Griesemer] got started, it was pure research.
> The three of us got together and decided that we hated C++. [laughter] ... [Returning to Go,]
> we started off with the idea that all three of us had to be talked into every feature in the language,
> so there was no extraneous garbage put into the language for any reason.

彼が"we hated C++"つって作っただからそらもうみんな嬉しいやろ
987 名前：デフォルトの名無しさん mailto:sage [2022/02/26(土) 19:44:13.98 ID:fRC8OZTs.net]: 結局>>957よりいいパフォーマンス計測ってないのかー
個人的感想としては。。。
パフォーマンスについて特筆すべき利点はない
原理的にスレッドプールを使った他言語のコードと同程度の性能が出る
機能的な利点はグリーンスレッドを言語で持っており、自動でOSスレッドと使い分けられる点(記述量低＆必要メモリ低)
逆に欠点はスケジュールをコントロールする方法がGOMAXPROCS以外ない点ってところかな
988 名前：デフォルトの名無しさん mailto:sage [2022/02/26(土) 20:07:50.21 ID:nWK21oqu.net]: >>971
優先度がないのはちょっぴり残念ではある
…ないよね？
989 名前：デフォルトの名無しさん mailto:sage [2022/02/26(土) 20:31:14.25 ID:kpnhrKVl.net]: >>969
> 学習コストに対しての性能パフォーマンスが異様に高い
Cの方が高いけどな。Goよりも小さい仕様で速い。
あとC#もGUIはゴミだぞ。それ以外がいいからunityを制覇してるが。
990 名前：デフォルトの名無しさん mailto:sage [2022/02/26(土) 21:20:48.95 ID:4mZJSMD8.net]: >>943
>> それはN:M軽量スレッドだからなし得ることなので、他の言語ができてない以上何とも比べづらい。

RustもM:Nモデルだよ
Goと同じく複数の非同期タスクを複数のOSスレッドに割り当て
しかもGoとは異なりスタックレスなのでGoよりも軽量タスクを実現しているよ

>>951
>> スティーリングまでやるのは他の言語の言語標準機能にはErlangぐらいにしかない。

RustもGoと同じM:Nモデルでワークスティーリングもしているよ
Rustでは以下のランタイムを選ぶことができるよ
・1:1モデル (＝M:Mモデル、OSスレッドそのまま利用)
・M:1モデル (シングルOSスレッドで並行マルチタスク)
・M:Nモデル[スレッドプール方式]
・M:Nモデル[ワークスティーリング方式]
991 名前：デフォルトの名無しさん mailto:sage [2022/02/26(土) 21:35:40.76 ID:yRlIqUsp.net]: >>974
それは処理系標準？それとも準標準？
992 名前：デフォルトの名無しさん mailto:sage [2022/02/26(土) 21:58:06.53 ID:kpnhrKVl.net]: >>974
それ以下と定義が同じだと、一般的には「ワークスティーリング方式」を「スレッドプール」と呼称するよ。（だからC#のもこれのはずだけど）
https://tech-blog.optim.co.jp/entry/2019/11/08/163000
Rustで何故あえて方言にしているのかは知らん。
というかワークスティーリングじゃない方のメリットなんてない気がするんだが。
993 名前：デフォルトの名無しさん mailto:sage [2022/02/26(土) 21:58:10.74 ID:nPeFYJEF.net]: >RustもGoと同じM:Nモデルでワークスティーリングもしているよ

VMじゃないのにどうやって実現してるのかな
994 名前：デフォルトの名無しさん mailto:sage [2022/02/26(土) 21:59:12.46 ID:4mZJSMD8.net]: >>975
RustはGoと真逆で標準ライブラリとは最小限のものに限る位置付けなので
標準ライブラリには非同期ランタイムを作るための枠組みだけが存在していてランタイム自体は無しだよ
これは全ての分野について同じ方針でRustでは標準＋準標準(デファクトスタンダード)を使ってプログラミングをするよ
995 名前：デフォルトの名無しさん mailto:sage [2022/02/26(土) 22:13:34.76 ID:4mZJSMD8.net]: >>976
そこは一般的は話としてまずOSスレッド毎にキューと持つかグローバルにキューを持って割り振るかの2大方式があるよ
それぞれに利点と欠点があってそこは省略するけど
GoもRustもそのハイブリッド方式となっていて普段はスレッド毎にキューを持って各OSスレッドが独立に効率よく処理だね
そしてGoもRustもグローバルにも管理して暇なOSスレッドが生じるとそこへ割り振る(OSスレッドから見るとスティール)するよ
詳細はここで書ききれないほどもう少し複雑だから省略してる点はそれぞれの解説サイトなどを見てね
996 名前：デフォルトの名無しさん mailto:sage [2022/02/26(土) 22:54:22.46 ID:kpnhrKVl.net]: >>979
Goと同じなら805のリンクの内容と同じだからああそうですか程度。
資料が古いがC#のは以下で確認した。同様にハイブリッドでスティーリングもあり。
（ただ.NET6.0とかだともう変わってそうだが）
https://ufcpp.net/study/csharp/misc_task.html
基本グローバルキューで、ただし優先順位はローカルキュー＞スティーリング＞グローバルキューになってる。
この構造はまあ納得。

> GoもRustもそのハイブリッド方式となっていて普段はスレッド毎にキューを持って各OSスレッドが独立に効率よく処理だね
> そしてGoもRustもグローバルにも管理して暇なOSスレッドが生じるとそこへ割り振る(OSスレッドから見るとスティール)するよ
無駄に複雑で余計に遅くなると思うけどね。.NETの方が単純ですっきりしてていい。
グローバルキューから取り出す時の競合を気にしてるのなら、
Goみたいに100,000goroutineとか目指す場合は分かるけど、Rustは基本そうじゃないだろうから、チューニングミスだと思うけど。
997 名前：デフォルトの名無しさん mailto:sage [2022/02/26(土) 23:02:07.46 ID:Gc6jVciw.net]: Goは別に最速を目指している言語じゃないからね
もし何かのベンチマークが最速になってしまったら逆に驚くよ
そのベンチ間違ってるだろ、って。
998 名前：デフォルトの名無しさん mailto:sage [2022/02/26(土) 23:40:35.78 ID:BX4iLvdt.net]: >>977
VMじゃないと起きる問題点は何？
いずれにせよC/C++/RustはVMでもOSでも記述できるのだからそこに不可能は無い

>>980
言語に関係なくシステムスレッド間のグローバルな操作はデータ競合回避など一定のコストがかかる
だから可能な限り個別にシステムスレッドが動くようにしつつアイドルが出ないよう最小限のグローバル操作
この部分はよほど上位で制約のある仕様としていないならば全ての言語で同じ
999 名前：デフォルトの名無しさん mailto:sage [2022/02/26(土) 23:48:39.58 ID:yRlIqUsp.net]: >>978
これがなぁ…。過渡期は混ぜるな危険で困らない？そこが不安。
Rustも良いとは思うんだけど、爪切るのにハサミ使ってる気分になる。
1000 名前：デフォルトの名無しさん mailto:sage [2022/02/26(土) 23:59:29.99 ID:kpnhrKVl.net]: >>982
それはハードによる。
x86はハードウェアでキャッシュコヒーレンシを取ってくれるので実は共有RAMでもコストは安い。
.NETがローカルキューからの取り出しでFIFOとFILOで競合が減るから、というのはそういう事。
Goの場合はARMを見てるのか、MacがARMに乗り換える布石だったのか、
以前からやたら「共有RAMは遅いから使わない」としてきてるが、
ぶっちゃけx86の場合は
（書き込み頻度と量によるが、タスクの起動＝関数ポインタ１つと引数のポインタ程度なら）
OSを利用したチャネル接続よりも共有RAMの方が実は速い。
ここら辺を理解してない奴がグダグダやってるからチューニングし切れてないのだと思うよ。
1001 名前：デフォルトの名無しさん mailto:sage [2022/02/26(土) 23:59:34.35 ID:4mZJSMD8.net]: >>980
>> Goみたいに100,000goroutineとか目指す場合は分かるけど、Rustは基本そうじゃないだろうから、

Rustの非同期タスクはGoroutineよりも更に軽くて
Goとは異なりスタックレスなので付加メモリ消費も非同期ランタイムの管理データ分の1タスクあたり64bytesで済みますよ
そしてグローバルキュー競合コストの件は>>982のように同じですね
1002 名前：デフォルトの名無しさん mailto:sage [2022/02/27(日) 00:02:30.74 ID:2GGoVw4G.net]: >>982
問題があると言っているわけじゃなくて、VMやOSじゃなければプリエンプションできないからどうやっているのかなと。
1003 名前：デフォルトの名無しさん mailto:sage [2022/02/27(日) 00:03:38.38 ID:uWHjNeVw.net]: >>973
Cはお爺ちゃんだから…
Cからの乗り換えコストっていう視点でどうかひとつ

あ、でも実装系別の頭おかしくなるコンパイルオプションやらバウンダリやらのメモリモデル考えると、Goのほうが実質勝ってないか学習コスト？
1004 名前：デフォルトの名無しさん mailto:sage [2022/02/27(日) 00:11:21.81 ID:uWHjNeVw.net]: >>973
ちなみに速さやらサイズでは当然にCとかの圧勝だろ普通に
関数呼び出しごとにオーバーヘッドのかかるGoが単純な速度で勝てる道理はない
1005 名前：デフォルトの名無しさん mailto:sage [2022/02/27(日) 00:23:35.14 ID:uWHjNeVw.net]: >>973
C#というか.Netのwpfは好き
一般的な手法じゃないだろうけど、MVVMのVM部分を単体テストできて(ディスパッチャ細工してメインスレッドで走らせる) []; [ここ壊れてます]
1007 名前：デフォルトの名無しさん mailto:sage [2022/02/27(日) 00:44:59.79 ID:PVy06kKY.net]: >>985
> Goとは異なりスタックレスなので
やたらこれを強調しているが、goでもgoroutineにローカルキュー（＝関数ポインタの配列）を用意して、順に食わせれば、
各タスク毎にスタックを用意する必要なんて無くて、普通にエミュレーション出来るよ。
(ただしGo信者的にはこれは負けだからやらないとも思うが）

ただこの場合、各タスクが止まらない前提ならこれでいいが、
止めて切り替える分には一般的にはスタック領域が必要になる。
(自動変数を全部ヒープ上に確保すればスタック無しでもいいが、これは遅くなるので多分やってないと思う)
ユーザーが確保しなくていいだけで、実際はランタイムかコンパイラが確保してくれてるだけじゃないか？
1008 名前：デフォルトの名無しさん mailto:sage [2022/02/27(日) 00:50:50.94 ID:PVy06kKY.net]: >>988
> 関数呼び出しごとにオーバーヘッドのかかるGo
かからないような気がするが、自信はない。かかる理由って何？
1009 名前：デフォルトの名無しさん mailto:sage [2022/02/27(日) 02:41:36.05 ID:uWHjNeVw.net]: >>991
Goは関数呼び出しごとにスタックをチェックして、不足してたなら拡大するから
関数ごとの静的な自動変数サイズと比較してるだけだと思うけど、そういう処理のおかげで初期スタックサイズを抑えてる
https://postd.cc/performance-without-the-event-loop/
1010 名前：デフォルトの名無しさん mailto:sage [2022/02/27(日) 02:47:33.19 ID:uWHjNeVw.net]: >>991
「十分な空間がない場合、ランタイムはヒープに対して大きなスタックセグメントを割り当て、現在のスタックの内容を新しいセグメントにコピーし、古いセグメントを解放し、それから関数呼び出しを再開します。」
1011 名前：デフォルトの名無しさん mailto:sage [2022/02/27(日) 03:00:02.25 ID:uWHjNeVw.net]: >>991
毎回拡張する訳じゃないけどそのためのチェックは毎回走るんで、単にサブルーチンを呼ぶだけの他言語よりは余分な仕事をしている
おそらくチェックは必要な回数だけだとは思う(ループ内での呼び出しとかの最適化は考えてないとは思わないから)
1012 名前：デフォルトの名無しさん mailto:sage [2022/02/27(日) 06:52:35.32 ID:+yReYAPt.net]: compiler explorer(https://godbolt.org/)で、goコンパイル結果を普通のamd64用のアセンブラ見ること出来ないの？(Plan9でなく)
1013 名前：デフォルトの名無しさん mailto:sage [2022/02/27(日) 07:42:28.85 ID:uWHjNeVw.net]: 次スレ建ててくる
1014 名前：デフォルトの名無しさん mailto:sage [2022/02/27(日) 07:44:00.44 ID:uWHjNeVw.net]: Go language part 5
https://mevius.5ch.net/test/read.cgi/tech/1645915400/
1015 名前：デフォルトの名無しさん mailto:sage [2022/02/27(日) 07:56:25.05 ID:nXG/aSfD.net]: >>990
Rustの非同期タスクは内部的には単純な状態マシンとなり何度も再入可能なコルーチンと同じ状況になります
その中の変数はRustのクロージャがその環境の変数をキャプチャするのと同じだからもちろんメモリを確保します
だからスタックレスで何度も呼べるクロージャみたいな状況でスタック自体はプロセス全体で1本のままとなります
もちろんその非同期タスクから他の非同期でない普通の関数を呼べば通常と同じくスタックが伸びて使われていきます
一方でその非同期タスクから他の非同期な関数を呼ぶとその非同期タスクから一旦離脱してスケジューラーへ戻ります
最初に書いたように「単純な状態マシンとなり何度も再入可能なコルーチン」となっているので再び再開できます
以上がスタックレスなのにRustの非同期タスクがメモリの許す限り多く動くことができる仕組みです
1016 名前：デフォルトの名無しさん mailto:sage [2022/02/27(日) 08:07:16.26 ID:c9v4owXb.net]: ワッチョイ無しかー(´・ω・｀)
1017 名前：デフォルトの名無しさん mailto:sage [2022/02/27(日) 08:16:41.16 ID:+yReYAPt.net]: goroutineとC++標準ライブラリのスレッドを比較するために>>957のmain.rsのC++版だけ作ってみた(ループは一桁減らした)
$ cat main.cc
#include <thread>
#include <chrono>
#include <vector>
using namespace std;
using namespace std::chrono;
int main() {
vector<unique_ptr<thread>> threads;
for (uint32_t i = 0; i < 1000; ++i) {
threads.emplace_back(
make_unique<thread>([=]{
uint64_t bad_hash = (i * 2654435761) % 200000;
this_thread::sleep_for(microseconds(bad_hash));
for (uint32_t _ = 0; _ < 1000; ++_) {
this_thread::sleep_for(10ms);
}
})
);
}
for (auto const& t: threads) {
t->join();
}
return 0;
}
$ g++ -O3 -pthread main.cc -o main && ./t ./main
real 11.04s
user 0.93s
sys 2.95s
rss 11328k
$
結果はmain.rsとほぼ同じで、やはりスレッド起動コストがデカく、rssもデカい
1018 名前：1001 [Over 1000 Thread.net]: このスレッドは１０００を超えました。
新しいスレッドを立ててください。
life time: 468日 4時間 2分 1秒
1019 名前：過去ログ ★ [[過去ログ]]: ■ このスレッドは過去ログ倉庫に格納されています

[ 新着レスの取得/表示 (agate) ] / [ 携帯版 ]

read.cgi ver5.27 [feat.BBS2 +1.6] / e.0.2 (02/09/03) / eucaly.net products.
担当:undef