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/ 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は、�@普通にビルドできて、�A普通にデプロイできて、�B後々ゴミにならない という当たり前の事が当たり前にできることに存在意義がある 簡単なことだけどそれができない言語が多いんだよね 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] "); //]]>--> 1006 名前：/read.cgi/tech/1605467680/973" rel="noopener noreferrer" target="_blank" class="reply_link">>>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