Go language part 3

**デフォルトの名無しさん** · 2019/10/17(木) 21:38:04.78

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

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

日本語訳
http://golang.jp

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

**デフォルトの名無しさん** · 2020/11/01(日) 20:48:36.50

古いPerlスクリプトをGoogle Compute Engineの無料枠で動かそうとしたら
cpanのDBD:mysqlのmake時のテストで多分メモリエラーで落ちた
いい機会だからgoで作り直すことにしたわ(´・ω・｀)

**デフォルトの名無しさん** · 2020/11/01(日) 20:53:11.08

一応調べたぞ。

スレッドのスタックサイズは、
.NETのはデフォ1Mで最小値はシステムによるがVista(.NET2.0)なら256KBだそうな。
それより新しいのはよく分からんがこの雰囲気だと64KBか。
https://docs.microsoft.com/ja-jp/dotnet/api/system.threading.thread.-ctor?view=netcore-3.1#System_Threading_Thread__ctor_System_Threading_ThreadStart_System_Int32_
https://docs.microsoft.com/en-us/windows/win32/procthread/thread-stack-size

pthreadはこちらも具体的には書いてないから推測になるが、
oracleが16KB指定してるし、MANPAGEにも書いてあるからここまでは行けるのは確実。
オーバーフロー検出の項目で1ページ以下にも指定出来るとあるから、
スタックサイズは4KBかそれ以下にも指定出来るとも思われるが、断定は出来ない。
https://docs.oracle.com/cd/E19253-01/819-0390/attrib-45427/index.html
https://linuxjm.osdn.jp/html/LDP_man-pages/man3/pthread_attr_setstacksize.3.html
https://linuxjm.osdn.jp/html/glibc-linuxthreads/man3/pthread_attr_init.3.html

いずれも起動時にパラメータでスタックサイズを指定出来る。

**デフォルトの名無しさん** · 2020/11/01(日) 20:58:17.56

>>819
それはネイティブスレッドな。

**デフォルトの名無しさん** · 2020/11/01(日) 21:30:51.41

>>816-817
実際Nodeに負けてるのは事実だし、あのブログ読んで技術的に俺は納得してる。
782も納得してるし、他の連中もあの貧弱環境ならそうだな、となると思うが。

ちなみに当たり前だが全ての環境で全敗するわけではないぞ。
俺も数年前に味見でPHP/Node/Goで同じものをPCのXAMPP上で試したが、
GoはNode比2倍、PHP比6倍のパフォーマンスが出た。
（僕のカワイイGoを虐めるな！って感じだから、、これを言ったら満足するか？)

それで俺はPHPで行くことに決定した。
PHPのパフォーマンスで俺には十分だったし、無料鯖は現状PHPのみだからだ。
そしたらGoでやってた奴が「ゴラアふざけんな！」って言ってきたが「知るかボケ」と返した。
あいつはPHPの糞コードがこれ以上世の中に増殖するのが許せなかったらしい。
実は本当はNode無料鯖が大量にあればNodeにしたいのだが、今はそうではない。
よって糞とは分かっているがPHPだ。
ただ、そのGo使いは「Goなんて遅すぎ、Rust行くわ」と言って今はRustでやってるよ。
そりゃパフォーマンスだけで勝負するならRustになるし。

静的なコンパイル言語なんだからスクリプト言語と比べて速いのは当たり前。
それが貧弱環境だと覆るのはアーキが悪いんだよ。
そして何故そうなるのかを色々理解した上で、それぞれが用途に適したものを使えばいいだけ。
今のところ俺がGoを使うことになる芽はない。だからって何だよ、でしかないとは思うけど。

最近のお前らがよく分からんのは、言語べったりで言語と心中しようって奴が多すぎることだ。
お前の使ってる言語が良くても悪くてもお前の成果でもないし、悪口でもないだろ。
ぼくがつかってるげんごすごい＝ぼくすごい、なのはゆとり特有な気がするが、
何故お前らがそうなるのかさっぱり分からん。

**デフォルトの名無しさん** · 2020/11/01(日) 21:50:55.32

>最近のお前らがよく分からんのは、言語べったりで言語と心中しようって奴が多すぎることだ。

なかなかの妄想力

**デフォルトの名無しさん** · 2020/11/01(日) 21:54:59.97

後半完全に何言ってるのか分からん
病気じゃないのかお前

**デフォルトの名無しさん** · 2020/11/01(日) 22:00:10.95

>>821
PHPは歯ブラシとしては優秀だからな。
それは認めるわ。

ただ、XAMPPとか無料鯖とか言ってる次元で意味がわからん。
普通自鯖だろ。

ちなみにRustが持て囃されてるのは、早いからではなくて安全だからだぞ。
大量の並行処理をさばくならGoの方を俺は選ぶが。

言語べったりと言うが、このスレはGoのスレなんだし、そもそもお前が他の言語に対して理解がなさすぎて、何でも自己流の解釈するから頭おかしい結論になるんじゃねえか？

**デフォルトの名無しさん** · 2020/11/01(日) 22:05:20.17

病人構うな

**デフォルトの名無しさん** · 2020/11/01(日) 22:20:51.95

お前らな、「グリーンスレッド？知らんかったわｗ」の時点で気付け

**デフォルトの名無しさん** · 2020/11/01(日) 22:45:13.37

わざわざgoスレに乗り込んできて何がしたかったんだろ

**デフォルトの名無しさん** · 2020/11/02(月) 08:42:57.13

スレッドのようなもので、スレッドではないって言ってんのに頭の中スレッドでいっぱいだから理解もできてないし。
何なんだろうなホントに。

**デフォルトの名無しさん** · 2020/11/02(月) 11:21:06.04

勢いがあってよろしい

**デフォルトの名無しさん** · 2020/11/02(月) 12:09:27.63

goroutineのオンリーワンは当分揺るがないだろな
同接数十万以上とかのWebAPI作るならgolangが第一候補
そこまで性能が求められない場合では、保守性からJavaとかNodeみたいな人員調達容易な言語

**デフォルトの名無しさん** · 2020/11/02(月) 13:55:39.65

Gopherくんがキモいのが全部悪い

**デフォルトの名無しさん** · 2020/11/02(月) 16:49:39.29

Gopherキモいのが何もかもダメにしとる

**デフォルトの名無しさん** · 2020/11/02(月) 17:41:48.74

Go書けるまともな人相当少ないからかなり美味しいんだよな
世の中の人プログラミング苦手なのか？と思ってしまう
スクリプト言語かいてイキってた人達が沈黙したし

**デフォルトの名無しさん** · 2020/11/02(月) 19:04:40.88

この10年ぐらいはスクリプトでイキリがほんと多くてウンザリした

**デフォルトの名無しさん** · 2020/11/02(月) 21:24:24.64

>>816
君がその程度の理解なのは理解した。
ただそれはGoの思想「何でもかんでもgoroutineに切り出せば自動的に速くなります」なのだろうからGoUserとしては悪くない。
しかし現実にはNodeに負けてる、ってこと。

君らの問題は、何故それが起きるのか理解出来ないことだ。
これは806のスライド作った奴もそうだが、何故遅くなるのか、何故速くなるのか、理解出来てない。
ただ、そう教えてもらったから、という知識しかない。

しかしこれもそんなに酷いことではない。
最近は複雑化したハードウェアに対応する為に、ソフトウェアも複雑化してる。
学生では単純に知識量が追いつかない。
となるといわゆる正しい作法で洗脳する、というのが現実的な解で、
それがJavaでのオブジェクト教、Goの場合はgoroutine教なのだろう。
しかし既に言ったがchannelしか使わないのなら現実的にそれでいいんだよ。理由は分からなくても。
ソフトウェアを資産として捉えた場合、正しい作法で書かれた物が大量にあることが重要であり、
君らがGo流の正しい作法で書くのなら、それはGo界の資産となる。だから貢献してる。

**デフォルトの名無しさん** · 2020/11/02(月) 21:25:09.49

問題は、その程度の理解なのに限界領域の最速を目指せると勘違いしていることだ。
それは無理なんだよ。ハードウェア上で動いているのだから、ある程度のハードウェアの知識がないといけない。
実際、Nodeに負けてるのも、その理由も、君には理解出来ないんだろ。

なおNodeのはスケジューラとは言わない。ああいうのはキューという。積まれた順に吐いているだけだから。
あれをスケジューラと呼ぶのは、まともなスケジューラ作ってる(つもり)なGoの連中に対しても失礼だ。

ただそこで負けてるのはやっぱりアーキが悪いんだよ。
スケジューラを入れると、一般的にディスパッチの際にその分オーバーヘッドが入る。
だからディスパッチされるジョブが小さければ小さいほどそのオーバーヘッドが大きく見えてしまう。
それは「goroutineで何でもかんでも切り出せ」という思想と矛盾してしまうだろ。
だからNodeに負けた。

**デフォルトの名無しさん** · 2020/11/02(月) 21:25:43.73

C界で有名な話で、「K&Rのmalloc(30行程度)に勝つ為には5000行のコードが必要だった」というのがある。
https://www.wdic.org/w/TECH/malloc
何もやらないのが一番速いから、シンプルなソフトウェアはそれだけで速い。
OSのスケジューラもほぼキューでしかないはずで、Nodeと同様に「積まれた順に吐くだけ」だけど、
逆に、それでいい領域であればそれ以上のスケジューラを持たせても原理的に勝てない。
それがNodeに負けた理由。

JSのシングルスレッドアーキテクチャというのはかなりトリッキーなアイデアではあるが、
ああ割り切ってしまえば世界がシンプルになるから色々省略出来る。
結果、ソフトウェアが全体的にコンパクトになるから思っている以上に速くなる。
それがNodeに負けた理由。

逆にGoの思想でNodeに勝つ為には、「積まれた順に吐くだけ」な馬鹿キューを上回る為に、
「このgoroutineは『いつ』『どこ』にディスパッチすべきか」をきっちり管理しないといけない。
それは今の「空いてれば取ってきます」程度では全然駄目で、上記mallocの戦いなら今はまだ一合目でしかない。
後10倍くらい複雑化してプロファイラーも整備しなければ「シンプルなだけ」のソフトには速度で勝てない。
(プロファイラーを実装したくなければユーザーが明示的に指定するgolightみたいなのがあればいいのだが、
そういうの無しでやりたければ、プロファイラーが要る)

後君らが見えてないのは、複数のCPUを並列/並行動作させるのは実はものすごくオーバーヘッドがあること。
これはx86だと全部ハードウェアがやってくれるのでソフトウェア上では負担がないのだけど、
それはコードから見えないだけで、実際のCPUは止まりまくってるから実行速度はがた落ちになってる。
それがNodeに負けた理由。シングルスレッド限定だとこのオーバーヘッドがないんだよ。

**デフォルトの名無しさん** · 2020/11/02(月) 21:27:00.51

>>830
CPUリソースを余すことなく使う、という意味では原理的にNodeの方が上なんだよ。
本体ジョブしかしないんだから。

ただNodeの場合はマルチコアだと束ねて使うしかない。
これも既に行われているはずだけど、この場合はそれぞれのNode間の直接情報交換は無理筋になる。
(やる場合はDB(或いはエミュレーションレイヤ)経由だが、直接RAM上での交換とは速度では全く勝負にならない)
しかし数十万のコネクションを一度に張って、その間で頻繁にやりとりするって何がある？ほぼ無いよね？
チャットはそうだけど、だからこそチャットアプリでNodeに現実的に負けたあのブログは大きいんだよ。
だからGoUserが噛みついてDisclaimerまで付いてGitHubにまで追いつめられちゃって、になってる。

ただし、実は現実的にはネットワーク出力は一つなのだからチャットでも何でもシリアル処理実装で全く問題ない。
よって根本的にはCPU単体速度>=ネットワーク速度なそこらのPC程度だとNodeでも問題の発生しようがなく、対応出来てしまう。
これはレン鯖等も含めて。
そうではなく、ネットワーク速度>>>CPU単体の速度、な環境ではNodeでは全く無理筋だが、これがどこにあるかだよ。
クラスタで中身は束ねたPC程度だとNodeで全く問題は発生しないはずで、実際それがNode鯖を使ってる連中の使い方だろ。

GoはNodeの思想からすれば盛大に屋上屋を架している。
それでパフォーマンスが出れば大したもんだけど、スケジューラがあの程度ならまだまだ遠いよ。
「CPUが十分速い」という大前提が成り立つ限りJSの思想はかなり筋が良いんだ。
ただそれが1995の時点で見切れたのか、単にラッキーなのかは謎だが。

**デフォルトの名無しさん** · 2020/11/02(月) 21:28:45.62

>>830
と思ったが、オンゲか？
オンゲは確かにNodeでは無理だろう。これは根本的にNode向きではないから。
コネクション単品の処理も重く、コネクション間の情報交換も多い。
逆にコネクション単品が軽いチャット程度だと、goroutineがオーバースペック過ぎてNodeに負けてしまってる。
これはある意味単なる設計ミスで、起動時にもっと小さいスタックサイズを指定出来るようにすれば済む話なのだけど、
それをしないところをみると何か出来ない/したくない理由があるんだろう。
あのブログを出されて噛みつくってのは民度が低くて、スタックサイズを可変にするってのが建設的対応だよ。

ただ、可変スタックサイズなんてやれば出来る話でしかないし、
理由はおそらくスケジューラの性能がその辺だからだろう。
goroutineに切り出すと「スケジューラ」「同期化機構」分だけオーバーヘッドが生じる。
それは「賢いスケジューリング」で取り戻すしかないが、元々軽いgoroutineでは無理がある。
だからある程度重いジョブをgoroutineに切り出すことが必要で、
それ以下の軽いジョブだと到底無理だから消極的に制限してるのだろう。
これだとチャットでNodeに負けた理由も、
またそれでもなおgoroutineのスタックサイズを2KBと巨大なままに保っていることも説明が付く。
実際、データを置かず、再帰も必要な時にしかしないのなら、スタックサイズ2KBなんて埋めようがないし。

**デフォルトの名無しさん** · 2020/11/02(月) 21:30:11.08

長くて読む気がしない
3行にまとめて

**デフォルトの名無しさん** · 2020/11/02(月) 21:34:24.83

>>835
Nodeに負けてるが定量的でないぞ。
お前が書いたNodeのコードに負けてるのであれば、goroutineをどう使えばよいか解ってないお前がポンコツだって事だ。
主観的すぎる。やりなおせ。

**デフォルトの名無しさん** · 2020/11/02(月) 21:44:01.67

また発作か…

**デフォルトの名無しさん** · 2020/11/02(月) 22:10:55.63

>>841
負けてるのは781のブログだよ。詳しく知りたければ読めよ。
俺は彼の分析には納得してるし、その通りだと思ってる。
だから同じような環境なら間違いなく負けるとも思っている。

お前らって（というよりは最近は他言語もだが）
結局Goが「最速最高」じゃないと文句を必ず言ってくるけど、それはないでしょ。
速度ならC/C++/Rustには負けるし、お手軽さではPHPやJSには負けてる。
だからいちいちそんなところで噛みついてくて欲しくないね。建設的な話が出来ない。
完璧な言語なんてないのだから、己の状況でどれが一番ましか判断してそれを使うしかない。
なら、いろんな言語を客観的に見てないと駄目でしょ。

ただ、スレッドで切り離せるところをgoroutineで積極的に切り離せば解があるのではないか？
という着眼点でGoが動いているのは分かった。
確かにこれは面白いし、実際threadはそういう風に使われることを想定されてない。
だからこれをやりたかった人達はネイティブスレッドには文句たらたらだったのだろう。

ただ問題は、同期自体が凄く重いのと、
現存のハードウェアはそういった大量の軽量スレッドを生かす方向には出来てないことだよ。
Niagaraは比較的向いてるけど、SPARC自体が死んでしまってるし、富岳もARMになってしまったからね。

**デフォルトの名無しさん** · 2020/11/02(月) 22:29:00.53

と思ったけど、SPARCはOracleが独自改造しまくってたな。
実際OracleみたいなDBサーバーならGoはハードウェア的にもソフトウェア的にも向いてるのかもしれん。

**デフォルトの名無しさん** · 2020/11/02(月) 22:39:52.04

>>833
>>834
俺から見ればGo使いも十分イキってる馬鹿だけどな。
そしてスクリプト言語使いがイキってるのを止めてる気配も感じないが。特にＪＳ/TS。

ただPHPerは叩かれすぎだとは思う。

**デフォルトの名無しさん** · 2020/11/02(月) 23:27:43.59

>>845
俺から見れば1番イキってるのは君だよ

**デフォルトの名無しさん** · 2020/11/03(火) 00:10:32.82

>>846
そりゃご丁寧にどうも。

ただ、今ここで話した限り、以前の印象「Go使いはC++を使えない馬鹿」ってのを再認識したけどな。
C++も無駄に複雑になって、しかもそれを使いこなすのが目的みたいな勘違い野郎がネット上には増えてるし、
あれはあれでおかしな事になってるが。

ただGoはちょっと立ち位置が悪い。
「端の言語」はとりあえずは生き残れるんだよ。Goはどの面もそこに該当しない。
今なら「最易」枠がPHP/JS/Python。
「最速」枠がC/C++。
「堅牢」枠がJava。
中庸といえば聞こえは良いが、実際に積極的にGoを選ぶ理由がない。
上記の言語はそれなりに糞だと分かってても最○を求めたら他に選択肢がないから選ばれる。
だからのさばってる。

goroutineの思想は確かに面白いが、今はそれを生かせるハードがない。
そしてそのハードを開発させるほど影響力も大きくない。
(ただしGo向けハードウェア開発自体は簡単だから、やる気になればすぐ出来るが)

あとはgenerateだね。
ただしgenerateが向いてるのは下地の言語が全機能を持っている場合であって、(つまりC++)
Goみたいに綺麗に制限されてる言語には向いてないんだな。

**デフォルトの名無しさん** · 2020/11/03(火) 00:18:35.41

↑ キング・オブ・イキリ

**デフォルトの名無しさん** · 2020/11/03(火) 01:02:06.59

>>843
だからスレッドではない。
同期も重くない。
同期しないためのchannelとselectだよ。
もう少し調べてから書け。

**デフォルトの名無しさん** · 2020/11/03(火) 01:05:11.27

>>847
goはバランスをとったのだと思うな。
最易ではphpやpythonに負けるけどそれらよりは速くできる。
最速ではc, c++, rustに負けるけどそれらよりは簡易に利用できる。
堅牢さでは、、、んー、これはjavaに負けてるのかな？rustには負けてそうだけど。

バランスとったから突き詰めたら他のものに負けるのはしょうがない。
0か100じゃないんだからそれでいいと思う。

goの良さはchannelやgoroutineを用いて従来言語よりcsp(communicating sequential processes)を利用しやすくなったところだと思う。

**デフォルトの名無しさん** · 2020/11/03(火) 02:20:11.37

疲れてるのに長い文章読む気もおこらんから読んでないが
>>847 だけ読んで俺は基本的に同意の人間なんだが・・
ちなみにわしはC++が一番好みで最初の数行に同意なんだが
複雑すぎるとか難癖つけるやつが多いがC++が今の形に発展したのには理由がある
哲学、美学先行で必要もなくわかりにくくしているわけではない実用が最優先言語なのだ
Go も正直なんでこんな流行してるのか今一理由がわかんない
これ使うくらいなら既存言語を用途にあわせてチョイスすりゃいいじゃん、ともおもうが
まあ小型のプログラムをサクサクと書くには便利な言語だね
ただし、Go は名前がクソ
あとエラーハンドリングはなんとかしろわりとマジで

**デフォルトの名無しさん** · 2020/11/03(火) 02:32:57.50

　 /＼＿＿_／＼
／　／　　　ヽ ::: ＼
|　（●）,　、（●）、　| 　　／￣￣￣￣￣￣￣
|　　,,ノ(、_, )ヽ、,, 　 | 　＜　まーたはじまった
|　　　,;‐＝‐ヽ　 .:::::| 　　＼＿＿＿＿＿＿＿
＼　　｀ニニ´　 .:::／
／｀ー‐--‐‐—´´＼

**デフォルトの名無しさん** · 2020/11/03(火) 02:34:49.96

思うに、go言語に未練あるけどもういじりたくない（または理解できなかった）人なんだろうな
どうにかして貶めたいという固い意志を感じる

**デフォルトの名無しさん** · 2020/11/03(火) 07:09:16.22

Goが理解できなかったわ無いわ
こんなのスクリプト言語レベルだろ

**デフォルトの名無しさん** · 2020/11/03(火) 07:45:30.12

>>850
バランスというより、なんか独自進化じゃないかな。
後出しジャンケンでインターフェイスを実装したことにするとか。

>>851
軽量スレッドなんかは既存言語にはできない事だからな。

**デフォルトの名無しさん** · 2020/11/03(火) 12:41:08.52

goroutine はスレッドをダメだこりゃと車輪再発明する暴挙に出た一品
更にスタックが固定じゃ限界があるって考えて魔改造
そこまで無茶苦茶やらかすことで数百万の平行処理を可能とした鬼子
逆を言えば、そこまでしなければ数百万のリクエストは捌けない
デメリットは関数呼び出しからやらかしているためC呼び出しな低レベル処理が書けないという点
WebAPI用途のドメイン固有言語と言ってもいいかもしんない？

到るところでベンチマークが出ていてすら認めたくないのが笑える
https://postd.cc/the-way-of-the-gopher/

**デフォルトの名無しさん** · 2020/11/03(火) 14:25:22.75

erlangなんかはこういう発想で軽量プロセスにしてるよね。
とはいえCouchDBでしerlang使ってないけど。

**デフォルトの名無しさん** · 2020/11/03(火) 19:17:11.84

goは名前とマスコットキャラがダメ

**デフォルトの名無しさん** · 2020/11/03(火) 19:57:00.21

サーバーサイドはGo一択でいいんじゃないか？
速いし運用もこれまでのlinuxの知識があれば問題ない
ライブラリも充実してるし
並行処理も便利
これまでforkを駆使して面倒なことしてたけどしなくて良くなった

**デフォルトの名無しさん** · 2020/11/03(火) 20:15:39.32

goも性能やスケールを突き詰めていくとダメよ。
https://www.atmarkit.co.jp/ait/spv/2002/10/news038.html

**デフォルトの名無しさん** · 2020/11/03(火) 20:58:25.32

>>860
そもそもこいつらが使ってるCassandraなんてまさにGCでフリーズする(笑)はずのJavaなわけで、眉唾な話だな
もうJavaで書けばいいんじゃないかっていう

**デフォルトの名無しさん** · 2020/11/03(火) 21:11:05.72

>>850
> csp(communicating sequential processes)
何ぞそれ？と思ってwiki読んだが、「応用」以前はハア？って感じだな。
応用部分は納得出来るが、それはどちらかというとモデリング＆シミュレーションであって、(従来の)プログラミング言語って感じではない。
勿論それ以前の部分はプログラミング言語としてのCSPについて説明してあるはずなのだが、
大半の連中はこれ読んでも俺と同様「何のこっちゃ？」だと思うぜ。

それはさておき、記述しやすいのは事実だから、cspに金脈があるのならいきなりブレークするのだろう。

**デフォルトの名無しさん** · 2020/11/03(火) 21:21:56.26

>>851
C++の現状に歴史的経緯と必然性があるのは認める。
しかしそれは新しく始める人にとっては関係ない話なのだから、言い訳にはならないだろ。
C++は（普通のプログラミング言語を目指すなら）ちょっと仕様を整理しないと駄目だよ。
ただC++陣営は「全部入り、仕様の整理は各人がコーディングルールで制限しろ」で多分考えてて、
確かにそれもありではあるのだが。
実際、C++を気に入ってる奴って、「俺がこうしたい」を記述する方法があるからだろうし。
他言語で「それは書けない」に遭遇すると本当にどうしようもないからね。

Goが受けてるのは簡単だからだよ。
PHPは簡単だがパフォーマンスと文法が糞過ぎ。
JSは非同期がウザ過ぎ、あとフニャフニャすぎて駄目。
Goは型もあるし！難しくないし！パフォーマンスも出るし！
となるだけ。俺個人はJSのフニャフニャっぷりが気に入ってるのでそこで止まってるが。
型あり言語出身の奴等が上記フローを流されたら順当にGoに行き着く。最近はTSに行ってるかもだが。

**デフォルトの名無しさん** · 2020/11/03(火) 21:22:40.23

あとGoは意図的に「若者の楽園」を目指しているのが、「見た目は」奏効しているかも。
意図的に用語等を他言語と変えていて、既存言語既習者の参入障壁を上げている。
色々あるが今回ならgoroutine、やっぱりあれはgolwp(lightWeightProcessの略)とかが妥当だろ。
それをgoroutineなんて言葉を使うから、thread/lightWeightProcess/co-routine/greenthread等を知っている奴等は余計に混乱する。
ところがこれらを何も知らない若者は全く混乱しない。だから結果的に若者が後れを取らない。

ちゃんと用語を合わせた新規言語（Go以外は全部こうだが）を作った場合、
他言語既習者は文法だけの修得でがんがん進めるのに対し、
新規プログラミング学習者（＝若者）はOOP等の「プログラミングそのもの」の部分で学習に時間がかかり、
早々に頭を抑えられて、結果、「老害」とわめくことになる。

Goのように意図的に既存言語から変更している場合、既存言語を知っている奴等だけが混乱する。
結果的に、既存言語既習者の流入が減り、「老害」が比較的少ない環境＝若者にとって居心地が良い環境になるわけだ。
ただしそれは見た目だけで、実際は人材が枯渇してる。「老害」と共に「老兵」も来なくなるから当たり前だが。
例えば、806のスライド、作ったのは東大の学生のようだが、中身を見る限り、こいつは、
共有メモリを使ったことがないし、それが何なのかも理解してない。
というより多分Goのチャネルしか使ったことがない。
その程度の奴をカンファレンスに呼ばないといけないほど人材がいない。

そしてここで「Goのスケジューラが読むに値するコードだ」と吠えている馬鹿もそう。
その程度のコードをありがたがらないといけないほど全体のレベルが低い。
「空いてりゃ取ってくる」程度のスケジューラなんてすぐ書けるし、
むしろそれすら書けない馬鹿は死ね、なのがC/C++/Rustの世界だと思うが、Goはそうじゃない。
だからこの意味ではGoUserは「イキっている」のを自覚出来てない。

**デフォルトの名無しさん** · 2020/11/03(火) 21:23:08.75

ただこれはGoの仕様だ。
実際いちいちグダグダ言われてもモチベーション下がるし、やりたいようにやらせろ、ってのはある。
そこで若者が天才的なコードを連発出来れば素晴らしい楽園が出来上がるわけだが、
実際はプログラミング自体、才能だけで突破出来るものではなく、地道な修練が必要なものだから、
そうは行かなかった、というだけ。（若いだけでは何ともならない）
結果的に「若者の楽園」＝レベルの低い「馬鹿者の楽園」になってる。ただまあ、それもありだと思うけど。
ただそれによって本来はGo界にも存在したはずの「凄いコード」に触れられる機会を逸していることは認識した方がいいとは思うが。

だから「若者」に受けているだけだとは思うが、実際それも分かる。
今のC++の仕様なんて色々複雑になりすぎてるし、あれ見たら引くだろ。使いもしない細かい仕様が多すぎる。
Javaは無駄に清書させられる、C++は意味不明、Rustはコンパイルが通らん、CはGUIには不向き、ならGoになる。
他のスクリプト言語よりは速いし。

伝わるかな？言い方を変えればユース、サッカーのU21みたいなのをプログラミング言語界に意図的に作ってる。
そこでは若者が馬鹿やってる、勿論レベルは低いがフルレギュで戦ってる大人がそれを揶揄するのは野暮ってもの、みたいな。
実際「共有RAM知りません」「空なら取ってくるだけのスケジューラは凄いです」
（この後投稿するが）「なんとNodeはシングルスレッドでした！」とか、グーで殴るぞ、のレベルだろ。
ただそれでもそういう環境の方が合う奴もいるだろうから、本人が選べばいい。

**デフォルトの名無しさん** · 2020/11/03(火) 21:23:25.98

インメモリなキャッシュと分散データベースでメモリ管理コストが影響する幅は変わるに決まってるし、そうでなくとも実測で改善してるならそれが全てでしょ
ここで比較するならC/C++/Rustみたいな言語で書き切るコストやそれを行える人材を確保するコストに対して、Goのまま書き換えなり他の手段で対処するコストがどうなのかという話だと思うよ
JavaのGCだって今や複数のリリース元から日夜改善されてってる訳で
Go自体は良さがあると思ってるけど他を眉唾だなどと語り貶めす形で話をするのはいい気持ちしないなぁ

**デフォルトの名無しさん** · 2020/11/03(火) 21:23:39.46

あと話を聞いてる限り、新規の若者は「全部の文法」を抑えてから次に行こうとする。
本来はこれが一番効率がいいから当たり前なのだが、
C/C++はその点、古い文法＝今では使うべきではない、というのがそのまま残っていて、
何も知らない若者がそれを活用しようとしてるのが散見される。
んで、「そんなん使うなボケ」と言ったら逆ギレされることが多々ある。
ただこれらも新規参入者にとっては落とし穴でしかないから、ウザイのは事実だよ。無いに越したことはない。
これらが存在する理由はレガシー＝互換性だから、新しい言語なら比較的少ないのも事実。勿論Goも。
だからC/C++なんて最速枠でなければとっくに死んでるよ。C/C++は新規を獲得する努力をしてない。

**デフォルトの名無しさん** · 2020/11/03(火) 21:54:35.32

>それをgoroutineなんて言葉を使うから、thread/lightWeightProcess/co-routine/greenthread等を知っている奴等は余計に混乱する。

名前だけ見てコルーチンみたいなものだろうなんて思い込むうのはおっちょこちょいだろうが
使ってみりゃすぐわかるだろう、普通。

**デフォルトの名無しさん** · 2020/11/03(火) 22:02:11.61

つーか Go の発案者て老人ばっかりじゃなかったっけ？
なんか皆 C++ 嫌い(それもいかにもロートルにありそうな理由)で
それであえてC++的な要素(ジェネリック、継承によるオブジェクトの多態モデル
try..catchスタイルの例外等々)は全部入れないようにしたって話だが
つまり若者向けではなく、モダンなプログラムをやりたいがCではきついので
ちょっとだけモダンになったCっぽいシンプルな言語、みたいなイメージだと思ってた

**デフォルトの名無しさん** · 2020/11/03(火) 22:10:57.27

>>869
多分それで合ってるぞ。
それに若者が食いついただけ。
既にC++使えてる奴は全く食いつかないし、食いつく必然性もない。

**デフォルトの名無しさん** · 2020/11/03(火) 22:17:11.15

今日もイキリの神様が暴れているのか

**デフォルトの名無しさん** · 2020/11/03(火) 22:28:43.57

>>870
たくさん書き込んでるけどもう良いだろ、Rubyスレに帰ろうな

**デフォルトの名無しさん** · 2020/11/03(火) 22:33:32.93

>>856
Nodeがシングルスレッドなのは基本中の基本で、そんなのでこんな記事書いてること自体がびっくりだよ。
お前はそれすら知らずにNode使ってたのかよ！(Go界は人材不足だからこんなもんかもしれんが）
そこら辺がWeb系が馬鹿ばかり、と言われる点だと思うよ。これで仕事してることになっちゃってるし。
ただこいつのイベントループの部分の理解も間違ってると思うけど。
イベントループを抜ければスタックは空になる。スタックフレームガーなんて事にはならない。
そして「燃え上がるグラフ」になってるのはお前がそう組んだからで、完全に組み方が悪い。
(燃え上がってるのは「負荷」ではなくて自分が呼んだ「関数ネスト」だから）

ただまあ、組み方が悪かろうが何しようが、動くってのは重要なんだが。
だからこのケース（＝同じ奴＝同じ技術レベルの奴）が組んで動くようになったんだから、Goの方が向いているのは事実だ。
状況からすると、timeoutした場合はおそらく優先処理しないといけなくて、
それを放置して次のリクエストを積んだら余計な手間が発生するのだろう。
そうじゃないと「燃え上がるグラフ」にはならないから。

この点、NodeというかJSのイベントループには優先順位がないから、筆者の言うように「最後まで待たされる」事になる。
だから優先順位を付ける必要がある場合は自前でsetTimeoutをラップしてやる必要があるけど、逆に言えばそれだけだね。
それすら思いつかない人でもGoなら上手く行く、というのもまた重要な点ではあるけど、
781のブログと同様に噛みつかれ、「お前のコードが糞なだけ」と言われた場合、それは事実だと思うよ。
(なおこのケースはI/Oのようなので優先順位付加ではなく自前キューの方がいいが)

**デフォルトの名無しさん** · 2020/11/03(火) 22:33:55.31

ただこれは「後付」であって、ここまで解明していればNodeでも対策は簡単に出来るわけだが、
実際はここまで解明するまでに時間がかかる。
AmazonS3がそういった類の、
つまり「timeoutのエラー処理を優先的に処理しないとその後の処理も遅れます？」みたいな特性を持っているとすると、
スペック上からは見えない落とし穴であり、Nodeなら嵌るがGoなら(知らなくても)嵌らない、というのはあり得る。
それはやっぱりNodeのシングルスレッドアーキテクチャの方が世間（他言語）からは特殊で、
Nodeだけ嵌り得る落とし穴も世の中には存在するということ。
こういうのに遭遇したくない場合、Goの方が安牌、というのはその通り。この点はNodeだけが特殊だから。
勿論この人が最初からGo使ってたら一番幸せだったろう、というのもその通り。

**デフォルトの名無しさん** · 2020/11/03(火) 22:34:19.61

ただgoroutineって優先順位付けられたっけ？
何かこの人たまたま直ってるだけで、さらに負荷かけたらやっぱだめでした、になるだけの気がするが。
「燃え上がるグラフ」になってるのは「処理が遅い」のではなく「処理時のネストが深い」だからね。
AmazonS3のせいでもなくて、
いわゆる「コールバック地獄」的な組み方＝コールバックを深くネストして『最初の段階』で全部積み上げてしまうから、
後で止まれなくて実はtimeoutしてた時に余計な処理が多々発生してネストが深くなっているだけの気はする。
ただこの手の「不味い組み方」な奴はJSには多いのも事実。もっとフラットに組めよ、と言っても通じないし。
多分彼等にとってはJSの非同期ってのが至極相性が悪くて、
彼等的に非同期を解消する方法がコールバックネストしかないのだと思う。
その点、Goだと最初から同期で書けるので、そういった「糞コード」には(初心者でも)ならない。
この辺はC/C++/Rustだと「お前が糞なだけ」で片づけられるだろうけど、
俺自身は「初心者でも糞コードになりにくい」のは大変良い特性だとは思う。(というよりこの点はJSが糞なだけだが)

というわけで俺のその記事に対する感想は、
goroutineが優先順位付けられた場合：Nodeだけ嵌る落とし穴に命中してご愁傷様でした
goroutineが優先順位付けられなかった場合：初心者JS使いだけが何故か嵌る糞コードになっててご愁傷様でした
だな。多分後者で、初心者でも糞コードになりにくいGoだから救われた、だけの気がする。
(Goが良いというよりはJSの非同期ってのが糞コードの産地になってて、筆者もそうだっただけだが)

**デフォルトの名無しさん** · 2020/11/03(火) 22:46:43.82

>>866
ついでだから本家の方読んできた。
まずそもそもReadStatesをそんなにバカスカ更新するようなアーキが必要なのか？という疑問はあるが、
それはさておき。

これは、多数のオブジェクトを「生存したまま」でメモリを埋める、
つまりオンメモリDBのような使い方をするアプリとGCが絶望的に相性が悪くて、それに該当した、ということなのだろう。
これはGoがショボイというよりはGCの限界で、C++/Rustしかねえわな、ということだと思うよ。
JavaでもC#でも同じ結果になる気はする。
だからそういうアプリでGC言語使っちゃ駄目、というのが教訓だと思うよ。

**デフォルトの名無しさん** · 2020/11/03(火) 23:20:17.15

マジで怖いんだけどこの人
何かやらかさないか心配

**デフォルトの名無しさん** · 2020/11/03(火) 23:44:46.53

お前ほんとに学習しないのな。

**デフォルトの名無しさん** · 2020/11/03(火) 23:52:01.26

Ruby のコンパイルに、1CPU なら、20分掛かるけど、
4CPUなら、5分で済む

CPUセントリックな処理では、CPU並列処理は意味がある

**デフォルトの名無しさん** · 2020/11/04(水) 00:08:44.43

>>862
cspは概念・モデリングっつう理解でだいたいいいと思うよ。
昔から並行処理システム関わった奴ならたいていは似たようなモデルは考えてる。
cspはそれを厳密に数学的に記述するって感じ。
極端なこと言えばメッセージでやり取りしましょう、だ。

っで、goはプログラミング言語としてgoroutineとchannelがあるから他の言語より並行処理向き。
go以外なら古くはadaやなんかもそう。タスクにランデブポートっつうのがある。
erlangも似たようなメッセージ機構はあるんじゃなかろうか。

本質的に並行処理ってのは非同期的な処理システムなわけだけど、
非同期ioとコールバック(やシンタックスシュガー)でやるより、独自に動く実行体が複数あってそれらがメッセージ通して協調動作するってシステムの方が好きだ。

**デフォルトの名無しさん** · 2020/11/04(水) 00:15:06.09

>>876
まぁーやっぱ、gcってよくねーわ。
捨てる前提のプロトタイプにはgcあり言語もよいと思う、ほんで大部分の案件はそれで十分ってのもあっる。
げももっと性能を、、、てやると今なら c/c++/rust の3つしかナイショ。

**デフォルトの名無しさん** · 2020/11/04(水) 00:48:58.46

>>880
それアクターモデルだろよ、と思ってwiki確認したら、CSPがモロに書いてあったわ。
ただ、アクターは浮かんでは消え、という印象があるが。
smalltalk信者等、通信したい奴は確かにいるようだが、それがイマイチ何になるのか明確でない。

あと、コード上で通信したいのならGoだが、アクターモデル自体は普通にオブジェクト指向で組めるし、
C++なら（あまりよろしくはないが） >> と << をオーバーロードしてそれっぽく見せることは可能だ。
実際その方がgoroutineより何倍も速く動く。

Erlangは俺も以下を半分くらい読んだ程度しか知らないが、
https://www.ymotongpoo.com/works/lyse-ja/index.html
あれは実用本位で、理論側から出てきたものでは全然無い。
電話交換機筐体を複数並べてスケールアウトした時にも性能が低下しないように作られてる。
だから最初から共有RAMなんて禁止されてる。そして当然メッセージ交換だが、
最初から上記のような疎結合でのメッセージ交換を想定されてるから、
Goみたいな密結合を想定されているものとはちょっと違うが。

**デフォルトの名無しさん** · 2020/11/04(水) 00:55:48.53

>>881
ちなみに本家の方はコメントも付いてて、GoUserが吠えてる（事になってる。
ただあの程度で噛みつきと捕らえられるのも厳しい気はするが)

Rust試す前にGoのバージョン上げろよ、というのもそうだが、
キャッシュサーバー使えよ、というのは確かにな、とは思った。

**デフォルトの名無しさん** · 2020/11/04(水) 04:35:34.49

言葉の端々に今どきの若者は～みたいなのを感じる
周りから相当クソ扱いされて5chで鬱憤晴らしてるんだろうな

**デフォルトの名無しさん** · 2020/11/04(水) 06:03:20.20

それか単なるヒキニート

**デフォルトの名無しさん** · 2020/11/04(水) 07:42:42.00

>>881
実際問題、ここ数年のGC言語で足を引っ張られた事はあんまりないけど。
そういう意味では参照カウンタ方式のPythonなんかは割と効率良いんじゃない？それこそスクリプト言語だけど。
言語としてのスループットを上げたければ、allocはまとめて、freeはもっともっとまとめてやって、必要そうだったらメモリのcompactionかけるほうがスループット上がると思うが。

>>882
Goのどこが密結合？
チャンネルは？

**デフォルトの名無しさん** · 2020/11/04(水) 08:59:07.22

>>886
参照カウンタのGCとマーク&スイープのGCは意味合いが全然違う。
それを一緒くたにしてるようでは駄目だよ。

そこら辺がGoスゲーって言ってる奴のレベルが低いところだよ。
それ以外も君は間違いすぎていちいち指摘するのは諦めたけど、
多分もうちょっと勉強した方がいい。

Goは酷い言語でもないけど、凄い言語でもない。
860の本家にRustと冷静に比較しているコメントがあるから読んでくるといい。

**デフォルトの名無しさん** · 2020/11/04(水) 10:32:02.91

>>882
c++はc++11以降ほんとよくなった。
でももう新規案件ならrustに譲ってもいいかなと思う。

**デフォルトの名無しさん** · 2020/11/04(水) 10:57:28.03

>>887
広義では参照カウンタもgcじゃん。
gcも色々改良されてるし未だに古典的なマークスイープgcのみってのはあまり無いんじゃろか。
だから案件の多いweb系とかアプリとかの上のレイヤーでgcが問題になるケースはあまり無い。

gcはそれより下のエンジンとかのシステムレイヤーで問題視されることが多い。
で、一応goはc/c++/rust同様のシステム言語のくくりで語られることもあるからその辺から叩かれたりするけど、そうじゃなくて上のレイヤーの言語として使えばいい感じの言語だと思う。

**デフォルトの名無しさん** · 2020/11/04(水) 11:27:49.81

哀しき中間管理職みたいな言語なんだね

**デフォルトの名無しさん** · 2020/11/04(水) 11:50:37.38

>>887
> 860の本家にRustと冷静に比較しているコメントがあるから読んでくるといい。

>>860 の本家ってこれかな？
Why Discord is switching from Go to Rust（Discord Blog）
https://blog.discord.com/why-discord-is-switching-from-go-to-rust-a190bbca2b1f
コメント58件あるけどGo信者の圧が凄い…

**デフォルトの名無しさん** · 2020/11/04(水) 11:56:43.57

>>887
参照カウントに対して、俺がどういう意図で話してるかわかってる？
一緒くたにしてるわけではなくて、参照カウントのメリットってのもきちんとあるんだよ。

勘違いが多すぎるのはお前の方だと思うよ。
グリーンスレッド知らなかったんだっけ？
グリーンスレッドの切り替えにはコストがかかるんだっけ？
全部スレッドの話だよな。

いちいち都合の悪いところをネグってレスつけるのやめろよ。

**デフォルトの名無しさん** · 2020/11/04(水) 11:58:46.84

Go vs Rust、じゃなくてむしろこの2つ以外が要らんのだけど
取り敢えずGoが分からないグリーンスレッド君がRustを理解出来るとは思えない（笑）

**デフォルトの名無しさん** · 2020/11/04(水) 12:03:20.78

参照カウント方式には結構なメリットがある。
別スレッドも必要ないし、速度も出る。ストップザ・ワールドも必要ない。
オブジェクトの開放が「かならず」「一定の場所」で行われてデストラクタの動作タイミングを保証できる。
弱参照がきっちりしてればそれこそ循環参照もそれほど恐れることはない。

組み合わせて使うのが良いと思うよ。俺的には。
だからこそ引き合いに出したんだが。
C++好きならshared_ptrあたりから理解が及びそうなもんなんだが。

**デフォルトの名無しさん** · 2020/11/04(水) 12:04:06.32

>>887
で、指摘してみろよ。
お前が間違ってることは懇切丁寧に指摘してるんだから。

**デフォルトの名無しさん** · 2020/11/04(水) 12:22:41.50

循環参照検出付きの参照カウント方式は、GC?

**デフォルトの名無しさん** · 2020/11/04(水) 15:06:50.39

>>896
自動的にメモリを開放してくれて、フラグメントを解消してくれる仕組みは、大雑把に言ってガベージコレクションの仲間に入れるもんじゃない？

**デフォルトの名無しさん** · 2020/11/04(水) 16:33:07.68

誰かこの人形劇を止めてくれよ

**デフォルトの名無しさん** · 2020/11/04(水) 18:33:48.20

とりあえずGoのリリースノートを全部読んでから話してほしいな。彼には。
1.14あたりでgoroutineのスケジューラちょっと変わってるし。

**デフォルトの名無しさん** · 2020/11/04(水) 22:39:50.46

>>889
> 広義では参照カウンタもgcじゃん。
そう。俺も「参照カウンタのGC」とも言っている。
馬鹿は放置として、君も疑問のようだから回答しておくと、
参照カウンタ方式は「ユーザーが間違ってない」前提が必要で、「ユーザー補助」でしかない。
対してマーク＆スイープは「ユーザーが間違ってても」GCが為されるから、「システム保護」なんだよ。
だから役割が全然違う。少なくとも真面目に24時間365日動作させるつもりなら、単純に交換は出来ない。

これが結局何だかんだでマーク＆スイープから離れられない理由で、
JavaもC#もJSも、勿論Goもマーク＆スイープしてる。
勿論それが重いのはみんな分かってるから、色々工夫してるけど、最終的にはやるしかないから。

だから参照カウンタ方式のGCでマーク＆スイープと同様に「システム保護」を得る為には、
「ユーザーがどんな書き方をしても」解放されることが必要で、
例えば>>896のようなのが有ればいいけど、これで実装してる例ってあったっけ？
（なお循環参照の検出自体は簡単だが、適切に起動する為のイベントがないから、実装時に困るのはそこだと思うが）

> そうじゃなくて上のレイヤーの言語として使えばいい感じの言語だと思う。
そこは今どっかりとC#が根を下ろそうとしている。
C#は俺は良い言語だと思うけど、Javaに食われて死にそうなのがなあ、という見方だったが、
少なくとも俺の予想以上には大健闘していて、生き残るかもしれないなあ、とは思いつつある。
これまではC#もC++もWeb系が手薄だったけど、どっちもガチで整備し始めてるから、それが完了した時にどうなるかだね。
そしたら本当にGoを使う意味が全くなくなる。

逆にRustはCPU負荷無しで「システム保護」出来るわけだから、GC言語を皆殺しにかかってる。
そしてC並に速いのだから、確かに最終兵器ではあるんだよ。盛り上がる理由はそれ。

**デフォルトの名無しさん** · 2020/11/04(水) 23:37:57.93

>>900
長文連投しても知識が薄っぺらい
https://github.com/JetBrains/kotlin-native/blob/master/FAQ.md#q-what-is-kotlinnative-memory-management-model

**デフォルトの名無しさん** · 2020/11/05(木) 00:53:39.27

>>900
ユーザーが参照カウントを上げ下げすることなんてほぼないぞ
言語内の仕組みなんだから
C拡張とか書く場合もたいていスコープ抜けたら
それまでの一時変数は全解放するって書き方があるし
他のGCでもそれは同じ
だからほとんど中身の仕組みを意識しなくても良い
むしろそれができないなら実装がしょぼい

**デフォルトの名無しさん** · 2020/11/05(木) 01:09:47.48

Goが人気出た大きな理由の一つは、過不足がなく比較的高品質な標準ライブラリ
その点でいえばNodeも同じだが、Nodeと違って変なのを噛まさず標準ライブラリを素のまま普通に使うことを美徳とする文化があるのも効いてる
くだらない流行り廃りに惑わされずに決まったものをただ普通に使えばよいというのが近年の複雑化しすぎたWeb界には受けた
Rustはそのへんは全然ダメだね

**デフォルトの名無しさん** · 2020/11/05(木) 01:17:10.50

またそんな煽りを…
まったくオマイラときたら変な輩を呼び寄せる呪文を唱える
才能に関しては天才的だな

**デフォルトの名無しさん** · 2020/11/05(木) 07:04:56.97

>>900
それで実装してる例がPython

**デフォルトの名無しさん** · 2020/11/05(木) 07:24:03.07

RustはRustでC++の標準ライブラリがゴテゴテと九龍城が如く聳え立ってきた反動でもあるので許してやれという気持ちがある
それにしたって初期の標準が貧弱で標準に取り込むまでの右往左往が長すぎるというのも分かるが

**デフォルトの名無しさん** · 2020/11/05(木) 09:00:41.20

>>906
Rustは去年ようやく並列処理APIが固まったレベルだから、将来性はともかく現時点ではまだヨチヨチ歩きな幼児と見てる
十年後に期待

**デフォルトの名無しさん** · 2020/11/05(木) 09:25:14.26

Rustは今でも面白いよ。標準ライブラリが貧弱でも大して困らんけ、並列ランタイムだけは標準に入れて欲しかった。
メジャーなtokioとasync-stdの両対応してる場合も有るけど、大抵枝分かれしてて共存も出来ないから無駄なんだよな。

**デフォルトの名無しさん** · 2020/11/05(木) 10:34:46.60

>>908
Javaで言えば1.0レベルだろ
当時から面白かったんで使ってたけど、実用性は微妙だった。特にファイルIOとコレクション

**デフォルトの名無しさん** · 2020/11/05(木) 10:59:39.83

参照カウントって、本当に「言語の仕組み」なの？

**デフォルトの名無しさん** · 2020/11/05(木) 11:05:21.21

こっち↓で聞いてみたら

GCは失敗。メモリは自分で管理せよ！その2
http://mevius.5ch.net/test/read.cgi/tech/1447856699/

**デフォルトの名無しさん** · 2020/11/05(木) 11:08:21.64

C#が充実したらGoが要らなくなる論は全然わからんな。
一体どういう理屈なんだろうか。
同じサーバサイドでもお互いに分担するエリア全然違うくないか？
というか、全然手薄でもなかったし。C#。

**デフォルトの名無しさん** · 2020/11/05(木) 11:27:44.88

ファットなランタイムに依存しながらも比較的デプロイ時の取り回しが良い
わりと固定されたツールセットで無難に迷わずに使える
まあ近いと言えば近いんじゃないかな
C#をバリバリ使ってるとこだとGoの出番はないだろうし

**デフォルトの名無しさん** · 2020/11/05(木) 11:59:24.87

C#ならGUIもサービスも書けるし遅くもないから、Windowsアプリを書くなら鉄板の選択肢だよな
どうしても高速化したいとか解析されたくない時だけC++
ただ事前にランタイムのインストールが必要なんで、Linuxとかマルチプラットフォーム展開の敷居がちょっとあるんで、CLIツールとか書いてもGoに比べてデプロイが不便
充分に住み分けされてるからどっちを使う論争は不毛

**デフォルトの名無しさん** · 2020/11/05(木) 12:39:02.69

Windowsアプリを作るときの鉄板に関しては異論はないが、C#のデプロイはガッカリ仕様だぞ。
.Net 5でも。

**デフォルトの名無しさん** · 2020/11/05(木) 13:08:26.70

SCDも知らんのか

**デフォルトの名無しさん** · 2020/11/05(木) 13:22:01.75

>>916
SCDでデプロイしたことあるか？
むちゃくちゃファイル数多いぞ。
SingleBinaryが自己展開ではなく直接アセンブリをロードする形にやっと.Net5でなったけど、そのままだとSingleBinaryと言ってるくせに数ファイル漏れるので、
それも完全にSingleBinaryにするには結局自己展開ファイルにせざるを得ない。

ファイルサイズも結構でかくて、最近は使ってるメソッドのみと言う形でTrimできるようになったけど、誤爆もまだまだあって実用とは言えんし。

ホントにやってみ。期待してただけにすごくガッカリしたから。