Go language part 4
レス数が1000を超えています。これ以上書き込みはできません。
【悲報】.日本人、ステマに.簡単に.洗脳される(笑).幼稚.な.多数決.カルト.信仰の.末路
(１)日本人.の.精神.を.腐敗.・.堕落させ.愚民.化.させろ
(２)日本人.の.女.を.集中的に.狙い.洗脳.しろ！
(３)ネトウヨ.、ヘイト.スピーチ.等の言葉を.浸透させ.、同胞へ.の批判.を.封じろ!
(４)「同性婚・LGBTを全面肯定しない者は差別主義者だ！」という雰囲気を作れ!
(５)中身のないアニメを流行らせ、クールジャパンをオワコン化させろ!
(６)「未だにガラケーの奴は笑い者」という雰囲気を作れ.
(７)「日本人の男VS日本人の女」の対立を煽り、分断しろ！
(８)日本人同士で恋愛・結婚させない、子供を生ませないよう誘導しろ。
(９)日本同士で結婚していたら離婚させる方向に仕向けろ
(10)海外セレブやハーフモデルをもてはやし、「日本人は劣等人種だ！」と植えつけろ。。
(11)イケメンブームを定着化させ、「男は外見が全てだ！」と洗脳しろ.
- ソース -
電.通.グループ.会長.成.田.豊.は.朝鮮.半島.生まれ
http://ja.wikipedia.org/wiki/成田豊 Python&MSの最強タッグに勝てるとは思えん
Pythonの生みの親、グイド・ヴァンロッサム氏、「引退は退屈」とMicrosoft入り - ITmedia NEWS
https://www.itmedia.co.jp/news/articles/2011/13/news066.html MSがPythonに力入れる夢見てるやついまだにおるんやなw 言語には得意分野があることを理解できないニワカが大杉 >>9
pythonは可読性上げるために文法強制するくせに、関数呼び出しばかりで可読性劣悪なのがちょっとなぁ。 Goはその関数呼び出しを1関数あたり5行くらいに分けてダラダラと書いてるだけだろ？
その分Goは情報の密度が低くて楽に読めるから、単位時間あたりに読める行数を可読性と定義するならまあGoの可読性はPythonより高いわな >>12
なんでPythonが関数呼び出しばかりだと思ったの？
なんで関数呼び出しばかりだと可読性が低くなると思ったの？ >>14
err = Hoge()
if err != nil {
return err
} >>16
俺はこれ好き
try-catchよりシンプルで読みやすい これが読みやすいとか、たぶん1000行程度のプログラムしか書いたことないんだろうな >>19
ごめん
俺土方じゃないからコード書かないんだ goって、
err = Hoge()
if err {
return err
}
とは書けないんだっけ？ Hoge() の戻り値が boolean じゃないとね 頻繁に出てくる定型コードなんだから言語側は糖衣構文実装しろよ err = Hoge() && return err
俺ならこうする Rust見倣って
result := Hoge()?
にしとけ すまん
if err = Hoge(); err != nil {
return err
}
以外の書き方したことないわ >>27
エラー以外の戻り値のある関数使ったことないの？ Proposal: A built-in Go error check function, "try" · Issue #32437
https://github.com/golang/go/issues/32437
This proposal has been closed. Thanks, everybody, for your input. >>30
な？ これで良いとかおもってるやつなんて
ロクにちゃんとしたコード書いたことすらないのがバレバレ
しょぼいサンプルコードぐらいしか書いたことないんだろう >>34
reject されたからどうにもならない えっ、なんの改善もされないの？
だとするといろんな意味できついね 昔go使ってスレッド同期系の不具合を調査しようとしたが、ログを入れてもスレッドid的なものが一切取得する手段が無くて驚愕した。
そこでmutexをAPI入り口に入れて回避しようとしたが再帰mutexが無くて断念した。
調べたら再帰mutexは使うべきじゃ無いから提供しないらしい。ならば作ろうとしたらスレッドid的な識別子が無いから作れない。
昔のgoは識別子を取れたため再帰mutexライブラリが落ちてたがそれも使えなくなってた。
なんだろうこのクソ言語って思った。 Discordに逃げられてつらい…
実装言語を「Go」から「Rust」に変更、ゲーマー向けチャットアプリ「Discord」の課題とは
https://www.atmarkit.co.jp/ait/spv/2002/10/news038.html >>16
わかりやすくていいじゃん。
このパターンなら、return Hoge()できないか考えるけど。
>>19
1ファイル1000行は異常だと思うぞ。
>>30
複数の戻り値あるときでも、>>27の書き方はできるぞ。 >>30
その一言で馬脚を現すとはなんという出オチ感
ディスるなら言語仕様くらい勉強して出直してこい
具体的にはGoではタプルで戻り値を返してくるのが一般的
一個の戻り値なんて、普通に使っている人間からしたら特殊な使い方だよ
つまり、使ったことが無い素人さんだね貴方 >>42
さすがにGoスレで多値返却知らないやつはいないてw
可読性の観点で同じパターンと認識してるのかどうかの違い
ちなみにタプルではないよ >>45
型としてのタプルではないから確かに無いといえば無いね
順序を持って並んだ変数の組、という物は構文としてタプルと表現すべきかと思ったので
タプル型って特に使い道思い付かないし要らんよな？
とか思ってたらissuesの#41148でタプルをチャネルで送りたいとかあったわ
なるほど >>35, >>37
これマジ？
GolangやめてRustやります Rustなんて数年経ったらScalaと同じでただの負債になるだけなのによくやる気になるな
個人で趣味程度にやるなら良いと思うけど RustはMSが正式採用してから始める、で遅くないと思う RustはOS寄りな案件に突き進むんじゃないか？
シェルじゃなくカーネル
>>39にあるようにGC不要であるという強みはドライバ記述に最適ということを意味するから 小学生レベルでも読み書きできるGoは負債になりにくいだろ
Rust使ってるやつは奴隷身分の癖にアーティストぶって負債を生むウンコマン Goはあまり変なフレームワーク使ったりしなくて標準ライブラリが基本なので、その意味では負債化する要因が少ない
廃れるのは言語よりも先にフレームワークだからね Rubyは廃れたけど
Railsが元気なお陰でバッテリーとして生かされてるじゃん いいかわるいかは別にして >>53 は真理
たとえば Lua なんて糞言語もいいとこだがいまだに
ゲーム組み込みスクリプトとしてちょこちょこ使ってるケースがある COBOLが負債化した原因は小学生レベルじゃ読み書きできないからなのか？ go2でジェネリクス入ったら今のコードは負債になりそうだけどな お前ら負債負債って言ってるけど、そもそも「負債」の定義は？ その言語のコード資産の価値を(最新の言語だったら発生しないはずの無駄な)維持費が上回り始めた状態だろうな 負債ってヨタ話なんて信用なんねー
損益分岐点越えたら切り替えるのが当然
「政治」的な問題だよくだらない 先週はイテレータ知らんやつばっかりで
今週は技術的負債知らんやつばっかりなの？
既存システムへの機能の追加変更時に
クリーンなシステムであれば必要ないであろう作業が
著しく多く必要になるものを負債と呼んでる
相対的なものだから単一指標で数値化することはできないんだけど
「あのシステムの修正は面倒だからやりたくない」と感じる度合いと正の相関がある >>62
それが「政治」的問題
技術的な問題じゃないね wikipediaくらい見ようぜ。
Technical debt (also known as design debt[1] or code debt, but can be also related to other technical endeavors) is a concept in software development that reflects the implied cost of additional rework caused by choosing an easy (limited) solution now instead of using a better approach that would take longer.[2] だから技術的な問題じゃないと再度主張
一般的なプロジェクトマネジメントとかのスレに行け >>65
君が技術的な問題じゃないと思うのは自由だけど自分勝手な定義を人に押し付けるのは止めようや 技術選択や設計選択の問題は多分に組織的要素や人的要素を含むものなのにね
その辺りの要素を考慮しなくていいのは末端の作業員だけ ここが何のスレだか言ってみろ
プロジェクトマネジメントのスレに行けと 技術的負債をどう返済するかがプロジェクトマネジメントやろ
元々は「Goは他言語と比べてどれだけ負債化しにくいか」という話じゃなかったか？
技術的負債の発生要因はプログラミング言語のバージョンアップ以外にも色々あるけど プロジェクトマネジメントじゃなくてエンジニアリングマネジメントだろ
自社サービスだと、こういうのを技術的な問題と思ってない奴はまずいない おまいらってほんとマネジメントとかそういうの好きだよな >>68
末端の作業員にも使われる言語になったということ
日本でも労働者言語としての地位が定着してきたのかな >>72
単にGoについて話すことがないだけなんだが… 間違った英語で日本人として恥ずかしい…
go getじゃなくてgo to getだろ… >>71
これは激しく同意する
上流/下流とか関係ない >>54
Goが負債化する要因は、コードがコピペだらけになって膨らむことだよ。
Goはコードを絞る手段を提供していない。だから俺はGoを使わないことにした。
長期的にメンテナンスする場合にコストが跳ね上がる。
これが顕在化するのはこれからだね。
逆に、動けばいい使い捨て用途の高速版Pythonと見るなら、全く問題ない。
だから完全に廃れるって事もない気もするが、大規模開発向けのメインストリーム言語として使われることもないね。
今もシェアなんて君らが馬鹿にしているRubyと比べてもゴミ以下でしょ。
自分が使っている言語が廃れるのが嫌なだけなら、今一番無難なのはC#だよ。
勿論Goより仕様が大きいから全部勉強するつもりなら時間がかかるけど、
Goが持っている機能だけ使うつもりならGoの修得と手間はほぼ同じ筈だが。 自社サービス系に関して言うと、C#はエンジニアがWin系の人間に限られてしまうために採用活動で苦労することになり、追加の人的コストが発生する
その意味では負債だ
C#は変わりつつあるとはいえ有名なSaaSとかでも開発環境はやっぱりWindowsとVSとIISだったりするので、Web畑のエンジニアには敬遠される
これ実話な C#ね……w
どういうところで働いてる人がGoを批判してるのかがよくわかったよ >>80
俺が言ってるのは純粋に言語についてだ。
ただ現実的に採用で困る、というのは大きな意味があるが、
それ言ったらGoもWebエンジニアにとってはGoは新規に学ばなければならない言語であって、
PHP/JSと比べたらGoなんて話にならんだろ。
Go選ぶ時点で間違いだよ。
あと、Goにもある機能の範囲だけC#を学ぶだけなら労力は同じだよ。
ただしPHP/JSのエンジニアの方がネットワーク周りの「知識」があるから促成はできるが、
「プログラミング」は技能に近く、一朝一夕には上達しない。
だから、「正しくプログラミング出来るGo技術者」を育成するとして、
PHP/JS等Web周りの知識がある奴にプログラミングを教えるのと、
C#/Java/C++等プログラミング出来てる奴にWeb周りの知識を教えるのとでは、
一通り座学してあとはググりながらやれ、で済む後者の方が断然簡単だ。
ただしWeb系の場合はプログラミングが大して難しくない範囲で収まるから、
PHP/JSからの促成組で何とかなるもの事実だとは思うが。
ぶっちゃけ、他言語は多機能すぎて、そこまで必要ないからこそ、簡素版のGoが使われる余地があるわけでさ。
そしてまあ、C#がWindows/VS/IISなのは多分事実だろう。
それでWeb系はLinux/VSCode/Apache/Nginxで、それ以外は絶対に嫌なのか？
ならEmacs/Vimと同じで永久に交わることはないだろうね。 >>79
コピペだらけになるって、それはその程度のスキルだからじゃないか？ >>83
論点がブレてるんだけど。
もう少しまとめて話せよ。
雑談はネグれ。 Gopherは他の言語やったことないから自分の使ってるGoが一番だと思ってるんだよ
つまりGopherには何をいっても馬の耳に念仏だよ C#バランスいいよね
Windows/IIS縛りがネックだったけどそれがなくなったから徐々にシェア広げていくと思う Safari, the new IE
Gopher, the new Rubyist C# Gaiji, the new Ruby Gaiji >>87
ただそれは最近はどの言語スレもだよ。勿論C#スレでも。
それを俺は信者化と言っている。
当たり前だけど、どの言語にもそれなりに糞な点はある。
もしそれが無く、他と比べて圧倒的に素晴らしければ、簡単に覇権を取ってる。
それは1993頃のC/C++であり、Cで72%、C++で20%だからC/C++で92%だ。
(その頃のC++なんて今のC++から見れば「それはCだよ」と言われる程度でしかない)
https://www.youtube.com/watch?v=Og847HVwRSI
今はシェア25%弱の言語が3つ並んでいる状況なのだから、言ってしまえば「どれも大して変わらない」んだよ。
だから他言語に糞な点があれば、同程度には自分のお気に入り言語にも糞な点があるに決まってる。
この単純な論理を認められないのは、信者だからだよ。
ただこれは既に言ったとおり、Goスレだけの話ではなく、C#も他も同じ感じだけど。 どんなにここでC#の良さをアピールしても現実世界じゃ古臭い会社やUnityでしか使われないゴミ言語なんだよ…
今後Goみたいに流行るといいね… Javaよりはいい言語なんだけどねぇ
でもJavaと同じ戦場だから……
GoやRustは狙ったのか利用シーンがズレてるんで居場所がある それだけcppが好きならずっとcpp使ってろよ。
グリーンスレッドも知らなかった分際で。 >>92
それが信者の観点だよ。
C#の方がGoよりは1000倍以上流行ってる。
それはシェアからもエコシステムからも明らかだ。
もっともお前らはJavaも流行ってないと言い切るくらい信者なのだとは思うが。
Goはそもそも流行る要因がない。他言語を使える奴が、わざわざGoを使う理由がないから。
だから今後とも今までどおり低空飛行だよ。
新規流入は初心者だけで、エコシステムも今までどおり回りもしないまま。
Rustはその点、明らかにピーキーで、Rustじゃないと駄目な理由が明確にある。
だからわざわざ使う理由にもなるし、今後はしばらくは確実にシェアは増えると思うよ。
ただどこまで行くかは謎だ。FFは死んでしまったし。あれRustのせいだと言っている奴がいるけど、俺もそう思うし。 >>96
どこがだよ。そもそも俺はC#は使ってないし。
>>91の動画見てみろよ。Goなんて一度も出てこない。
Rubyは最後落ちるが健闘した方だ。少なくともGopherに馬鹿にされる理由はどこにもない。
サーバーシェアでもGoなんてゴミ以下だろ。
CやLispをサーバーに使ってるなんて聞いたこと無いが、Goはそれ以下だぞ。
https://w3techs.com/technologies/overview/programming_language GoはMicroserviseとCLIが主戦場
JVMやCLRに依存したくなくて軽量でサクサクコンパイルしたいユーザー層向け
ただGo2が残念な結果になりそうなのとUSで下火になってきてるのを見ると先は明るくない >>97
フロントエンドとしては使われないからそこには数字出てこないでしょ 使ってもいないのに1000倍以上流行ってるってよく分かるなぁ〜ｽｺﾞｲｽｺﾞｲ 他言語も使うしC#も結構書くけど、Go書くことも多いぞ。
何一つ処理系もランタイムもインストールする必要ないから、展開めっちゃ楽だし。1ファイルだし。
デカイって言っても.net coreのscdほどデカくもないし。
というかGoのエコシステムって結構しっかりしてると思うけど。
awesome goとawesome dotnet見比べてがっかりしなければ良いけど。 >>99
いやそれはバックエンド限定の話だぞ。
なおフロントエンドなんて言うまでもなくJSの一強だ。その下をつつけば出てくるが、以下。
https://w3techs.com/technologies/overview/client_side_language
前も思ったが、お前ら違う世界に生きてるよな。 >>103
それはおまえらみたいな初心者は騙されるのかもしれんが、逆なんだよ。
シェアが低いからこそ受注案件を宣伝する必要があるし、
それをやっている時点でまだ数えられるほどしかない、ということなんだよ。
実際、PHPでそんなのやってないだろ。多すぎて無理だし。 >>102
フロントエンドはフロントエンドサーバーのことだよw
クライアントサイドがJSなのは当たり前
こんな話が通じないとは確かに違う世界に生きてるな ことば遊びしはじめたｗｗｗ
フロントエンド←→バックエンド
クライアントサイド←→サーバーサイド
はい、では「フロントエンドサーバー」の定義からどうぞ～😆👍➰ >>107
冗談抜きで知らないんだね
フロントエンドってのはアプリのプレゼテーションレイヤーのこと
プレゼンテーションレイヤーを管理するサーバーがフロントエンドサーバー
Webアプリなら基本的にWebのUIを返すサーバー
クライアントサイドとの違いが理解できたかな？ >>109
そういうのは99.99%の人はBFFと言う。
BFFのfor Front-end、これなんのことか分かる？ｗ
クライアントサイド、ブラウザで動くJSのことだよバーカｗｗｗ
あのさあ、フロントエンド、なんて一般的な英単語なんだから分野によって指すものが違うのは当たり前なわけよｗ
例えばコンパイラ構成にもフロントエンド/バックエンドって用語は使われるわけ。
コンパイラ構成の文脈で「バックエンド？ああサーバーのことね！」なんて文脈無視した理解する馬鹿はいないわけ。普通。
ところがここにいたわけ。それがお前ｗｗｗｗｗ
Webの分野ではフロントエンドはクライアントサイドのことなんだよバーーカｗｗｗｗｗ
さすがに腹痛ぇわｗｗｗｗｗｗｗｗ BFFで通ってるものを「フロントエンドサーバー」とか言っちゃってたわけ？
オレオレ用語にしてもセンスなさすぎィ…
今IT用語辞典でBFF必死に調べてそうｗ
恥ずかしいオレオレ用語晒す前にもちょっとは調べりゃよかったのにｗ >>110
残念だけどBFFの解釈も間違えてるよ
Webアプリの開発やったことないんだろうけどさすがに少しは勉強したほうがいい BFFはAPIをホストするところであってUIをホストするところじゃない
クラシックな3階層に当てはめるとアプリケーションサーバーの一部 ふ、フロントエンドサーバーｗｗｗ
それバックエンドにあるわけ？ｗ フロントエンドサーバーっての俺も初めて聞いた。
こうやってオレオレ用語ができていくのか。 俺はフロントエンドサーバ使ってるけどな
ページにリクエストが来たときフロントエンドサーバでJavaScriptを1から生成してブラウザに返してる
ITの世界でも鮮度は大事だからなるべく出来たてのスクリプトを提供したいんだよね
思いやりの気持ちを持たない現代のガキに足りない精神を維持するためにもフロントエンドサーバは大事だよ その「ページにリクエストを送っているもの」がフロントエンドなんじゃないかなぁ >>116
わかる
自分も思いやりの精神を忘れないために画像は全部リクエストが来る度に作ってる
1日10件ぐらいしか対応できないけどリクエストが来たらPhotoShopをすぐに開いて画像を作ってフロントエンドサーバに格納してる
職人の心を忘れちゃダメだよね メルカリの人のプレゼンとか見てみなよ
フロントエンドをどういう意味で使ってるか分かるから
https://youtu.be/zYAt569F9qA?t=1057 イテレータ、技術的負債、フロントエンド/バックエンド
お前ら一般常識知らなすぎ >>119
バックエンドフォーフロントエンドとか
こんがらかってきてファックって言いかけてるw >>121
1週間前の無知な自分に気付けて良かったじゃない
Fuck my ignorance! Grazie mille, 5ch amici!! 無知な私め！どうもありがとう、5chの友よ！！
かな？
amiciはイタリア語っぽい
友達の男性複数形かな
Grazie milleは何語だろう？
千のありがとう→Thanks a lotみたいな意味だと思うけど… dataA, err := getDataA()
if err != nil {～
dataB, err := getDataB()
if err != nil {～
ってやりたいんだけど
Bの方のerrが二重定義だから怒られる
var dataB []DataB
dataB, err := getDataB()
if err != nil {～
ってやると、VSCodeに「dataB []DataB declared but not used」って怒られる
こういう場合ってどうするのがセオリー？ >>124
前半は、そんなエラーにはならない
https://play.golang.org/p/A3Qg-byXg0p
後半はdataBを使用する部分を書いていないだけ >>124
よく見ると、後半は二重定義になるから未使用警告にはならない
見直すこと >>125
大変失礼しました…
仰るとおり、dataB使う処理書いてないで怒られてるだけでした ここでバイク乗りがこそっとフォークエンドも混ぜておきますね めちゃくちゃ腹立わ
Go推すまで密林不買だな
AWS、プログラミング言語「Rust」を重視する理由示す--エンジニア採用中 - ZDNet Japan
https://japan.zdnet.com/article/35163089/ >>130
どっちも高級C言語という立ち位置だと思ったが違うのか >>131
RustはモダンC
Goにその役割は無理
別に悪いことでもないと思うが
「なんでもGoでできる！Goサイキョ！！」
とか言ってたらRubyみたいに鼻摘み者になるので注意 >>131
関数呼び出し機構が違うため、Goにはドライバなど低レベル処理が書けない
その代わりにGoは超軽量なgoroutineと可変なスタックを手に入れた
これによりWebAPIなどサーバプログラムで数百万の同時接続でもヘタレない性能を叩き出す
プログラム内プロセスと言えるスレッドに並列処理を頼る他の言語ではメモリ消費の問題で、この性能を求めるのは非現実的
コンテキストもデカけりゃスタックもデカいため >>131
前にGoからRustにシステムリプレースした会社の話があったが、これはまた話が違う
GoはJavaなどと同じくガベージコレクト(GC)機構を持ってる
時々発生するGCの時にはms単位で他の処理が遅延する
この遅れを嫌ったためGCを使わないRustで処理時間の安定を計ったため
RustではGCではなく所有権という特殊な考え方でメモリを管理している >>131
Goはそういう低レイヤーなことは危険だから使えないようにしますって感じの言語 ごー言語勉強しようと思うんですがフルスタックだとどのフレームワークがメジャーですか？ 俺はecho使ったけど、特にバニラでも問題はない感じ
パラメータの解析とかCORS実装とかで多少は便利になる
テンプレートはこれどこか改善されてる？ >>136
フルスタックなフレームワークを使うこと自体がGoではメジャーではない >>136
答えとしてはGinかRevelと思うけど
実態は>>138の通り 趣味でプログラミングしてるんだけど今はPythonとc++/C#あたりを触ってる
goも勉強したらPythonの代わりとして使えるのかな？
それとも趣味レベルなら覚えるだけ無駄？ >>140
趣味レベルならばオススメできない
Pythonは拡張に拡張を重ねた巨大な仕様で一つのやりたいことに色々な書き方ができるので、初心者でも自由に書ける言語
専業プログラマーでない研究者でも楽に望むままのプログラムを書けるため、利用者が桁違いで膨大なライブラリが日々作られ続けてる
Goは不自由な仕様のかわりに大量の非同期処理などを高速に処理できる
これは使いどころが限られるし、利用者も限られる
ただし使いどころでは驚異的な性能を誇ることが存在意義 ginでオレオレwebアプリを勉強がてら作ってるのだけどtemplateベタ書きなmvcっぽいので参考サイトやリポジトリないですか？
日本語だとjson返すAPIばかりなので英語でもいいので JSON返すWebAPIが大の得意だからwebページの用途に関してはブログを書く気がないんじゃないかな？
webページでは画面遷移は控えめにシングルページ主体で、JavaScriptによってセッションキー付けてWebAPI叩けば用は足りるだろうという推測
これは一般的に聞いた話ではなく、自分がstrutsページ遷移とかでセッションのデータを管理するのが大変なんで、なるべく使いたくないなーと思ってるための希望的妄想なのですまない >>140
趣味でやるならLISP forth Nimあたりのマクロの強い言語のほうが面白いよ。
飯の種としてはおすすめしないけど。 自鯖で静的なHTML（貧弱なレンタル鯖用のサイト）を生成するスクリプトを走らせてたんだけど
それをGoogle compute engineの無料枠に移行しようと環境構築してたら
cpanm（perlのモジュール管理ツール）のDBIのインストールのテストで、メモリエラーでコケた
goは余計なリソース一切なく単体で動くという点で、弱小サーバをどう使うかという観点でも有望な気がする >>146
ちゃんと読んでないけどHugo使えば？ >>147
こんなのあったのね…
もうオレオレでデータ入力用の管理サイトと、
構造化してリンクとか全部付与してサイト生成する部分まで作っちゃってる(´・ω・｀)
まあ言いたかったのは少なくともPerl（+cpanm）よりも貧弱な環境で動きそうということ >>12,>>145
関数呼び出しを気にするならマクロのある言語使え
というわけで、lispよりも強力なマクロのあるJuliaを使おう > lispよりも強力なマクロのあるJulia
これ本当？ 最強のマクロったら gcc の inline ではないだろうか？ >>150
「JuliaとLispのマクロの比較」っていうタイトルのブログを読んでそう思った。
リンク貼りたかったけど、はてなブログのリンクはNGワードっぽいから自分でググってくれ マクロでlispに勝てる言語ってほとんどlispじゃね？ 強力という言葉の意味次第だろう
そのブログにも書いてあるけど、
何でも出来るという意味ならlispの方に歩がある 最強のマクロがある言語はどれなのか
C言語とLisp, Julia, Nim, Rustの5言語に精通してる人なら答えられるかもしれない…… juliaのマクロはschemeの健全マクロみたいなもんなのかな？そうなら健全なマクロでも変数補足しちゃうはずだよ。マクロに関してはastベタ書きするLISP族が一番適してるとおもうけどな デフォルトで変数捕捉しません。
させたいときはエスケープする。 そんなにマクロつかいたきゃ
ビルドの途中でC/C++のプリプロセッサを間にかませや そんなオモチャみたいなマクロの話じゃないから黙ってろ
真のマクロの話をしてるんだ GO2のリリース日を教えてください
来年にはきましゅか？ 来てもなぁ
とりたてて困ってない
滅多に使わなくて実感ないから正規表現が遅いと言われてもピンとこないし int64をuint64に変換する簡単な方法って無い？
当然に収まらないからマイナス値はif文で0にしてあるものとする
何が困ってるかと言うと、ファイルサイズはosパッケージではint64なのに、zipパッケージではuint64なんで
もう面倒なんで、文字列にしてハイフン取っちゃおうかな httpで読み込んで
https://qiita.com/ytkhs/items/948f516ec82c82eaa882
とかXMLパースするだけだろRSS
JSONは要素のコメントなしで読み込む機能はあるけど、XMLはどうだったか知らん
名前空間も Go製のrssリーダーはすでに幾つかあるが、作れるかであって使えるかじゃないから、自作する話だと判断するのが妥当
rssの要素技術はhttpとXML
rssのURLをブラウザで叩けば最低限読めるのだから、他に必要な技術はない
作れるかと聞かれているのだから、要素技術をサポートしているか、という質問だと判断するのが妥当なのでは？ GoでGUIアプリのRSSリーダーを開発できるかという質問なのかな？
QTくらいしか俺は触ったことないけれども 組み込み関数じゃなくて言語の基本仕様レベルだよ
って話じゃないの GOってもしかして人気無い？
2～3年前と比べて下火になってる？ go routineって windows APIで言うと単なるファイバーだったのね。何か昔に戻った見たい。
それなら、パフォーマンス気にする処理なら自分でスレッドとメッセージループでしっかり組んだ方が早いし確実だと思った。
初期のgo routineの中でビジーループすると他の処理が全部止まるってのも笑えたし、最新のgoでの改善策はAPI呼び出した時にディスパッチされますって。プリエンティブ無しの初期のRTOS見たいな動き。VBAのdo procだっけ、ループ中に他の処理動かすやつ。あれと同じ。 じゃあGo捨ててErlang/Elixirを学び直すんですか？
貴方、正気ですか？ またVScodeでアップデートしたら
go get package failed: err: exit status 1: stderr: template: main:1:9: executing "main" at <.Module.Path>: nil pointer evaluating *modinfo.ModulePublic.Path
とか出てimportできない！とかほざくようになってしまった
Go自体のアップデートを1.14.2で止めてるからだろうか？ >>176
1.14.13まで上げたけどダメ
他のプロジェクトでは問題なし(解せぬ
go env GOPATH ではちゃんとパスが通ってる
setting.jsonは共通 >>176
ほかのプロジェクトと比較
OneDriveとかユーザーディレクトリからcのサブディレクトリに移したら出なくなった
空白入りとか漢字のパスといった国際化への対応が、またダメになったのかもしれない >>173
goroutineはファイバーじゃなくて(グリーン)スレッドだろ。 大体がスタックを関数呼び出し毎にチェックして拡張する仕様がどうかしてる
これがあるので他と比較するのはあまり意味がないのでは？
そんな変態的な仕様が過去にあったなら、それとは比較できる
勉強不足で知らんから >>172
JSとPythonに比べたら人気はない
ただしそこそこの速度が出るので実用的 グーグルの秀才たちが内輪向けに作った言語だから一般向けじゃないんだよなあ
変数の宣言～初期値代入の形態が何種類あるかってだけでも初心者を脱落させるに十分 繰り返しは無理してでもforに集約してるクセになんか片手落ちだよなｗ マイクロサービスってログイン認証とかどうやってるんですか？
ログインユーザーのトークンをDBに保持してそれぞれのマイクロサービスでDB情報を共有したりするイメージですか？ >>184
JWTを送る方法もあるというか、どちらかと言えば主流？
俺は認証フレームワークの都合で使ったことないけど >>179
う～ん、微妙。同じ事言いたいだけかな。複数のファイバーって方がしっくり来る。結局、1万個のgo routineがあったら、動的に5個とか10個とか小数のスレッドが立ち上がり、メッセージループで逐次処理してるだけだから。
まあ関数途中から再開出来たりするのは言語仕様として使いやすくしてるだけ。暗黙的にasync構文が自動挿入されまくっているだけ。 普段C#書いてるけどゴルーチン大好きよ
圧倒的に楽 普段Rust書いてるけどゴルーチン圧倒的に楽だね
たまに名前が気に入らんだの、ググラビリティ低いだの聞くけど
その辺はCでもGoでもなく、Rustのが辛ぽよ >>187
プリエンプションするからファイバーじゃなくてグリーンスレッドなの。 n:mでぶん回してタスクのスティールもするし、それをファイバーとは呼ばんと思う。 とはいえスレッド使いたいことはある
重い計算処理を完全に占有させたい時とか >>190
プリエンプションするの？初期は誰かがループすると他のgo routine呼ばれず、その後、改良されてAPI呼んだタイミングではするけど、純粋な計算とかのループはNGってください記事までは見たけど。最新だとするの？どんどん本物のスレッドに近付けて処理重たくなって最終的に本末転倒な結果にならないのか？ >>188
c# なら taskとgo routineって殆んど同じかなと思ってしまうがどうなの？c#ではスレッド直接使ってたって話し？ for i:=0;i<n;i++ {} というループでも1.2以降ではスタック操作でスイッチングが走るようになったから、for {} と書かない限りは気にすんなという記事を読んだ >>195
そう言う事なのかぁ。そんな単純ループでも切り替えチェックを毎回実行してるって性能面ではすごいデメリットだな。 >>196
性能では不利だけど、それはGoの優位点でもある
Goはスタックつまり自動変数の領域を初期値2KB(Javaのスレッドの1/500)しか持たず、それを必要時に拡張する
そのため、goroutineを10000個作ってもスタックは初期値なら20MBあれば良い(Javaのスレッドだと10GB)
そんなにgoroutineを使うか？という話だけど、webAPIが同時接続10000とかの場合を想定(昔は10K問題として大問題)
今でも300万同時接続をJavaとかのスレッドで扱おうとすると3TBの仮想メモリが最低限必要になるけど、Goなら最低6GBで済む(スレッドのスタックサイズをデフォルト値で使ったら)
そんなわけでスレッドのメモリ消費を何とかしない限り、webAPIにおいてGoのアドバンテージは無くならない >>197
いや、go routineと本物のthread(javaも同じ)で比較するとその通りだと思う。
過去のwebフレームワークが1要求を愚直に1スレッドに割当てして性能限界に至ったのも真実。
だからgo routineを使えば、同じく1要求を愚直に1 go routineに割当したとしてもgo 内部で複数のgo routineを1つのスレッドに割当する事で極力性能、メモリ使用量を抑える事が出来ますって事だけ何だよな。
そして、スレッドのコストが高いってのはある意味常識で、スレッドは最低限に抑えましょうてのは昔から常識。方法としては、古典的なメッセージループ、スレッドプール、ファイバー、タスク、async構文、nodeの全シングルスレッドとあらゆる方法がある中の一つがgo routine。
中身は、まあ他の手法から抜きん出て便利なのか否かは歴史がこれから証明する所。
apacheが歴史的に1要求1プロセスのforkベースだったから、webはプロセスから見たらスレッドの方が軽量って事で性能面は見過ごされて来た歴史がある。組込みシステムはリソース命だからかなり初期からスレッドの高コストはしっかり意識してモノ作りしている。 Unity界隈はどうなんだろ？
基本はC#で部分的にgoroutine使ってるような話を聞いたことあるが正確なところは不明 C#のTaskは非同期+スレッドプール(OSスレッド)
>>197
10年くらいまえの認識だね GOはホント話題無いね
いい意味で枯れてきてるのかもしれないけどとにかくトピックが少ない 新機能に渇望してないのが大きい
期待の新機能であるジェネリックが欲しい層もあまり数は居なさそうだし
もう、あれば便利だろうし使うけど特に今すぐには要らないよなって
弱点としてよく挙げられる正規表現も、実用性が無いほど遅い訳じゃないし、探せば高速なライブラリもあるんだろなとか思ってる >>203
正規表現そんな遅いんだっけ？
Goだと文字列メソッド使うからあんまり気にしてなかったわ >>202
もう出て10年くらい経ってるんだよな
大きな新機能の追加も無さそうだし
パフォーマンスを極めるフェーズになってるから話題ないねえ 例外キボンという声は聞いたことないから、やはり
今時例外なのﾌﾟｰｸｽｸｽとみんな思ってると考えていいかな？ コストの高い例外フロー制御はともかく、
例外専用の戻り値は欲しいわ。 Javaのだと、シグネチャに無い例外を返せないからインターフェースとして呼ぶのに困るし
C#のだとガバガバ
結局、実際には何が帰るのか分かりませんとなってカスタムしたExceptionで受ける一択
更にそのため常にメソッド内でカスタムExceptionにラップするためのcatchを書かないとならんし
面倒すぎたよね例外(過去形でかくな コールスタックを一気にジャンプするとかおぞましいことはいらないよ
単なるgotoだし if err書いて回るのに比べればgotoのほうがマシでしょ
それにコールスタックを一気にジャンプするのは言語による実装の詳細で必須事項じゃないよね 文句が出てないという根拠は、そこそこちゃんと使っている人からの不満点として見たことが無い、というもの
反証は受け付ける 突っ込み所しかなくて、えー頑張ってね
きっと良いこともあるよ var exp = flag.Bool("exp", true, "export")
で、-exp false しても *exp が false にならん
どこを間違えてるのか https://play.golang.org/p/gcNo0xC4tUj
exp:true, CommandLine:&{0x4a6ee0 /tmpfs/play true map[exp:0xc000108040] map[exp:0xc000108040] [false] 1 <nil>} Win32 APIもエラーコードチェックばっかやらなきゃいけない
それと大して変わらんよ
低レイヤーのプログラミングはいつも同じ 判明というか多分バグ
他のフラグは
-cred admin.json
とかの形式で取り込めるけど、
expは(多分flag.Bool()は)
-exp=false
と指定しないと取り込まれない ああ？go documentで検索したら、non-boolean only
仕様なの？何で？because the meaning of the command? 文字列で取り込んでbooleanに変換しなきゃならんのか
めんどくさい…… go routine リーク周りはまだ話があるんじゃないの？ >>222
デフォルトtrueのフラグパラメータって設計が良くない気がするなー
俺なら、-disableExport(デフォルト:false)って引数にするかも。で指定するときは、
go run main.go -disableExport
って感じでtrueとか、falseとかつけないかなー。なぜならフラグ指定してる時点で「true」だから >>231
だよね
go好きだから......... >>229
https://qiita.com/kawasin73/items/7f04b2943bdbb7588c3e
でも筆者が勘違いしていたので、単に一度ヒープから確保したメモリはヒープのプールに入るため取得されたまま、になってただけと訂正入ってる
ヒープが利用終わったら解放されると思い込んだ勘違いという結論になったのでは？ >>233
いやそういうリークじゃなくて、正確にはチャンネル待ちリークというかそういう感じの話。 待ちなのにリークなん？
送ったはずのチャネル通信が届かない事案だとしたら、それは通信の問題でリークじゃないよね いやだから通信の問題で実質リークというかgoroutineが溢れるって話をしてるんだが。。
kube並の大きさのプログラムで発生したらデバッグできんの？って話をしてるんだよ。 チャネル送信が送られないなんて報告があるの？
と言ってる 検索しても233にある誤解が原因だった記事くらいしか見つからなかったから、具体的な記事のリンクを張ってくれるのを待ってる ゴルが解放されないって話なら永続リソースとかを
掴んだまま離さないとかそういうお行儀の悪いプログラムしてるからだよ
動的言語と同じ感覚でプログラミングするとそういう痛い目にあう 無理に使おうとしなくてもええんやで
ウチはインフラ部分はほぼgoに置き換えてる
でもc#の方がすこや もっと流行るかと思ったけど全くだよな
やっぱ言語仕様に癖がありすぎる 癖っていうか糞仕様が多い
いまどきこれ？？みたいな 国内でのGo普及活動家の母体メルカリのGoエンジニアたち全然情報発信しなくなってて草
2の対立とか、そもそもの言語仕様の酷さとかに気づいたのかな >>247
最近ソフトウェアデザインに記事書いてたよ
レベルがクソ高くてますます初心者置いてけぼりだろうな goって、特定の構造体が目的のインターフェース実装してるか見分けるのむずくない？みんなどうやってるの？ >>249
https://play.golang.org/p/0MGZkqhS6Oe
こんな感じでエラーチェックしてるかな
./prog.go:20:2: cannot use &StrE literal (type *StrE) as type IStr in assignment:
*StrE does not implement IStr (missing Func2 method)
./prog.go:21:2: cannot use &StrE2 literal (type *StrE2) as type IStr in assignment:
*StrE2 does not implement IStr (missing Func method) 前スレのこれは対応してほしい……
https://play.golang.org/p/XRFmBiqhqJp
インタフェースAを返すメソッドを持つインタフェースB。
そのメソッド実装がインタフェースAを実装しているポインタを返しても、
./prog.go:34:4: cannot use &Base literal (type *Base) as type IBase in assignment:
*Base does not implement IBase (wrong type for Sub method)
have Sub() *Sub
want Sub() ISub
と、インタフェースAを返しているとは認められない。 >>250
え、ビルドするまで分からないってこと？クソ面倒じゃない？
あと、ってことはパッと見ただけじゃやっぱ分からんってことかー。。 あ、でもそれなら実装漏れに最低ビルド時に気づけるってことか
たしかにその方法良いですね。真似します。 >>248
気が向いて買って読んでみたけど
たいした内容じゃなかたぞ GODOTってゲームの開発環境あるんだがGOなのかと思ってたよ >>253
一番の利点は、メインのないライブラリプロジェクトでメソッドの実装ミスを検知できること
テストでもいいんだけど、漏れとか >>256
外部のパッケージ内で、目的のインターフェースの実装探すときどうしてる？
ideとかで実装済みクラス一覧見れたりできるのかな VScodeでgo.modがパッケージ更新できなくて悩んだ
結局コマンドラインから go get -u で取得したら GOPATH /pkg/mod/... に最新版が取得できた
VScodeのgo拡張って変な動きとかするなぁ ubuntuのi386って、もしかして32bit？
goをインストールして動かそうとしたらファイル形式エラーで実行できなかった
i386捨ててamd64でやりなおし >>260
amd64をインストールし直したら動いた ものすごい当たり前の落とし穴なんだけど
os.MkdirAll() で os.ModeDir だけ指定してたら、Linux に行ったら権限不足でファイルを読み書きできなかった
アホか自分は！当たり前すぎるわ！orz goエンジニアって0.5割ぐらいの超人エンジニアがいて、残りはマジでカス未満のエンジニアしかいなくないか？
ライブラリよく作ってるようなエンジニア以外の業務コード見たら吐き気するんだが同士おる？ >>263
それ何系の会社？
メルカリ界隈じゃないよね？ Ruby/Go の神、Vagrant, Terraform, Packer の作者、
今世紀最大の起業家、HashiCorp のMitchell Hashimoto
皆、彼を参考にしてる >>265
お前KENTAガイジやろ？
ここでクソみたいな宣伝すんなボケ >>266
KENTAって誰ですか？
貴方のせいで検索して動画を再生してしまいました
貴方のせいでKENTAさんに収益が発生しました >>263
それ〇〇エンジニアの全てが同じ状況だろ、それとも〇〇言語だと超人が増えるのか？ RubyをNGすればケンタガイジも自然に消えるよ
Go使いならRuby触ること無いから問題無いっしょ ルビィ/Go の神、Vagrant, Terraform, Packer の作者、
今世紀最大の起業家、HashiCorp のMitchell Hashimoto
皆、彼を参考にしてる KENTA
HashiCorp
KENTAガイジ対策として上記単語をNGワード設定しておきましょう。
プログラム板で二度と不快な投稿を目にしなくてすみましゅよ。 あとrubyのNG登録が浸透してしまったからか最近ルビィて書いとるぞそいつ。
ルビィもNG登録や。 Linuxはinotify、WindowsはWMIを使ってディレクトリへの更新を検知してくれるパッケージって出来ないかな
iOSにも同じような機構はあるだろうし ル・ビぃ/Go の神、Vagrant, Terraform, Packer の作者、
今世紀最大の起業家、ハシCorp のMitchell ハシmoto
皆、彼を参考にしてる あーあ、意固地になっちゃった
お前らガイジ揶揄うのもほどほどにしとけよ？ｗ >>275
元々価値の無い駄文を垂れ流して鬱陶しかったけど、日本語としてすら意味をなさなくなれば目に入ってもスルーしやすいからこれはこれでいいような気がするw >>277
効いてて草
ル・bi、、、ィ
ル、b・ィ >>275
NG出来なくてくやちーねーwwwwww
ruuu！biii最強！！！！wwwwwwwww ル・bぃ/G,o のG,od、Vag_rant, Terr_aform, Pac_ker の作者、
今世_紀最大の起_業家、ハシCorp のMitケル ハシmoto
皆・彼を参考にしてる
ル・ビぃ/G,o のG・od、Vagrant, Terr_aform, Pac_ker の作者、
今_世紀最大の起_業_家、ハシCorp のMitchell ハシmoto
皆_彼_を参_考にしてる もはや出会い系のスパム並みの印象になっちゃってるから、色々逆効果だぞ。 R u b y
G o の 神
Vagrant, Terraform, Packer の作者
★今世紀最大★の★起業家★
HashiCorp のMitchell Hashimoto
皆 、 彼 を 参 考 に し て る キモオタプログラマー君はみんなから虐められてるけど…… 学生の頃、眼鏡かけた気持ち悪いブス虐めて遊んでたけど
大人になるとそういう奴らがネットで暴れるんだな
俺が植え付けたトラウマは大きかったんだな
青葉みたいにはなるなよ…… Ruby君が日本語の文章っぽいものを書いてるのを初めて見た気がする。
中身はともかくとして。 goの文法教えて
if a, b := c.(*d.Foo); b && o.Bar() {
・・・
}
これは2つの変数 a, b に代入ってことであってる？
c.(*d.Foo) この部分がよくわからない
セミコロンは単に2つの式を入れるためだけのもの？ >>294
ざっくり説明すると、これはいわゆる型キャスト
b に型の変換が成功したのか論理値で代える
; 以降が if の判定に使われる論理式
むしろ ; 以前が特殊で、ここで返ってきた変数は {} の中だけで使える
a は Foo へのポインタなので、Foo のメソッドを呼べる C や Java とかでも for (int i=0; i<5; i++) {} と作成した i は{}の中だけで有効
それとノリは同じ
C#のusingやら、そういう特殊な構文はどの言語にもある
無理やりキャストするのではなく、キャストできない場合の判定がある分、他の言語よりもいくらか安全
この系統には map のインデックスアクセスがあり
if value, ok := m[key]; ok {
……
}
キーが無ければ ok には false が返る Vagrant の作者、HashiCorp のMitchell Hashimoto もそうだけど、
皆、Ruby → Go がキャリアパス
メルカリ、カヤック
KENTA、るびきち、mattn
Ruby コミッターが多い、Cookpad、マネーフォワード、Ruby 開発 基地外にレスするつもりはなくて純粋に気になるんだけど、
RubyからGoに乗り換えた奴なんてそんなにいるのか？
俺の知ってるRubyist達はRubyしか知りませんやりませんマイクロサービス何それ食えるのって感じでGoとは遥か遠い連中だわ
GoはJava系かNodeやPythonから来る人が多い印象だな vscodeでステップ実行してる時に値を見ると+xxx moreになるけど全部見たい場合はどうすればいいねん Ruby on Rails で、スノーボードのサイトを作っていた、
Shopify の時価総額は、今や15兆円
Amazon は150兆円だけど、このままじゃ抜かれると、ライバル視してる
米国年収では、ついに、サーバー構築運用資格がRails を抜いた。
AWS ソリューション・アーキテクトが、1,500万円
VWware が、1,400万円
Rails が、1,300万円
Node.js が、900万円
ただし、Nodeの求人数は、Railsの2倍ある
Rubyでも、Shopifyアプリを作ったり、AWS Lambda, CloudFormation とか、色々な仕事があるけど、
速度重視のものは、Go へ行くだけ go1.16にちょっと興味が出た
ファイル埋め込みをサポートしてくれるのか //go:generate って自動でコマンド実行させられるけど、この機能のセキュリティの資料ってどこ？
ビルドはユーザー権限で動かすからサンドボックスとか無し？ セキュリティに対するケアなんか何もないよ
そもそも何のチェックもなくGitHubから直接パッケージを入れる仕様なんだから、
パッケージ作者がその気になればgo:generate云々以前に利用者のビルド成果物のバイナリに対してマルウェアを仕込むことすら造作もない
パッケージを入れるときには作者を全面的に信頼しそういう重大なリスクを受け入れていることを忘れてはいけない なんか会社のPCで WSL+Ubuntu に Go をインストールしたら、こんなエラーになって使えなかった
$ go version
go version go1.13.8 linux/amd64
$ go get -u golang.org/x/text
go: extracting golang.org/x/text v0.3.5
go get: rename /home/hoge/go/pkg/mod/golang.org/x/text@v0.3.5.tmp-022669236 /home/hoge/go/pkg/mod/golang.org/x/text@v0.3.5: permission denied Windows 10 Home でも出来るようになった、
WSL2 で、Docker でも使えば？ go1.16 がまだ出てないから statik 使ってるけど、コマンドラインから
go run github.com/rakyll/statik -f -src=static
叩くと、NISが
カテゴリ: 解決したセキュリティリスク
日時,リスク,活動,状態,推奨される処理,パス - ファイル名
2021/01/20 23:38:45,高,statik.exe (SONAR.SuspScript!g3) が SONAR によって検出されました,\
削除しました,解決しました - 処理の必要はありません,c:\Users\hoge\AppData\Local\Temp\go-build742135550\b001\exe\statik.exe
と容赦なく抹殺に来るんでバッチファイルから作成できない
トホホ
VScode からは実行できるんだけどなぁ
何が違うんだろう あわしろ氏がDockerはオワコン、これからはWSLと言ってる。 goのパッケージで、全然違う役割で同じパッケージ名つけなくなったときみんなどうしてる？ apiwrapper2
apiwrapper3
saigo_no_apiwrapper
apiwrapper_final
こんなかんじで import (
zenzen "xxx.com/omae/package"
chigau "xxx.com/aitsu/package"
) >>324
いや、自分が作ってるアプリ内でパッケージが被りそうな場合ですー >>326
たとえば、
package encrypt
っていう、APIの通信を暗号化するパッケージを自分で作ったとして、あとからユーザーがアップロードした画像を暗号化する処理作りたくなったとき、また
package encrypt
ってつけたくなるけど、最初に作ったAPIを暗号化する処理向けにすでに「encrypt」って使われてるからどうしよーってなるって話ですね
package apiencrypt
package userimageencrypt
にするのが普通ですか？ >>327
いや、同時に使用する場合でも>>324さんの言うようにエイリアスで区別してインポートして使えばいい
例えば標準パッケージのnet/httpに対して、サブリポジトリにもgolang.org/x/net/httpがあったりとか、実験的実装でも同じパッケージ名をつけたりしているし >>328
いや、importするときの話ではなくて、実装する時の話です！
ちょっとあとでサンプルコード用意しますね！！ >>329
だから公式でもやってるから気にするなw すいません、僕のエイリアスの理解が間違ってました。↑でみなさんが言ってることが正しいです。
意味不明な事言って、誠に申し訳ありませんでした😳 このスレでgolangのモヤモヤが一つ解消できました。本当にありがとうございました。 別にgolangだけじゃなく他の言語もほぼ同じ仕様だぞ >>335
別ディレクトリの同一パッケージ名つけちゃうと、同じパッケージという扱いになると勘違いしてました。
ディレクトリが違えば、ちゃんと別パッケージ扱いになるんですね 公開したアプリの機能追加しようとしたらgolintがまたゴネはじめた
調べるともうdeprecatedが可決されてるんだな
Apiと書くとAPIにしなきゃ絶許とかアホな子なんで困る 高速なWebAPIが超楽に作れる
あとは、慣れるとスクリプト代わりに使える 実行環境側で準備がいらないから、ちょっとしたツールとか作って人に配ったり、サーバーで実行したりしやすい linuxとwindowsで動かすツールにjava使ってたんだけど
少しづつGoに移植してる
かなり良い感触
ついにjavaを捨てられる >>345
それがあったか！
あとgithubからcloneしてこなくても go run できるのは意外と便利
でもこないだ statik を run したらノートンが怒って temp に作成された statik のイメージを問答無用で削除
build して実行したら動くから、temp にある exe がローカルディレクトリのファイルに書き込みするとヒューリスティック検知が危険と判断してるんだな、多分 >>347
> あとgithubからcloneしてこなくても go run できるのは意外と便利
これどゆこと？？ >>348
この例だと statik を使うとき、go.mod に github.com/rakyll/statik を追加しとくじゃない
ここで、statik でファイルを固めるために statik コマンドをビルドしなくても
$ go run github.com/rakyll/statik -f -src=static
と打つと実行できるの
でもノートン入れてると危険な動作だと判断されるんで、run じゃなく build して実行ファイル作らないとダメだった >>349
ほーー！これ知らなかった。有益な情報ありがとう！ importで現在のpackage宣言からの相対パスが使えなくなったのはクソ仕様変更だと思う
おのれ Russ Cox 具体的に恨んでることは、あるサイトのコードを使い回して別のサイトのコードを書くとき、import を全部修正しなきゃならん
というかしてる
Linux ならまあ sed で置換すればなんとかなると思うけど、Windows で開発してるし あ、元のサイトの一部のコードは使い回すために go get して import してるから、sed でも面倒だわコレ タダで使わせてもらってるくせに糞とか恨むとか
そういう心根だから日本はソフトウェア技術で海外に負けるんだよ タダで使わせてもらってるじからって大人しくしてるほうが進展しないと思うよｗ
もちろん活発にフィードバックが最善だが 趣味でいじってて、検索に使うAPIを作ろうとしてるんだけど
関数の動的な引数について
ぐぐると出てくるFunctional Option Patternってどれくらい使われてるのかね
structをポインタで渡す（nil判定のため）でいいかなと思い始めてるんだけど >>358
たまに見るけど、エディタのコード補完と相性悪くてどんなオプションがあるのかがクッソ分かりにくい
個人的には大嫌い structをポインタで渡すという一文で、わかってるのかな？という疑念が
FOP はざっくりと、アレンジする対象のオブジェクトを受けて内容を好きに設定する関数を、引数として渡す手法
ここでその関数の引数に対象structのポインタじゃなく実体渡しで受けるようにすると、コピーを書き換えちゃう事になるから設定しても動かない
ポインタで渡す以外の話にはならない もしかしてstructをというのは、FOPではなくオプション用のstructを用意するという話か >>359-360
どもども
サンプル見ても、準備する関数とか増えるから
スコープのためにimportのためにディレクトリのネストもう一個深くしないときついかなとか
色々めんどくさそうだった
>>362
そういうことです
手法として
・そもそも関数を別に切ってしまう（一番簡単だけどメンテがめんどい）
・引数を関数のために定義したstructのポインタにする
・FOP
という3つが挙がってた 18か月毎に、Goのユーザベースは2倍に膨れ上がっているのです。これはつまり、今日行われる変更は、5年前に比べて10倍の人々に影響を与える、という意味になります。 Goが現在備えている依存管理は素晴らしいものですが、おそらくは5年前に実現するべきものでした。
この遅れが難しい問題をより難しくして、結果的に必要以上のストレスをコミュニティに起こしているのです。
同じように、現在開発を進めている大きな言語変更がジェネリクスです。これもコミュニティに大きな影響を与えるでしょう。
もし最初からすべてをやり直すことができて、この機能がいかに重要かを事前に理解しておくことが可能だったならば、おそらく7年前から本格的な開発を始めておきたかった、と思っています。 言語として不足している唯一の大きな機能はジェネリクスです。先程も話したように、現在はこの開発に注力しています。 ・Goは優れた既定言語(default language)で、システムやサーバ、API、デーモン、データベース、Webサイトなどに適しています。Goはパフォーマンスと開発者の生産性を、高いレベルで両立させています。
・Dart + Flutterは、GUIベースアプリケーション(モバイルおよびデスクトップ)に適しています。Flutterは、複数のOSとフォーマットで動作する単一クライアントアプリケーションの記述というアイデアを、高いレベルで実現しました。
・Rustは、詳細なコントロールが必要な場合に適しています。低レベルな処理やカーネルなどです。Rustは精密性に優れていますが、その分、複雑さは大きくなります。このトレードオフが理に適っている場合もあります。そうであれば、Rustが最適です。 Goは1度の週末で学べますし、2週間あればプログラミングに習熟することができます。もっと早い人もいるでしょう。他のいくつかの言語で経験があれば、Goは非常に短期間に習得できます。
Goを導入した企業と会った時に、彼らが一貫して話してくれることのひとつが、Goは習得の容易な言語だ、という点なのです。 あったら便利かも知れないけど、無くても不便を感じてないんだよな
多分、普段に書いてる案件の方向性の違いじゃないかな
ライブラリ書きな人は欲しがるのかも Webアプリだと必要なケースはほぼないかな
複雑なデータ構造を扱う分野とか数値計算なら必要だろうね 複雑なデータ構造というより、多様なクラスじゃないか？
クラスが異なるが構造は同じ、といった場合に処理を使い回すための機能だから
たとえばList<Animals>とか https://github.com/golang/go/issues/43651
spec: add generic programming using type parameters #43651
Labels: Proposal Proposal-Accepted Proposal-FinalCommentPeriod
アクセプトされたぞ あと議論の末リジェクトされたのはエラーのキャッチでは？
https://github.com/golang/go/issues/43777
proposal: Go 2: catch error handler #43777 >>375
おお！承認されたのか
ところで、go2はいつくるの？ https://blog.golang.org/generics-proposal
v1.18β（今年末）にはジェネリクスが入ってる予定だそうだから
そこからしばらくexperimental feature扱いになるとして
だいたいv1.20（再来年頭）かそこらでexperimentalじゃなくなってv2.0にするんじゃないか
まあこれは一番順調に行ったらって予想だけど 実装難しそうだから相当先だろうな
特殊化をコンパイル時にやるのか実行時にやるのかすら決まってないみたいだし Javaのジェネリクス導入時みたいに、総称型コレクションの利用で警告を出すような真似はしないで欲しい なんで Java ではデフォルトで「raw型の使用を無視」にしとかないで、探して無視に指定するまでうるさく警告を出すことにしたんだろう issue の本文で
func xxx() xxx, error
とか
nill
とか、go 使ってないような奴なのは見え見えだし、
妥当じゃないか？ ジェネリック馬鹿を排除できるだけでもgoを採用する意味あるわ。 実務でgoやってみたいけど今は未経験の募集あまりないな ジェネリクス反対派って結局何がしたかったんだろう
訳がわからん
言語の設計者でもないのに Java ではジェネリクス過激派による強制で多いに迷惑したから 正直、意味があるのか俺には理解できない
他の言語は継承による拡張なので共変反変が意味を持つ
でも go は継承による関係じゃなくて、インターフェースを具備しているかどうか
元々がインターフェースさえ合致していれば可換なのだから型パラメータには意味がない
そう思ってしまう
どうしても型パラメータが必要な用例、それを目立つように挙げて貰いたい Goで便利なのはsort関数とかmap関数なんかではないの？
今まで型ごとに書くしかなかったんだし。 まずmapはインターフェースをキーとしても値としても使えるから問題にならない
ソートもsort.Interfaceを具備したコレクションでソートするから、Swapとかのための比較可能な値を返すメソッドをインターフェースで持てば良い
構造体はただの入れ物に過ぎないよね インターフェースで構造体の多態性を確保してるから、それが既に型パラメータ以上の柔軟さを持ってる
なんでインターフェースよりも性質的に劣ってる型パラメータを導入しなきゃなんないの？
頭のいい人が、それでも導入が必要だと判断したのだから、そこには理由があるはず
でも頭が悪いから、俺ではissueで見つけられなかった >>394
インターフェイスを使ってしまうと毎回型チェックしないといかんし、コンパイル時に縛りもかけられんでしょ。
テストで網羅するといっても、ユーザに使ってもらうライブラリなんかではそうもいかん。
静的解析でもうまくいかんこともあるし、柔軟性を持ちたいのではなくて、コンパイル言語として担保したいんじゃないか？
俺は今まで型ごとに関数作ってたけど、インターフェイスでなんとかしてたって事？それも極端だな。 >>396
というかインターフェースを型パラメータみたいな物として使っていて問題なかったと言ってるんだよ
機構として使い回すために、その機構に使いたかったらインターフェースを実装する
ソートの機構が使いたかったらsort.Interfaceを実装するでしょ >>396
そもそも何で型チェック？
メソッドの挙動やらが違うのに同じインターフェースを使ってるのか？
Javaとかの型パラメータでも、まさか中でキャストして使ってるのか？
偶然にインターフェースを実装してしまったケースなんて想定しても仕方ないと思う
それは設計ミスだから
区別用にダミーのメソッド生やしとけば？ goは組み込みで要素が型付けされた動的配列と連想配列を持ってるから、他のコレクションはあまり必要ないんだよね
それらでカバーできないようなケースってそもそも大抵は特殊な状況なんで、汎用的なコレクションではなくアプリの要請に合わせて独自に作るのが自然 んな意味不明なジェネリクスより
>>251 のバグを直して欲しいんだよな >>397
ジェネリクスはロジックを使い回すのためだけにあるわけではないと思うよ。
Sortableなんてinterfaceを実装した配列を引数に受ける関数の戻り値の型は何になる？
Sortableの配列が帰ってきても無意味でしょ。
>>398
中でキャストするとかは意味不明じゃないか。
ジェネリクスがない頃のObjectの配列を受けざるをえないメソッドはまた違っただろうけど。
ダミーのメソッドとか完全に意味不明。 >>401
Sortableの配列を返すので正しい
文意からソート結果だろ？
君が型チェックしなきゃならんとか意味不明な事を言い出すからエスパーしたんだよさせるなよ
インターフェースならメソッドを呼ぶだけだから型チェックなんて話は出てこない
型チェックするってことは実体に変換しなきゃならんという話だろ
そうでない場合に考えられるケースとして、偶然に同じインターフェースを実装してしまった構造体を、偶然に渡してしまうコーディングミスを考えているとエスパーしてあげた
そんな阿呆な設計をしてるなら、引数としてるインターフェースにダミーのメソッドを生やしとけば、別のインターフェースになるから誤って渡すミスは無くなる
エスパーさせるなよ >>402
ソート可能なインターフェイスを受けてソート可能なインターフェイスが帰ってきても何も得しない。
[T Sortable]な関数の返り値は[]Tで十分でしょ。
結果がもう一度ソート可能かなんか必要な情報でない。
intがSortableだとして、返り値が[]Sortableだと、結果は型チェックしないとだよね。
[]intが直接帰ってきた方が効率的だし、無駄なコードではないよね。
やってることも自明。
mapとかflattenなんかなんかはジェネリクス使えないと使い物にならんと思うが。
エスパーするならジェネリクスの使いみちをエスパーしなよ。 単一の引数だけなら>>395のようにインターフェースで代用できるけど
複数の引数や戻り値の型を合わせたいという場合は型引数が使いたいよね。 >>398
キャストしないといけないの理解できてないあたり、型パラメータとインターフェースでの実装の違い理解してなさそう >>404
複数の別のインターフェースを引数に持たせれば問題ないでしょ
それぞれが型パラメータとして機能するんだから
戻り値も同じ………いや、戻り値に関しては一概には言えないのか
でも実体ポインタを返すメソッドは>>251のバグに引っ掛かるんで使いたくない
→ 戻り値の実体ポインタはインターフェースを備えてるならば、本来は反変でアップキャストされてインターフェースを返しているとも判断されるべき
このバグで多態が機能しなくなるから使いたくない
具体的にはシグネチャが違うため、変種をコレクションに混在して格納できない
ジェネリクスを導入して個別に実体ポインタを返せるようにした時に同じ現象になるはず
このメソッドを持つジェネリクスな構造体は、それぞれ可換でないので多態が適用できない
コレクションに混在させられない
インターフェースを返す設計ならば、それらは実体は異なっても多態が機能してコレクションに混在格納できる
よって、インターフェースを返す方が設計として抽象度に優れている
以上の論旨から、ジェネリクスはインターフェースの下位互換だとしか見えない >>406
違くて、2つの引数があるときにその型が同じであってほしい場合とかね。 >>407
その場合には同じインターフェースの二つの引数を持つことによって問題がある事例について具体的に指摘してくれ
型が同じことは保証されてるぞ >>406
インターフェイスはインターフェイスで使えば良くて、ジェネリクスで効率的にできたり型を自明にできる部分はジェネリクスを使えばよいでしょ。
今でもコードジェネレータなんかで作ってる部分もあるだろうし。
どちらかがあれば原理的にどちらかが不要なのと、
どちらかがあれば片方は作ってはいけないのは別。
Sortとか、mapの[T,U]のKeyのみ、Valueのみを([]T,[]U)と、配列として返す関数なんか書こうと思ったらジェネリクスが無いと型チェックの嵐でしょ。
確かにキャストではないけど、型チェックもノーコストではないよ。
ジェネリクスのある言語使った事無いんじゃないの？
>>403のケースなんかはどうするん？型チェックすんの？ >>408
map[T]Uを受けて、[]Tと[]Uを返す関数。 とか顔真っ赤にして主張してきたけど、具体的にちょっと面倒な事例に自分で気づいてしまった
new() が厄介だな
new の代わりにインスタンスを生成する factory 一時クラスを外から渡してやれば解決するんだけど面倒ではある >>408
結局は返り値の話に帰着するのかもしれないけど (T, T) -> T な関数が欲しいとかね。 返り値に関係なかったら、Tとそれに対するfunc(x T)を受ける関数とかかなぁ。 >>410
納得した
メソッド引数のシグネチャが異なるものを一本化して書けるわけか
確かにインターフェースじゃmap[T]Uを引数とした共通メソッドは書けない
T,Uがインターフェースだとしても、それぞれのインターフェースの組ごとにメソッドが必要になるから >>414
伝わってよかった。逆もしかり。
[]Tと[]Uを渡してmap[T]Uを返してくれる関数も。
Pythonでいうとzip関数的な。 >>415
JavaだとProxyを使って何でも解決するという黒魔術的解決手段があるのが恐ろしい
デバッグ用だよねとか思ってると struts とかwebフレームワークのソース読んだ時に、インタセプターとかで普通に使われていて更にビビる >>416
Springの十八番だな。
ただ、ああいう方法だと結局、ランタイムで死ぬかどうかをテストで担保するしかないって方向性に行きがち。
あとパフォーマンスももちろん遅い。
今回のジェネリクスがどう実装されるかが一番気になるけど、俺的には素直に関数たくさん作って欲しい。 >>400
どう考えてもバグじゃないと思う。Goのinterfaceとstructの関係はembedしなければほぼ静的方チェックありの
ダックタイピングだから「そのメソッド実装がインタフェースAを実装している」と思い込んでるのは自分であって
実際にはJavaのようなimplementではないです。もっと言うなら、ルックアップが行われるのは、実行時であり
コンパイルは厳密な型チェックが行われます >>419
んじゃ、言語拡張要望と言い直そう
メソッドの戻り値がインターフェースでの戻り値の型に反変できるなら、インターフェースを具備していると判定して欲しい、と ポインタじゃなくてインターフェースを返すのが正しいのでは？
何故ポインタを返す
インターフェースのポインタにはなんの意味もない >>421
いや、インターフェースのポインタじゃなくて、構造体ポインタ
構造体ポインタ*SubがインターフェースISubを具備しているのは代入させて確認
んでISubを返すメソッドを持つ別のインターフェースを具備させようとした時に、戻り値としてISubではなく、ISubに代入可能な*Subを返させると、シグネチャ不一致でエラー
ISub を期待しているのに *Sub を返していると
インターフェースを具備しているかの判定でも、反変を考慮してくれないだろうか、という要望
そうすればインターフェース対応でキャストして返すメソッドと構造体固有のメソッドの二本を作らなくて済むから
作れよ、と言われちゃうか >>421
シグネチャが合わないコンパイルエラーの時だけ、戻り値の型が互換(反変可能)かで追加チェックさせればいいから、パフォーマンスが極端に悪くなることはないはず
という見立て >>421
インタフェースを返すのが理論的にも実装にも正しいけど、インターフェースのポインタは埋め込みを
するときにコンパイラが使う。あんまりこれをやるモジュールは（メモリサイズが大きくなるから？）
標準ライブラリ以外見ないけど。
>>423
「 ISub を期待」というのは分からなくも無いけど、実行時じゃなければ分からないチェックを
コンパイルの速度と、言語の厳格性を犠牲にして、（かなり）保守的な言語がやると思えないですね 今回の目玉は embed で、あとは modules がデフォルト利用になったくらいか
96% って、どこから来た数字なんだろ？ え、これすごくない？
ファイル内容のバイナリを変数に設定できるのか
クソ便利そう embed例を交えながら詳しく懇切丁寧に説明してくれ >>431
WebUIを持ったアプリの画像なんかのアセットをバイナリ一つで配布したいとか。 外部ライブラリで出来てたから、そんなにインパクトはない。むしろNotifyContextの方が意味ありそう
こういう事は他言語だと非常にやりづらい NotifyContext例を交えながら詳しく懇切丁寧に説明してくれ android アプリを調べようと、go android 常駐アプリ で検索したんだけど、go の記事が探しづらい
以前からポケモンが引っ掛かっていた上に、次のandroid11はGoエディションなのか？ 1.16 だと、Deprecation of io/ioutil は面倒に感じるなぁ
一杯使っちゃっていて 検索ワードはgolangって言うのはこのスレの常識 そういやgolang.jpってもう活動していないのか
日本のgoコミュニティの総本山たるべきドメイン名を無駄にしやがって 名前よりもマスコットがキモすぎるのが気になってしかたがない 俺みたいにゴーファ君を結構可愛いとか思う人間がいるから厄介 c#はマスコットいないんだぞ
クラウディアとか藍澤光とかいたけどな マスコット…冴子先生がCortanaとして復職してくれたなら、Cortanaボタンを非表示にしないのに… LISPにマスコットなんてあったのか・・とおもってググってみたら
たしかにこれはエグい
キモすぎ なんか gui ライブラリで調べるといろいろ出てきてよくわからん
マルチプラットフォームな gui って何がええんや？
Qt は golang で使ってる人おるんかえ？ >>454
ありがとう、そうなんか
主にバックエンドで使われてる感じなんかな
https://i.imgur.com/pGBnPCA.png
ふむう ローカルHTTPD建てて、ブラウザからAPIで操作するアプリは提供してる >>455
ウチはElectronでGUI作ってバックグラウンドにGo使うてる >>457
面白そうだね
オレオレGUIツールだと.netが楽すぎるのでそっちで書いちゃうけどGOで書くのも楽しそうだ GUIは俺は普通にブラウザ起こしてるな。
IE使われると辛いけど。 for (大分類) {
for (中分類) {
for (小分類) {
wg := sync.WaitGroup{}
cpus := runtime.NumCPU()
errCh := make(chan error, cpus)
defer close(errCh)
for (アイテム) {
wg.Add(1)
go func() {
defer wg.Done()
errCh <- 他の関数()
}()
}
err := <-errCh
if err != nil {
return だめです
}
wg.Wait()
}
}
}
こんなコードでwaitしっぱなしになるんだけど
なぜなんでしょうか(´・ω・｀)
途中の即時関数にwgのポインタ（&wg）渡すのもやってみたけど、
結果変わらなかった >>461
・errCh <- 他の関数() はバッファが一杯の場合ブロックする
・err := <-errCh はブロックする
goのchannelは初心者が使うと極めてデッドロックを引き起こしやすいので、まずはchannel使わずに正しく動作するものを作れるようになってから手を出すことを強くお勧めする >>462
ありがとうございます
全体としては物はもうできていて、上記の処理は大量にファイルを出力するため重く
速度改善としてgoroutineを入れようと試みてました。
まあファイルシステムのi/oがボトルネックだとそんなに変わらないかもしれませんが… エラー判定をgoroutineと同じ階層で判定することで返ってくるようになりました
一応オチとしてめも
速度改善はならず >>461
ぱっと見しただけで検討しないで書くけど
errCh の受付数はcpuの数
errChの読み込みが一回しかしてないからアイテム数が受付数を越えたら書き込みがブロックされてwgがDoneされない
DoneされないからWaitは抜けてこない
のでデッドロックということでは？ >>465
ご指摘のとおりでした
なのでgoroutineと同じループの中でerrChを取るようにしたら動作しました
wg作る位置も動かないからだんだんスコープ狭めていったんですが
一番外のforの外で作って動きました Goのグラフィックって、標準だとこんなに低レベル処理なパッケージしかないのか……
JavaScriptで言うならImageDataしかない感じ
誰かのライブラリ使わないと線を引くだけでも大変 ∧,,,∧
（・ω・｀ ） スマンカッタ・・・
/ y/ ヽ
━(m)二フ⊂[_ノ
（ノノノ l l l ）
￣￣￣￣￣￣￣￣￣ 標準ライブラリなんて小さい方がええやん。HTML5のCanvas APIみたいのならgithubに腐る程ある
github.com/fogleman/gg まあ、イケイケGoGoジャーンプ！って言葉もあるくらいやし… 16がでてしばらくたつけど、何か問題があった人いる？
無かったら入れようとか姑息 当初から分かってたがPlan9同様、実用言語ではなく
他の言語のリファレンスとしての研究用言語になったな もともとグーグルの社内言語だったと聞くが
本家では今も活用されているのかね モンストの通知サービスの一部でも、他の言語とのトライアルの結果で採用したとのインタビュー記事が、つい先日あったし(日経XTECH) 学習が簡単というのがデカかったらしい
分かってるな CodeZine（コードジン）: 2020年のGo言語利用状況が明らかに、9648名の開発者が回答.
https://codezine.jp/article/detail/13819
正直、手前味噌過ぎて萎える
無作為アンケートならともかくなぁ echoでAPIのパラメータの初期値を設定する方法って
ぐぐると構造体作ってコンストラクタで設定しよう！とか出てくるんだけど
なんかすごく面倒な上記述場所が離れててわかりにくい気がしてならないんだけど
例えばこんなのは悪手？
まあ悪手なんだろうけど
func getParam(p string, defaultValue interface{}) interface{} {
switch defaultValue .(type) {
case string:
if p == "" {
return defaultValue
} else {
return p
}
case int:
ret, err := strconv.Atoi(p)
if err != nil {
return defaultValue
}
return ret
}
return nil
}
pageNo := getParam(c.Get("pageNo"), 1).(int)
一般的な方法ってあるのかね ひさしぶりに書く機会があったが
やっぱクソだなこの言語 肝心のグーグルに普及させる気がないように思う
メンテナンスが別組織に移ったにしてもさ ファンクション実行環境が使い放題のところでは有用かもしれないけど、それ以外だとあまりいいことがない ジェネリクス入ればまた話題になるさ
それ以外では大きな機能追加はなさそうだし
話すことはゼロ Ubuntuに最新のfzfを入れるために成り行きでgoも入れてビルドに使ってるんだけど、使い勝手どう？ 全体的な満足度は高く、回答者の92％がGoを使用して満足しています 公式の正規表現パッケージだと機能が足りないんで高機能版を探してるんだけど
例えばgolang pcreで検索すると玉石混交っぽいのがたくさんヒットします。定番はどれですか？ Golint is deprecated and frozen.
https://github.com/golang/lint golintなんて使うな！ってのはかなり前から言われてなかったか？
そうか、とうとうというかやっと非推奨になったか Golintよりあの独特のキモさのあるマスコットを frozen してくれ そういや、今は golangci-lint で gosample, unused, deadcode を disable して使ってるけど、皆は何を使ってる？ ごふぁー君、日本人が日本の感覚でリファインしたらどうなるだろうな
可愛くなるかな land of lisp知らん人って居るの？居るか、昔の本やもんね… lisp興味あったから買ったけど、興味なかったら買わないだろうし知らない人多そう。
あの本のコミック感好き lispみたいな妙ちくりんな言語好きなやつらって
かっこつけるのが好きなだけなやつのイメージ 歴史的な意義は大きいよ
lispマシンみたいな非効率な物作るのも今では考えられんし
調べる分には面白い じゃ、gopherはキャワイイ、lisp alienはカッコいいって結論でいいよね？ 月末日の今日timeのAddDateのキチンとした仕様理解したわ… A Tour of Goでわざと誤ったコード書いてRunするとエラーとか何も表示されないんだけどこれって俺環？
一応FirefoxとChromeで試した エラー行と、Go build failed が出てます
play ground のサーバが落ちてたとか？ GoにGenerics入るの喜ばれてるのを見るにD言語で良かったのではってなる・・・ GoLandっていうIDEすこ
これ使ったら他のIDEには移れねえわ 基本的にVSCode信者だけどVSCodeのGo拡張は糞すぎるんだよなあ
まあどうせ他の言語も日常的に使うからGoのためだけに移行するのはありえないんだが、さすがに糞すぎる VScodeがGo/HTML/JavaScript/Markdownと幅広いから、それだけで間に合っちゃうんだよな… 機能とかはともかく、ステータスバーをやたら占有するのは糞だな。 VagrantのRubyコードをGoでリライトする模様 ほう。Vagrantfileはどうするのかな。今だとYAMLとかになりそうな悪寒。 Vagrantとかまだ使ってる奴いるの？
Dockerでオワコンとか以前に、GoだとVMもコンテナもなしに生でも普通に動くようにポータブルに作るだろうし 普通に、WindowsでVirtualBox使うならその環境構築にほぼセットだわ。
Goのアプリしか使わないわけでもないしな。 あらー
まあユーザーからしたらRuby入れるの面倒だったしな >>533
WSLで用が足りるならVirtualBox自体使う必要がないんだろうがな。
ただ、単にLinuxのソフトウェアが動けばいいんじゃなくてやっぱり仮想環境が必要な場面はあるし。
以前Ubuntuの複数バージョンを使い分けたりしたことがあるが、こういう用途にはまだ必要。 goのcoroutineはgoroutineていうのに
goのcontextはgontextていわないのはなぜ？ goroutineはGo言語のルーチンじゃなくて予約語goで作られるroutineだからじゃね？ そもそも goroutine は coroutine じゃなくて thread だから。 Goもようわからん方向に進んでますな
インフラ用言語と割り切ればええんかな 今は、WSL2, Docker, VSCode(Remote Container, WSL2 ならRemote WSL)で十分。
Mac, vagarant, virtual box さえ不要
Ruby on Rails では、Heroku, Cloud 9, CircleCI などのクラウド開発
ローカル開発なら、Dockerを使うのが簡単だが、
日本人が作った、バージョンマネージャーのanyenv で、rbenv, nodenv も使える。
asdf でも、多言語の好みのバージョンを入れられる
echo -e "$RBENV_ROOT\n$NODENV_ROOT"
/home/ユーザー名/.anyenv/envs/rbenv
/home/ユーザー名/.anyenv/envs/nodenv
任意のLinuxディストリビューションをWSL2で動かす Clear Linux OSを動かすまで、2021/4
https://impsbl.hatena＠blog.jp/entry/ClearLinuxOnWSL2
注意。アク禁にならないように、URL 内に、＠を入れました
Docker Hub からpull したイメージを、tar へexport して、
それをWSLで、D ドライブへimport する
docker export
wsl --import
WSLでカスタマイズしたものを、さらにexport しておく。
wsl --export >>541
goroutineって
オプションで複数のCPUコアに分散も出来るけど
実際はほぼ軽量スレッドじゃん？
コルーチンみたいなものじゃないの？
プログラムの書き方がスレッド使ったプログラムっぽかったら、
Goみたいに実装が極力OSスレッドに頼らないものになっててもスレッド（グリーンスレッド）？ goroutineはstackful coroutine Rustのメモリ安全性はボローチェッカーによって担保されている
Nimバージョン：1.5.1でRustのボローチェッカーに似た「View types」が実装されれば、
GC無しでView types参照の有効性を検証することによってメモリ安全性を保証しつつ
限りなく抑え込まれたタイプ量で高速化したCのソースコードを吐き出せます
Nimソースコード ==nimコンパイラ==> Cソースコード ==Cコンパイラ==> バイナリ
なので、nimコンパイラが通った時点でメモリ安全性が担保されませんか？
Nimの実験的特徴
著者： アンドレアス・ルンプ
バージョン： 1.5.1
http://nim-lang.github.io/Nim/manual_experimental.html
Nimは限りなく抑え込まれたタイプ量で高い生産性とPythonのような高い可読性を実現し
ているにもかかわらず、Cのソースコードを吐き出せるので割り振られた仕事が早く終わっ
ても終わってないふりをして怠けることができる
「怠け者とはこうあるべきだ！」と言うとても大事な事を Nim は我々に教えてくれます Rustのメモリ安全性はボローチェッカーによって担保されているが、
Nimと比較してRustはタイプ量が多い事により限りなく低い生産性と
C++のような高い難読性、超巨大なバイナリ生成性能を兼ね備えています
Nimはバージョン1.5.1でRustのボローチェッカーに似た「View types」が実装されれば、
GC無しのView typesで参照の有効性を検証することによってメモリ安全性を保証しつつ
限りなく抑え込まれたタイプ量で高速化したCのソースコードを吐き出せます
Nimソースコード ==nimコンパイラ==> Cソースコード ==Cコンパイラ==> バイナリ
なので、nimコンパイラが通った時点でメモリ安全性が担保されませんか？
Nimの実験的特徴 バージョン1.5.1
http://nim-lang.github.io/Nim/manual_experimental.html
第二プログラミング言語として Rust はオススメしません Nim をやるのです
https://wolfbash.hateblo.jp/entry/2017/07/30/193412
Nimは限りなく抑え込まれたタイプ量で高い生産性とPythonのような高い可読性を実現し
ているにもかかわらず、高速なCのソースコードを吐き出せるのでC言語でリモートワーク
されている方は割り振られた仕事が早く終わっても終わってないふりをして怠けることができる
「怠け者とはこうあるべきだ！」と言うとても大事な事を Nim は我々に教えてくれます >>545
ttp://rosettacode.org/wiki/Category:Go まー、概ね間違ってもいないかな？
でもmapなどがループより優れてるっーのは感想にしか過ぎなくないか？ 優れているかどうかはともかくmapとかは便利だよ
Genericsが導入されたらめっちゃ使われるようになるっしょ 総称によるイテレーションを伴うmap/reduceは他の言語みたいに単一スレッドの自己満足じゃなく
デフォルトで並列にして欲しいです。。。 map/reduceが使われる殆どのケースでは、入力の振り分けや結果のマージ、コンテキストスイッチ等のコストのため、並列化するとかえって遅くなるんだよ うっせーうっせーうっせーわ、あなた思うよりmap/reduceに並列度引数付ければいいだけです！
デフォルトで言うてる文章も読めないアホはgolangのM:Nモデルの高速スイッチが分かってない だから「殆どのケースでは」って言ってるじゃん
デフォルトで並列なら確実に遅くなるよ その記事は肝心のポイントが一つ抜けておるな
goは何がクソといってまず名前がクソすぎる
40年50年前にできた言語じゃないんだからちゃんと後先考えて名前つけろや！ 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
もっと強烈なのあったはずなんだけど見つかりませんでした でも悪評も評判のうちなんで
WebAPIとして最適な並列処理性能を持つとはいえ、なんでそんなに注目されるのか
極論言えばWebAPI作るくらいしか能はないよね GoにGenericsが導入されるのは来年か、待ち遠しいなあ ググラビリティなら同じ名前のゲームがあるRustより遥かにマシ >>566
c って名前をつけた奴に無理な注文すんなｗ たまには D とか V のことも思い出してあげてください >>573
Szl (Sawzall) っていう命名もできるのになあ >>567
> Why Golang Is Bad for Smart Programmers
> https://raevskymichail.medium.com/why-golang-bad-for-smart-programmers-4535fce4210c
読んだ
Cしかやったことない奴は騙せても
いろんな言語やってきた奴からしたらショボすぎるわな
あとどうでもいいけどDを引き合いに出してGo批判するって斬新だなｗ D言語ちょっと試したことあるけどなかなか心地良かったよ。
しかしなぜGoやRustが使われて、Dが使われないのか、というな視点でも評価してほしいな。
「俺が考えた最強の言語」を作る人はいっぱいいても、ちゃんとコミュニティを作って使われるようになる言語はなかなかないね。 >>577
> 「俺が考えた最強の言語」を作る人はいっぱいいても、ちゃんとコミュニティを作って使われるようになる言語はなかなかないね。
Perl6もフィボナッチ数列から最初の十個を出力を
say (1, 1, *+* ...*)[^10];
と簡潔に書けたりして最強言語だけど使われてないね write only language として最強でもなぁ・・・ >>578
そういやこの前「Perl6 は～」って話してたら「rakulang だ！」って怒られたわ Goは、①普通にビルドできて、②普通にデプロイできて、③後々ゴミにならない
という当たり前の事が当たり前にできることに存在意義がある
簡単なことだけどそれができない言語が多いんだよね 2021年にもなってジェネリクスを待ち望んでる言語があるとか
痛々しすぎん？ いらん
と開発元も思ってたけど、おまえらがどうしても欲しいと言い続けたからだろ 言語をデザインした奴が最初の段階で要らんと言ってるなら
それを貫き通してほしいよね
馬鹿にいまさら迎合することなく
Javaにジェネリクスが入った時も同様の失望を覚えた 俺はジェネリクスが欲しいと思ったことはないなあ
sliceとmapに型があるから実際ほとんど十分なんだよね システムプログラミングではいらんかもしれんけど業務アプリではないとつらい 言語デザイン的には業務アプリは考えてなかったけど、業務アプリでも使いたいという要望が広まってきて、その弊害というかなんというか
業務アプリにgoroutineはオーバースペックだし、JavaとかC#でいいと思うんだよな Goって、より良いCとして使うだけの利用者層は今はどれくらいのシェアなんだろ？ Generics が入る時点で Go1 と Go2 に枝分かれするかと思ったけど
そうでもないみたいだな Genericsがないから、いまは代わりにコード生成でなんとかしてるんでしょ
コード生成ってメンテしづらいし面倒だよ 型クラスがないジェネリクスとか片手落ちなんだよな
それに標準の型クラスもないのにどうやって共通性を持たせるんだろうとか
いろいろ無理な気がする
使いにくいから誰も使わないということになりそう >>589
Linux関連プロジェクトみたいに、既存関連リソースがC言語ばかりだとC使うんだろうけど、
しがらみのない新しいツールではCなんて滅多にないような？ ほとんどGoかRustなのでは・・・？
シェアは全くわからんけど、おれの趣味寄りにもなるけど有名なのだと
Docker、Kubernetes関連、moby、HashiCorpのプロダクト、etcd、CockroachDB、InfluxDB、BoltDB、fzf、Hugo、frp、traefik
もしかしてこういう話じゃない？ >>595
WIP ブランチなら既にデフォルトで -gcflags=-G=3 になってる
gopls も対応したので Emacs + Eglot でサクサク書いてる TVCM見てて Go Pay が出てきて吹いたわ
なんなの提供元
ポケモンGoに勝てるの？
GO TO トラベルに勝てるの？
Google Pay に勝てるの？
それも調べたら MOV Pay から名称変更とか、そこまで逆境が欲しいの？
山中幸盛なの？ 書かなくても分かると思ったけど一応、サービス内容に対しての話じゃないからね
ググラビリティの話
Go が後続のサービスにどれだけ苦しめられてるのか
任天堂やら日本国政府やらGoogleやらのパワープレイヤーなら知ったこっちゃないだろうけど、泡沫勢力じゃ約束されし絶望じゃん ググラビリティって普通GolangかGo言語で検索すんじゃねーの？
Cとかでどうやってんの？ >>603
>>600
書かなくても……書いといて良かったわ 検索ワードで回避できる問題なんかどうでもいい
一般人が検索するような物でも無いし
コマンドが短く入力しやすい方が重要
squirrelみたいな名前にしたら腱鞘炎になるぞ 極主夫道の二巻の福引きGo等の商品がどうみてもGopher君のパチモノ Go簡単って言うからやってみたらローカルファイルimportするのに相対パス使えないとか
go mod するんだとかGOPATHはもう使わないとかｺﾞﾁｬｺﾞﾁｬｺﾞﾁｬｺﾞﾁｬ・・なんじゃこれ？全然シンプルじゃない
ツール周りがゴチャりすぎやろ、やっぱPythonが神だわ そうですね。Python使った方が良いと思いますよ。さようなら まあ相対パス使えないのはやり過ぎな気もする
htmlですらbaseを指定できるのに、何を恐れているのか
パーサーを作る際に楽だからなのかな？ え？ go.mod で replace しておけばいいんじゃない？ Sum Type、Union elementあと4か月か…2月/8月 既に WIP ブランチでは使える様になっているから 1.18 で
正式採用になると思う(gopls も対応済み) ついにGenerics載るんだね、楽しみやなー。
ところで、ユーザ定義演算子は計画されてない？
AddとかMulみたいなメソッドじゃなくて+とか*みたいな演算子使いたいこともあるんよね >>616
>>594みたいな書き方しか無理みたい
トホホ なんも知らん新人でも、できるベテラン・新人でも、仕事に使うにはソースコードに均一性のある良い言語だわいな 最近Goの現場入ったけど
dep?とかいうモジュール使っててGOPATHにも気を使わないと駄目で
結構混乱する
初期で大分失敗してると思うわGo depは3年ぐらい前から正式な公式ツールじゃもう無いし、ツールの煩雑性や使い勝手は言語に関係ないよ
PATH変数に気を使うのはC,C++でも一緒、そもそも環境構築すら出来ない失敗をしてんのはあんたか
現場の手順書が無いか 「改訂2版 みんなのGo言語」という本を読めば？
学生時代に、Ruby 製のVagrant を作って、
Terraform で有名なHashiCorp を作った、今世紀最大の起業家、
Ruby/Go の神、Mitchell Hashimoto のソースコードも解説している go.mod に書いとくだけで github やらから直接にライブラリを導入できる点で、環境面では目一杯助かってるわ
Mavenやらpipが組み込まれてる感じだけど、基本機能であることは大きい
Mavenとかpipは別途入れないとならんし、それぞれ本体と別の環境整備しないとならないから 面白い
GCP無料枠でそこそこ実用性のあるサイト建てたりできるし だってアマとか無料枠ないんだもん
一年目だけってのは、単に初回サービスって言うんだよ 社会人なら別にEC2使ってもマイナーサービスのサーバ台ぐらい余裕やで。
一ヶ月分の料金なんて、スタバ2回分くらいだろ。
そら安いほうがいいけど。 micro使えば安いけど明らかにメモリが足りないんだよな
おまけに調子に乗ってぶん回すと詰まるし
最低でもmedium程度は欲しいがそうなると結構高くなる Oracle Cloudは？
コンソールが重くて独自性強いけど起動してしまえばいっしょ サイト立ててもアクセスが日に数件なんでほとんどマシン回ってないやww microといえば思い出す、大手のNでスワップしまくりなんも考えてないSEが手配したmicro
しかもWindowsの時の絶望感・・・ microでも小さいサービスならメモリ足りるやろ？ goだったら100MBメモリ食うこともありえないくらいやろ
メモリリークでもしてるんじゃないの？
Windowsとか動かしたらそらきついだろうけど。 動くか、と言ったのはWindowsの話
400MB確保できるみたいだから意外と使えるかも？ なんでそんなにWindowsを動かしたいんだ・・・。 >>640
pインスタンスでwindowsを動かすのは普通に多いよ いや、なんで？という疑問への答えじゃないよな
ぶっちゃけLinuxでSSH接続専用にすれば済むから GUI系のアプリを動かすんだよ
CAD系のシミュレータとか
windowsにしか存在してないアプリが多い github.com/fogleman/gg が遅くてちょっと困った。
Webassemblyで普通にcanvasの関数をcallした方が速いなんて。
ebitenはdraw系の関数少ないからなぁ。 Twelve Years of Go
Russ Cox, for the Go team
10 November 2021 >>646
普通は使わないが何故か仕様にあるんだから許可されてるんだろ ラベル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とも呼ばれる。 Inline指定出来ないので関数呼び出しのコスト低減くらいしか用途が思いつかない
そこまでシビアな実装滅多に無いから基本的に使わない 確かに関数化すりゃブロック脱出もシンプルにreturnさせりゃいい
となるとgotoは関数呼び出しによるオーバーヘッドの削減だけなのかな？
ナノ秒単位でも削減したいという余程のシビアな要件で使うって話になるけど、関数呼び出しごとにスタックのチェックが入るGoでそんな要件に意味ってあるの？とも思う というよりもアホ意識高いgoto異端審問官が、文句つけてくるので使わない。 おれにとっては、Golangでgoto使うのは、構文解析器みたいなのを書くときにたまにあるんだけど、共通の処理までジャンプしたいときとか、
for文とかをネストしたときに、いくつか上のブロックまでジャンプしたいときかなあ。これも構文解析したあとの評価器で使うこともある気がする
ようするに最適化とかじゃなくて、ちょっとした大域脱出みたいなノリで使ってる
Go本体のソースコードでもこんな感じgoto使ってるんじゃなかったっけ バージョン管理からテストまで環境内で完結してるのに仲間外れなのか emacsは"環境"だから、
emacs > IDE
だよな
ところでIDEの定義って何よ？
高機能エディタと垣根がなくなってきたからそれらを区別する意味があるのかどうか 統合開発環境だから、コンパイルからデバッグ、バージョン管理にデプロイまで揃ってるemacsとかVScodeを入れないとなると、いよいようろんな定義になる
RADとかグラフィカルな開発環境とごっちゃになってるのでは？ エディタ内でデバッガと密接に連携(ブレークポイント設置して値を参照とか)できれば統合してると言ってもいいと思うんだが mapをrangeステートメントで処理すると毎回順番変わるのな
将来mapの実装を変えた時に要素の順番が変わっても大丈夫なようにあえてランダムにしてるらしい
最初知らなくて嵌った
しかもランダムに返す仕様の方がパフォーマンスをよくしやすいらしい
ensure better balancingって
なるべく偏らないように要素を配置するみたいな意味か
https://stackoverflow.com/questions/55925822/why-are-iterations-over-maps-random/55925880#55925880 > ランダムに返す仕様の方がパフォーマンスをよくしやすい
いや流石にそんなことはないぞ
処理系の実装変更だけでなくマシン毎に結果が違うことも許容することで、パフォーマンス最適化の余地が広がるという意味だ go と defer とチャネルが便利すぎるね
チャネルのキャパシティは未だに悩む チャネルはクソだろ
Cでいうポインタ関連のミスによる死と同程度くらいにはデッドロックを起こしやすい極めて危険な仕組み 勉強中でよくわかってないんだけど
メインルーチンが死んだらゴルーチンもチャンネルも死ぬんじゃないの？ デッドロックは一番の可能性としてキャパシティを疑う どんな言語でもスレッドやルーチェンの１つが落ちて無事平穏な言語は少ない。Erlangぐらいかな落ちる前提なのは もう新しいデータ来ないのに
私待つわ…いつまでも待つわ…と待ち続けるコードを書けば
当然ながら詰まる 未使用の変数がコンパイルエラーになるのは地味に良い 俺もチャネルはどうかと思う
ある意味スレッドより危険 設計間違えたらデッドロックするのはどんな通信でも一緒じゃね？
チャネルを殊更に危険視するの？ >>676
デッドロックしやすい仕様なのは事実だし、危険だからといってその使用を回避できる標準的な代替手段が存在しない
他の言語ではだいたいpromise/future、fork-join、actorがあるからよほど変なことしなきゃデッドロックなんか滅多に起きないよ そうなんだ？ イケてないの？
Googleさんはなんでそんな方式を採用してしまったのやら >>678
デザインパターンみたいなものを極力廃して、小さな標準的なツールセットだけでモノ作れるようにするという思想は一貫している
しかしスレッド関連のデザインパターンというのは基本的に死なないためにあえて制約を設けているのであって、
Goの思想が逆に敷居を高くする方向に作用してしまったということだ CSPモデルに沿った実装がしやすいとは聞く。
CSPモデルができていればそれがデッドロックを起こすかどうか静的に検証できるはず。 ほえー、そうなんだ
実際のところ、他の人がgoroutineとか使ったやつを -race 付きで実行すると警告出まくるやつばっかだったよ
Goの強みは並行処理だと思ってたのに、他の言語のことはよく知らんけどもそんな有様じゃ強みだなんて言えないなあ なんかID変わっちゃってたけど、おれは >>678 ね
>>679 に向けて返信した CSPモデル
ttp://www.usingcsp.com/cspbook.pdf すまん、せっかくCSPを紹介してくれるなら、もっと初心者向けのやつない？
興味はある >>678
ここに玉にディスりにくるRust坊、ほんと性格悪いな 設計が間違えてチャネルで無限ブロックするならタイムアウトをつけるべきだし、Rustもチャネルで
無限ブロックするしほかの多くの言語も（スレッド）チャネルの受信でブロックする
チャネルとは違うがErlangメッセージパッシングだって似たようなもの >>687
そういうことを言ってるんじゃないのよ
>>677にも書いたけど標準的な安全な代替手段が存在しないことが問題 Rustなんてスレッド実装が固まってから五年も経ってないお子ちゃま スレッドとかだとバッドパーツが一通り手間揃ってて
こういうのはやめましょうってのがほぼデザインパターン化されてるから
コードレビューでつぶせたり
処理を追うとわかったりする >>683,685
CSPモデルのasync/awaitに対する優位性って何？
見た目何もない気がするが。
(ちなJSではなくC#のスレッドプールに対するasync/await想定でよろしく) もともと危険なthread/mutexには安全なwrapperがあるのにgoのchannelにはそれが無いから、ってことかな？ >>688
平行性のある現代的なプログラミング言語ではデットロックは言語仕様の問題ではなく、食事する哲学者の問題と
同じく制限された個数のチャネルで送られたデータが受け取られていないのに、送信できるようにはなりません。
これがレース競合を起こさないための標準的で安全な手段であり、グローバル変数や変数共有をgoroutine介して
同期ミューテックスもない操作すれば当然警告が出るでしょう。
そもそもgoroutineでのチャネルブロックはデットロックではなく、待機ブロックです。その証拠にSIGINTなどの
シグナルでは待機ブロックでも抜けるはずです。本来のデットロックなら応答しないかゾンビになります
もちろんスレッド（あるいは軽量スレッド）間でチャネルを介してのみデータを共有できるプログラミング言語も
存在しますが、goは親スコープにある変数などを操作できるように利便性のトレードオフ設計であり、より現実的で
効率的だとも言えるでしょう
また制限された個数でないチャネルの場合は送信に受信側処理速度が追い付かない場合、キューイングされて
無限にメモリーが圧迫される危険性があります。
非同期系の言語で使用されるpromiseや、未来値のプレスホルダーを参照するfutureでデットロックが起きないのは
当たり前です。前者は非同期であり並列/並行ではありません、後者は終了時まで待って値を受け渡すだけです。
fork-joinは何が言いたいのかわかりません、actorプログラミングモデルや純関数言語ならその通りですが
共有したいデータが多くの言語でチャネルやパッシングを介してのみなので競合は起こらないでしょうが
いつまで待っても到着しない受信側は、永遠に待ち続けるのは変わりません。
「そういう事をいってるんじゃない」
ま、こういう問題を一切合切、無難に解決してくれる標準的な手段を手続き言語に求めるのは分からなくも
ないですが、最終的にデットロック（あるいは待機ブロックで無限待ち）したらどうするか記述するような
フォールトトレラント処理が欲しいわけでもないのでしょうが、個数が限られている場合のレース競合対策の
ルールなので言語的ではなく、哲学的にどうにもならないと思いますが >>693
それお前が今書いたん？
ググってもヒットしないが、そうとも思えないから原典があるのならそっちのURLくれ。
横だが「そういうことを言ってるんじゃないのよ」ってのは、単に、
生でスレッド処理を弄らせてデッドロックの危険を避ける色々な仕掛けを正しく準備しろ、というのなら、
フレームワーク等でその辺の仕掛けを全部用意してしまって、その上でジョブをキューイング出来るようにするだけの方が
処理性能も同じで手間がかからない分だけ合理的だろ、という話だよ。
Web系でSessionや認証周りは全部フレームワークに丸投げするべき、と言われているのと同じ。
スレッド周りでどうせ色々やらないといけないなら、最初からフレームワークに丸投げした方が合理的なんだよ。
だから、レイヤーが低い記述が出来るのなら、その手間に見合うだけの価値がないと意味無いんだけど、それがないでしょ、って話。
平行並列周りの研究をしてていじくり回したいだけの人＝そのプログラムがその時動けばいいだけの人
にとっては言語が直接サポートしてるのは便利だけど、
製品としてガッツリ動かす為には結局色々全部必要なら、職業プログラマにとってはまるで意味無いよね、という話。 >>696
何の検証？デッドロック？
async/awaitはデッドロックはしないぞ。
(永遠にジョブが終わらずに待たされてるように見えるだけ。メインスレッドは動き続けるし、GUIも動く) いやこれはMSのC#おじさんだね、チャネルの話ならまだ良いがGolangの設計にありえないasync/awaitとフレームワークを交えながら意味不明なことを呟き続ける。
普通にデッドロックするしフレームワークってなんやねん（笑）Web系なんて共有すべきデータが無いんだからシコシコ糞コード書いてろよ？
おまえの競争相手はJavaとかPHPとかRailsだから、そっちに噛みついてこい、C#なのかRustなのかどうでも良いけど頭おかしいことは確か >>697
そういう意味ではモデルの記述力か。
async/awaitは動作モデルを単純化することで安全性を保証できるようになったけど
食事する哲学者問題みたいなものを記述することができない。 async/awaitみたいな使い方ができないのはヤダヤダってことなんだろうな >>688
どの手段も場合毎に安全では無いし、それ故に画一的な標準的手段にはなり得ないから、それだけバリエーションがあるんよ。
Goはそのあたり多様性をネグって「こういう場合はこういう事に気をつけようねぇ！！」という脳筋的解決を図ってるの。
愚直だけどシンプルよ。 Taskをスレッドプール使ってやりくりするより、はるかに早いんよな…goroutine。 むしろ定年間際な俺みたいなCで育った奴の方にウケてないのか？ Go以外の並行処理のことはよくしらんけど、「Go言語による並行処理」を一通り読んでからは、並行処理でバグることへったよ
他の並行処理モデルだともっとうまいこといけるんか？ 別の言語じゃ主にメモリを共有して排他処理して使ってる
ガバガバだけどミスには寛容なのでわりかし安心ではある
Goでもガバガバにキャパシティ増やしとけばそんなにデッドロックしないと思うんだけど
デフォルトだと一個でもキューされてると次の送信がwaitになる優しくない仕様を問題視してるんじゃないかな？ >>700
> 食事する哲学者問題
これを記述出来たとして、何が嬉しいんだ？
並列は結局のところ、処理能力の増大を目指してる。
シングルスレッドに無限大の処理能力があれば、誰も並列なんて使わない。
現実的にはこれはないから、様々な方策を用いて何とかするわけだ。
そこで、ジョブを他CPUに投げれれば事足りますね、で単純化したのがasync/awaitで、実際確かにこれで済む。
マルチスレッドの諸問題と解決策等、プログラミング界で経験値がたまった結果の、現段階の最適解だ。
これを実装してなくてどうする？と思うが。
スレッド周りの問題をいじくり回したい研究者には向いてるのだろうけど、それだけだよね。
やりたければ他言語でも生スレッドは使えるから、いくらでも出来るけど。
逆にGoroutineではチャネル接続タイプしか記述出来ないから、そこを越えた研究には向かないよ。
とはいえ現段階ではチャネル接続の優位性が覆る事はなさそうだが。
多分な、
・チャネル接続にすればマルチスレッドの諸問題が解決するかも？
という見積もりが外れただけなのだと思うよ。だからGoはメジャーになり損ねた。
なおJSは逆に、
・シングルスレッドに無限大の処理能力があれば、誰も並列なんて使わない。
→ならシングルスレッドの処理能力を無限大にすればよくね？引っかかってるところ全部I/Oだろ
でI/Oをすべて切り離して非同期にした結果、これが大当たりして、あらゆる所に蔓延ってる。
当時メジャーでなかったクロージャの利便性を知らしめたとか、GUIにはプロトタイプが向いてたとか、他にも色々あるけど、
根本の言語設計が素晴らしかったから結果的にでも大当たりしたのは事実だよ。 >>708
というより、本来チャネルよりも適した抽象化がある場合でもチャネル使わなきゃいけないことが問題じゃないかな
たとえばpromiseで一つの値を返せたらいいだけのケースでチャネル使っちゃうと、
そこに処理は単一の結果の生成をもって完了するというセマンティクスは全く残らないわけよ
で誤って値を2回取り出そうとしたらデッドロックだ ていうかgoでもロックとか
サードパーティのロックフリーキューのライブラリは使えんじゃね？
しらんけど >>710
ちなみにPromiseも俺は不要だと思ってるんだけど、
Promiseが無いと書けない何かってあるか？
C#はPromise見えてたけど採用しなかったし、実際async/awaitで足りてる感じだし。 >>712
async/awaitで使用されるTaskはpromiseの一種だよ >>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実装してデビューしてたら神だったと思うよ。 >>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内で同期処理すればいいので、今の話題とは無関係 >>715
それはPromise中心主義的な考えであって、
実際async/awaitの理解にはPromiseの理解は不要だろ。
「そこで一旦止まって、非同期Jobが終わり次第、次を実行」で済むのだから。
実装でPromise型にするのも一つの手だけど、forkでも実装出来るのだし、(むしろforkの方が簡単）
> async/await自体もpromiseの実装だよ
これは買いかぶりすぎで、async/awaitとPromiseは直接の関係も必然性もないよ。 >>715
そういえば脱線を嫌ってるのか？なら戻しておくと、
Goはgoroutineで並列平行をお気楽に書けるようにしたが、
並列は今のところasync/awaitで決まりなので、目論見は外れた。
平行は…async/awaitではなさそうだし、まあチャネルだろうし、goroutineかも？ >>715
716（脱線側）補足
× > async/await自体もpromiseの実装だよ
○ async/awaitの実装の一つがpromise
async/awaitはただの記法であって、その実装にpromise方式も使える。
つまりasync/awaitの方が上位概念だよ。同一レイヤーではない。 >>714
Taskなしのasync/awaitだけじゃ並列処理できないんじゃないの？ >>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スレッドに振るようにしたら並列するようになるだけだよ。 awaitで待っている側はその間止まっているわけだから並行処理ではあっても並列処理じゃないでしょ。
まぁTask.WaitAllのように複数同時に投げられるようにするならそれでもいいだろうけど。 async/await ってPromiseの糖衣構文にしか見えなくて大いに疑問が(知らないだけ？
糖衣構文で言語仕様を膨らませて、こんなに簡潔に書けるようになりました！とかもう子供かと
言語仕様が増えても出来ることが簡潔に書ける以外で変わらないんじゃ劣化してるだろ
簡潔にと言われるたびに信用を下げる >>721
それは君のawaitの理解が間違ってる。
書いたとおり、awaitで「メインスレッドは一旦処理が返る」から、GUIも反応するんだよ。
メインスレッドはasync/awaitでは止まらない。
awaitでイベントループ(メッセージポンプ)に返されるだけ。
その後asyncが終了したら、awaitの続きから実行される。
この実装の一つとして、Promiseがある。でも動かすだけならforkで実装した方が多分簡単。
メインスレッドは止まってないのだから、asyncジョブはいくらでも「順次」投げられる。
（同時に投げる必要はない）
並列平行したければ好きなだけ投げ込めばいいだけ。 >>721
俺の理解では
awaitは非同期関数でのawait以降のセンテンスをthenメソッドの処理としてasyncを実行する
thenのネストを平らにして、単に簡略に書けるだけの糖衣構文 >>724
まー、理解が怪しいんで間違ってたら指摘してくれ
ともかくawaitじゃメインスレッドは停まらない、もしくはメインスレッドではawaitは呼べない(はずじゃなかったか？)、という程度の理解 >>722
簡単は正義だろ。
無駄に仕様が膨らんでいるのは、紆余曲折しすぎたからだ。
Promiseが便利だとされているのはPromise.all位で、つまりjoinだが、
今のasync/awaitはこれを直接的に解決する手段を提供してない。
だからここが何とかなれば、async/await以外は廃止方向だと思うぜ。今のままなら。
JSの場合はasync/awaitが見えてたのにPromise導入に踏み切った。
俺はあれは判断を間違えてると思うよ。
JSは仕様を廃止出来ないのだから、ムダ仕様を入れる度にオワコン化していくだけ。
逆に、バージョン管理してて仕様を廃止出来るC#は、実験場にも出来るし、今そうなってる感はあるけど、
本来ならもっと軽量級のGoやRubyで色々やるべきだったよね。
Goも登場時の2009にasync/await持ってればもっとメジャーになってたと思うよ。
goroutineも無いよりはましだけど、その程度でしかないから今こうなわけでさ。 >>723
イベントループの存在が前提なのかな。
async/awaitではawaitで待っているTaskが内部でまたawait待ちになった時に
その制御を取得する手段がないから、そのイベントループ自体はasync/awaitとは
異なる機構で実現されてるってことかね。 >>727
そうだね。少なくともC#もJSもそう。ランタイムがある前提。
要は、asyncジョブが終わった時にメインスレッドをたたき起こす仕組みが必要なだけ。
GUIの場合はメインスレッドはイベントループを回ってるから、そこにイベントとして与えるのが一番簡単だし、そうしてるはず。
コンソールアプリだとイベントループはないので、ランタイム側にメインスレッドをたたき起こす仕組みを付加しないといけない。
けど、goでもこれはやれば出来るだけの話だよね。 >>716
違うよ。
全然別の部分からresolveされるPromiseをawaitするっていう、コールバック関数をasync/awaitに変換する事ができたりする。
可換なんよ。 async/awaitが使われていると、コードのいろんな箇所がどんどんノンブロッキングになっていく傾向がある気がしていて、
多くの人にとってかなり使い心地が良いんだろうな、と思ってる
俺はチャネルとgoroutine好きだけど、よく考えるとみんなうまく使えてないんだよなあ・・・ > 俺はチャネルとgoroutine好きだけど、よく考えるとみんなうまく使えてないんだよなあ・・・
太田道灌 >>730
出来るのは分かるが、使い道がないんだよ。
俺もPromiseは要は予約を積んでるだけなので無限に動的に積んで色々出来るか？と思った事はあった。
async/awaitはその点ハードコードだからそのルーチンしか処理しないし、狭い範囲で確定的だ。
ただな、Promiseに動的にいろんな場所からPromiseを積み重ねないといけないような状況はないんだ。
単にasync/awaitでまっすぐ書くだけで十分なんだよ。 >>731
> 俺はチャネルとgoroutine好きだけど、よく考えるとみんなうまく使えてないんだよなあ・・・
ならお前が上手く使ってる例を布教すればいいだけ。
それが凄く有用で、現行のasync/awaitやPromiseでは実現出来ないものであれば、
Goスゲーって事になるだけ。
JSも2005にXHRが再発見されるまではオモチャ扱いだったし、ワンチャンはあるぞ。 >>733
めちゃくちゃ使うよ。
既にメモ化されたデータがあればそれを使う、そこに無ければ動的にイベントハンドラー仕掛けておいて、一定時間内にそのイベントが発火したならそのイベントの引数を返すが、発火しなければrejectする、みたいな。
async/awaitしか使わない、CPUをきちんと解放しろ、と言う話なら、Goならランタイムが自動的にやるので気にせず同期型のように書いて良いぞ。 >>736
よく分からんからコードで頼む。
君のコードでなくてもいいし、誰かのGitHubでもいいので。
要はその、Promiseでは簡単に出来るが、async/awaitでは無理（または複雑になる)、っていうコードを。 >>735
おれの知識はほぼほぼ「Go言語による並行処理」だから、これを読め、で終わってしまう・・・ >>737
この説明でわからなければ、どーせメリットもわかんないだろうから「めんどくさいコード書くな」で終わるでしょw
実際に使ってる自分のリポジトリ晒すのもアホだし、Zennの記事はっとくわ。
https://zenn.dev/uzimaru0000/scraps/b4445cfed8f42f async/await(だけ)では面倒で、Promiseと可換だからこそ便利だ、と言ってるんよ。
C#でも皆に臨まれてTask Likeな自作クラスが作れるようになったわけだが、いかんせん大袈裟な作りがいる。 >>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はもしかしたら駄目かも） 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.の直後) に実行される
} >>710
一回だけ使うはずなのを二回以上使うと不具合があるのが問題とか言い出したら
副作用のある関数の呼び出しも問題ってことになるよな
「単一の結果の生成をもって完了するというセマンティクス」というのもないし まあゴル同士で複雑なハンドシェイク的な値のやり取りはしない方が良いね
少なくとも俺はバッドパーツ認定してる
結果をkey-value storeに吐くとかそういう使い方しかしてない >>746
そうだね
副作用があって2回呼び出したら死ぬ関数より、冪等な関数の方が望ましいよね
だから単一の結果を生成するだけの処理にchannelを使うのはクソだよね >>748
副作用のある関数もクソということになるだろうって話だがな
呼び出すべきじゃないところで誤って呼び出すと不具合があるから問題だと言い出すんだから >>749
それはその通りで、一般論として、副作用のない関数より副作用のある関数のほうが相対的にはクソだろ？
本来副作用の必要がない場合でも常に副作用のある関数として実装しなければならないとしたら、本来例えば半分程度で済むはずが全てクソ関数になっちゃうじゃん
それがchannel まあGoの設計思想的としてはそもそも非同期関数を作っちゃいけないんだろうな
常に非同期で使用することが明らかな場合でもchannelを引数に取るような関数をパッケージ外に公開するような設計はすべきじゃなくて、
普通に同期関数にしといて使う側で必要に応じてgoroutine使えということなんだろう え？goroutineにチャネル渡さなけりゃクロージャで渡すしかないから共通関数にできんし
ちょっと何を言ってるのか分かりませんね tourはあくまで機能の紹介だろ。
hello worldを実務で書くか？
channelの何が気に食わんの？デッドロックするところ？
別に後続の関数投げても良いんだぞ。 >>754
>>753 が言ってるのはライブラリの公開関数の話で、753のコメント通りでしょ
goroutine使えば同期関数を簡単に非同期にできるから、ライブラリの高階関数は同期にせよ、っていう思想っぽい
標準ライブラリにもチャネルを受け渡しするやつはあるのかもしれないけど、少なくとも俺はしらない 標準のライブラリは低レベル機能しか持たせてないじゃん
だからといって、非同期に使うことは好ましくないという設計思想だとかかなり無理があるだろ
ツアーは基本的な使い方のサンプルなんだから、基本的に非同期で動かす関数を書くにはチャネルを渡しましょう！と大々的に宣言してる証拠じゃないのか？ >>752
>本来副作用の必要がない場合でも常に副作用のある関数として実装しなければならないとしたら
そんなのがどこから出てきたんだか。
呼び出すべきじゃないところで誤って呼び出すと不具合があるからクソだと言い出すなら
入出力とか、副作用を持つ関数もクソということになるって話だがな
戻り値を変数に入れて置けば良いだけなのにそれを出来ずに
2回呼び出すと不具合が起こると文句を言ってるんだよな チャネルが理解できないC#おじさんがID変えて自己弁護しながら暴れてるだけ
>>752
「副作用のない関数より副作用のある関数のほうが相対的にはクソ」
一般的には手続き型言語であればサイドエフェクトがある関数が普通で、純関数言語のようなほとんど副作用の
無い関数などはI/O処理などでビックロックなどで誤魔化してるに過ぎない。
>>753
そもそもGoは全部が非同期・並列だから逆。メインでさえgoroutineの１つで、デフォルトでGOMAXPROCS
「channelを引数に取るような関数をパッケージ外に公開するような設計はすべきじゃなく」これも逆です。
structには本来はchannelやcontextを含めるべきではなく、引数に取ることが推奨されている
>>759
「標準のライブラリは低レベル機能しか持たせてない」最近の言語は、標準のライブラリという重大なクソを
薄く小さくするのが流行り、なぜなら稚拙な標準のライブラリをリリースしてしまい、後からもっと効率的で
理論に裏付けされたライブラリが出てくる。そしてクソな標準が互換性のために直せない。薄くて小さい
ライブラリは速く、メンテナンスも容易で、依存性も少ない。
逆に、標準のライブラリに重厚長大を求めるのは何かが間違ってる。チャネルを渡すことを使う事を禁忌したい
気持ちが奥底にあるから「証拠」なんて言葉が出てくる。Tourなどのパイプライン処理とかを見ればチャネルを
受け渡すことの効率性と高い非依存が良くわかる。aync系の言語でやろうとしたらミューテックスでロックして
処理の終わりでwaitしてなど極めて並列度が低く、依存性が高く、ゴミのような自己満足が広がる
だから遅くて成果物はデカい まぁまぁ、顔真っ赤にして投稿するのやめよ？落ち着こうな 昨日からなにが言いたいのかさっぱり
自分でも頭おかしくなってるんだろうか Go 1.18 Beta 1 is available, with generics, 14 December 2021 ちょっとかじってみたニワカの感想なんだけど
Go言語ってBetter Cって感じだな。 >>763
チャネルを渡すことに積極的な>>759に、真っ赤になってチャネル渡すコーディングを語ってて草 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 } 最近goよりrustが気になってきた
コンパイラ型の早いモダンな言語ということで安易にgoやってたけど
rustにすべきだったか 利用範囲というか得意範囲が違うから興味はない
まして癖が強いんで覚えなきゃならんことが多すぎる
出始めのJavaより癖が強くないかあれは
今は皆が馴染んだけどJavaのIO周りとか、解らねぇ！という声が多かった記憶
だから少なくとも10年は待つのが正解 Goは向いている適用範囲が狭い
他の言語も併用せざるをえない 単体のマシンで並列処理をひたすらに行うという涙ぐましい用途特化よね
無駄金がありゃ分散化してロードバランサ使ってしのぐと思う Goは並列処理が書きやすい簡単な静的型付け言語って感じよな
Goの文法はモダンとはとても言えないけど、わりと早いビルド、gitとの連携、fmt、とかもろもろのエコシステムを総じて言えばモダンと呼べそうではある
逆に、例えばD言語は文法が良いのにエコシステムがウンコだったから人気出なかったんだと思う 分散しないでも程よく性能が出るって点から、ネットワーク関係の組み込み機器(ルータとか)に向いてるような気もする(気がするだけ)んだけど、特に席巻してるとも聞かないから使われてないのかな busybox的な作りならメモリも圧迫しないだろという考え >>782
ルータの中身なんてlinuxでCだろ
組み込みはCPUパワーと消費電力に厳しいのでC以外に現実的に解がない
逆に言えば、C以外で組んだ時には価格と消費電力でその商品に訴求力が無くなる
Cでは実現不可能な程のファームウェアアップデートの頻度が必要な商品もないだろ Google的には組み込み向けはFlutter/Dart >>781
goroutineが正解だと間違えた失敗言語だろ
このチャレンジ自体は良い事だが、正解はasyncだった
複雑になりすぎたC++を嫌い、またWeb系での最速を求めた連中はRustに行った
型を知らなかったWeb系の馬鹿共には丁度良かったが、そいつらはTSに行った
ast木がデフォで出るのは面白いが、あれはプログラマ的にはレベルが低すぎて使えない（自前で正規表現でやるよりはまし程度でしかない）
ならいっそのことあれこれやりまくる実験言語にしてもいいとは思うが、仕様の追加は他言語と比べても遅い
現在新規でGoをやる意味はないから、あとは廃れるだけだろ web系のバックエンドである程度速度求める層には使われてくんじゃないかな。楽だもん。
個人的にはnull安全じゃない点でもういいやって感じだけど。 >>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#は絶対に勉強したくない層向けになるが、これは現実的に無い。 >>788
JS/TSの人材がNode/Denoでサーバーサイドもいけるからね
そしてそれでは性能面リソース面で満足できないならRustが記述しやすくていい Rustが使えない場合で、かつ速度が必要な場合にTS使う訳無いだろ。
C#はわかるが。
マルチコアに弱すぎるわ。
C#ではなくGo選ぶケースってのはGoならではのメリットがあるシーンが多い。 >>791
> Goならではのメリット
だからそれは何？って話だろ。
C#で駄目でGoってのは学習コストくらいだが、学習コストが問題ならWeb系ならTS/JSで決まりだよ。
Goはgoroutineかgo generateが大当たりすれば良かったが、そうでない以上、C#に勝てる仕様がない。
現在シェアでボロ負けしてて光る仕様もなければ、このまま沈没以外にない。
Rustを考えれば分かりやすいが、シェアでボロ負けしててもC#に速度で勝てるし、
安全性も一応最高を目指してるから、選ぶ理由はあるだろ。
GoはRustが出てきた時に身の振り方を考えなければならなかったんだよ。 >>792
そのGoroutineだよ。観測範囲狭いのでは…？
C#のasync awaitとスレッドプールは詰まる。 >>793
asyncな関数を呼べばスケジューラに戻るわけだから
長時間ループで計算のみを続けることでもない限り詰まることはないでしょ あとこんなんも出てきた
https://www.rox-note.tech/?p=30
まあスレッドプールはそういう設計なのだから、デフォで問題ない使い方をしないのなら自前で設定してやらないと駄目だね。
でもスレッドプールはプールであって、goroutineみたいにスレッド占有（スタック保持）ではないので、
動いてないスレッドはプールに返されて結果的にCPUは最速で動くはずだけど。 C#ってサーバというかバックエンドで使えるのか
知らなかった >>797
膨大なタスクでも途中で何らか入出力すればスケジューラに戻るからタスクが切り替わる
入出力ゼロならばそれは延々と算術計算するだけなのだから別スレッド立ち上げればよい goroutineが理解できないC#おじさんがのC#のasyncで騒いでるだけ
こいつは数多くの言語が採用してるchannelの原理も理解できない。 >>800
スレッドだと必要な数が多すぎて回らない。
シミュレーションの類やってる。
あとバッチで集計処理していくとかも作ってるけど、これも一億行百万ファイルとかが対象。 >>801
なるほど。説明しても理解できてないから無駄だし、
理解する気が無いのか。 >>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で回すメリットは何？ >>804
その考え方が古いでしょ。goroutineは軽量スレッドで実質async await+スレッドプールだよ。
https://zenn.dev/hsaki/books/golang-concurrency/viewer/gointernal
>>804
チャンネルでfan in/fan outしてる。 >>801
それは例として厳しいかな
C#については全く知らないが
例えばRustではchannelの送受信もasync環境ではasyncとなる
つまりgoroutineのようにchannel送受信だけを永遠にする長時間タスクがあってもタスクは切り替わる
だからそういう例でも大丈夫
おそらくC#でも同じ状況ではないかと推測 goにおけるチャンネルって、概念的には別スレッドのI/Oにデータ渡して発火させる感じだよね
最大スレッド数は開いているチャンネル数以上になることはないし、
メインスレッドには関係ない
async/awaitで詰まるってのはawaitが文字通りメインスレッドで待つからって話ではなく？ goroutineも実質スレッドプールなのは事実だね
async/awaitはawaitの区切りでしか中断できないのに対してgoroutineはGoのユーザーコードならどこでも中断できるので、どちらがより詰まりにくいかといえばGoかもしれない
とはいえGoもシステムコールの中断はできないから、現実には差は出ないだろうね >>804
Erlangは「スケールアウト時のパフォーマンス低下を回避するために疎結合にしたもの」じゃないよ。プロセスが落ちることを前提にしたもので
パフォーマンスなんて考えてないというのは言い過ぎだが、フォールトトレラントでプロセスが落ちるから沢山のプロセスが起動できるようにした
ものであり、スケールアウトによる性能の保持はその結果に過ぎない。
「一億行・百万ファイル」このように初めから総数が分かっていれば分割できますが、総数が分かっていない場合には、「一行・10億ファイル」
かもしれない。この時に「絶え間なく処理結果が欲しい」ような場合だとスレッドを張り付けた処理は、分割された連続処理群が終わるまで
待たねばなりません。GoやErlangだとこのような処理の次に続く処理があった場合、パイプライン処理として処理します。 >>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のページサイズに因っているから) >>804
それに「Goにはこれがない。 なおC#、.NET4.0の64bit環境では32767個のスレッドが上限らしい。」という中途半端な知識表現に
ついても一般的なOSではスレッドの上限は16bitの域を出ないで少ないのは当たり前で、それはスレッドがあまりにもOSにとっては
重すぎるから。(メモリやコンテキストスイッチなど払う代償が大きい）
Erlangはだいぶ思想が違うのはその通りだけど、GoはErlangほどではないが、小さいコストで多数の軽量スレッドを用意したもので
あり、これが何のために「Erlangで良いよね？」にならなかったのかといえば、背景にあるのは多数コアを搭載した近年のハードウェアを
生かし切れていない言語が溢れていたから
じゃあGoの役割はなんなのと言えば、Erlangはプロセスがネットワーク分散を簡単にできるが（その分遅め）、Goはコンパクトな
1つのマシンの中で上記のようなパイプライン処理をコンパクトに「なるべく早く」出来るよう考えられた。 >>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級あるのを知っていますか？ Goのランタイムのフットプリントはかなりでかいし、GCだけでなくそういうコストも許容できる贅沢な環境で、手抜きをして並列処理を書ける言語だよ
ようするに、RustやCで書くのはめんどいしメモリ食われてもいいけど楽してM:Nスケジューラ使いたい、みたいなときには適してる、っていえる言語ではないかと
非同期シングルスレッドしか使わない、っていうんならいろんな言語が選択肢に入りそう >>812
>「Go信者はgoroutineのコストがゼロだと仮定」これもダウトです
これ確かにGoroutineがコスト高いことを知らない人たちが意外に多い
例えばRustのタスクなんかはGoroutineに比べたら本当にコストゼロ
スタックレスであるし素朴な状態マシンとしてコルーチンとして機能するだけ
だからGoroutineよりリソース的にも軽いし起動も軽いし
巨大なランタイムを必要とするGoと違って非常にシンプル >>809
いやErlangは電話交換機用に開発された言語で、メタル回線時代だから最初から物理で殴る前提だ。
（収容数が増えたらラックを増やすしかない）
プロセスどうのこうのはOSの話だ。ただしErlangが生まれた80年代はそこまで綺麗に分離してなくて、
ErlangのランタイムがOS扱いだったのだろうけど。
フォールトトレラント性も多分最初から考えられていたのだとは思う。
> 「一行・10億ファイル」
論理CPU数を数万倍越えるジョブがあると分かっているのなら、纏めればいいだけの話。
単に1ジョブ毎に放り込むのではなく、100ジョブ纏めて取ってきてから放り込めばいい。
原理的にはgoroutine*100と同じ速度が出る。 >>811
> 一般的なOSではスレッドの上限は16bitの域を出ないで少ないのは当たり前
そうじゃなくて、そういう風に作ってないだけ。
つまり、現行のOSでは、スレッドはそこまで使わない前提、そういう風には使わない前提だ。
> 小さいコストで多数の軽量スレッドを用意したものであり、
これをどう見るかだが、本来ならそれ用のOSを作らないといけないんだよ。
ただし実際はGoのランタイムでどうにかなる（=ハードウェアサポート無しでいい）から
そういう動きもないのだろうけど。
> Erlangはプロセスがネットワーク分散を簡単にできるが（その分遅め）、
> Goはコンパクトな1つのマシンの中で
これはその通り。Erlangは疎結合にしすぎてて、近年のハードウェア向きではない。
とはいえGoもまた行きすぎだよ。
論理CPU数を遙かに越える数のgoroutineを起動しても、速くはならない。
(ただ、コードは簡単に書けるだろうけど) >>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の方が速い理由を説明出来ないだろ。 そら最速を求めるならクソデカランタイムが仕込まれてるGoが勝てるわけがない >>813
ああすまん、リンクは完全に失念してた。
で、読んだが、何だ？知ってたような内容しか書いてないが。
わざわざ指摘してくるのだから、fan in/fan out の説明があるのかと期待したが。 書きやすさ&ビルドのしやすさ、なんてのも実務的には大切。
ザクッと書いてクロスでコンパイルして大量のサーバに撒く、がめちゃくちゃ楽だよ。 >>821
実際、軽量スレッドな事は知らなかったじゃん。
知ってたような事が書いてたけど誤解してたの？間抜けだな。 >>819
フレームワークを使うともっと速くなるみたいで、最初はRust負けててactix使ったら勝ったらしい
フレームワークのベンチならこっちにある
https://www.techempower.com/benchmarks/
フレームワークを使わないケースだと、同じような実装にする努力の跡は見えるが、結果が言語単品の性能を表しているのか標準ライブラリの質を表しているのか、はたまた測り方なのか、何を表しているのかは知らない >>823
いや知っててあの内容だが？
それで納得出来ないのならそれでいいが、
goroutineは軽くはないし、ゼロコストでは全然無いよ。 >>819
サンプルコード見たけど酷いな
言語そのものの速度を比較するためのものとは思えない
典型的スクリプトキディのおじさんだ >>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. Goは何も考えんでも、公式の実装がハズレ無いのでオーダーさえ考えて実装してれば間違いは無い。
まぁ、そもそもオーダーの計算を失敗しがちなmapとかflatMap無いからな。全部ループ。
そのおかげでめちゃくちゃキャッシュにきれいに載るというのもある。
思ってるより早いよ。 >>819
.NET他環境の半分程度の性能しか出ないのかよ
C#おじさんのご高説はなんだったの？戯言？ >>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#は重量級であって、日曜大工でやろうというものではないが。 >>831
C#のAOTはこのケースにはあんまりきかないない。
なおそこてはなくてこっち。
https://github.com/dotnet/runtimelab/blob/feature/NativeAOT/docs/using-nativeaot/README.md
刺さるときはめちゃくちゃ刺さる。制約にひっかからないかぎりよく使うよ。
ただこれでもダメならGo書いた方が楽。
Goらしいコードが書けてないのでは？と言う印象だな。
C#の主戦場はUnityは言い過ぎでは？
お前業務システムエアプ勢か？ >>831
コネクション増える程.NETの性能悪化してgoとの差開いてるだろ
都合の悪い所は見えなくなるのか？ >>819
なんでこれdotnetはDebugビルドで実行してるの？？ >>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コードでも外せません。決して
キャッシュおかげでも、あなたの足りない語彙のせいでもありません。 >>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 一応訂正しておくよ。以前書いたフレームのベンチでも
https://www.techempower.com/benchmarks/#section=data-r20&;hw=ph&test=plaintext
このベンチが一番近いはずだが、nodejsは決して速くない。
js勢だとjustが速い。 > Goらしいコードが書けてないのでは？と言う印象だな。
ある程度書いてないとらしさみたいなもんは分からんわな
どんな言語でも
よってここに天下一武道会を開催する
各言語のらしさの粋をあつめたコードで
Concurrencyの雌雄を決したい >>837
nodejsはフレームワークとは言えんような。
justはnodeインストールしてなくても動くのかい？ >>838
まずはぜひGoらしいコードを叩き台として出して 自分で手を動かせ
誰かに何かを「やってもらう」ところじゃねーんだよ
自分でできないやつは書き込むな >>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が使えるレベルの仕上がりかどうかは知らんが。 >>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/ 別に.netをディスってる訳では無いんだが、代理戦争みたいな真似する理由がわからん。
GoがWebフレームワークのベンチマーク弱い理由はだいたいこの記事にまとまってる。
https://zenn.dev/nobonobo/articles/e651c66a15aaed657d6e
同じ事したら他のフレームワークと同じかもう少し早い。
ヘイトに関してはだいたいこれじゃん。
https://zenn.dev/nobonobo/articles/74808a8d5e6f1e >>843
ホントにやってみて言ってるか？ひっかかるぞ。 >>845
リフレクションを常用してるのなら、それは基本的にお前の組み方が悪い。 >>844
「GoがWebフレームワークのベンチマーク弱い理由」が書かれていない記事に見えるがリンク合ってる？ >>834
これ。Debugビルドでやって何の意味があるの？そりゃあ最適化されてなかったら遅いわ… >>844
> https://zenn.dev/nobonobo/articles/74808a8d5e6f1e
> Rob Pike氏はあらゆる既存のプログラミング言語が互いに発案した特徴を取り込みあって、
> あらゆる言語が同じような言語に向かっていることに異を唱え、そうではない言語を作ろうとして
> (略)
> Goのアイデンティティのひとつに「厳選された必要十分な機能セット」というものがあり、
> 過去ここを壊すような多くの提案には「No!」が突き付けられてきました。
Goはなんか言語としてのウリが弱くて
逆に言語としての機能不足を非難されたりするけど
ここにC++を持ってくると急に腑に落ちるな
ブヨブヨに肥大したC++の現状の惨状を見ると
そらロブの言いたいことも分かるってもんよ
Goに対する一部の批判はそら的外れってもんよ かなり後発のRustが先発言語たちから厳選された機能を洗練して上手く採り入れていって
純粋に言語としての比較ではGoを抜き去って行った感がある 個人的に趣味でゲーム作ってて、
（仕事はPythonとかのスクリプト言語）
そのバックエンドに高速そうなGo使おうと思って勉強してるんだけど
そういうレベルの俺からするとRustはものすごく難しそうというか、厳しそうに思えてしまうんだよな
メモリリークって一番やりそうだもん >>851
何か勘違いしてない？
RustはC言語と違って
使われなくなった瞬間に自動的にメモリ解放してくれる言語 >>846
リフレクション以外もひっかかる。
試してから言え。
>>847
APIの秒間リクエスト処理数比較などもそうです。HTTPヘッダパース遅延評価機能を持つものと持たないもののベンチマーク等ではヘッダへのアクセス不要な簡易負荷で比較しているような状況になりがちです。特にデータベースアクセスなどを伴わないような場合だとその性能差は大きな差として現れます。
実際、Goのサードパーティライブラリ「fasthttp」はHTTPヘッダパース遅延評価機能を持っており、この場合ベンチマーク結果の数値は最速実装にかなり近づきます。しかし、HTTPヘッダは実用の現場の場合、評価しないわけにはいかないので実用上の性能は標準のnet/httpと大差ないということが実際にあり得ます。 >>852
ガベージコレクションが無いって事しか知らない
違うのか
ってかスレチかもすまん >>854
Rustは使われなくなったら即座に自動的にメモリを解放してくれるため
ガベージコレクションを必要とせず速い >>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なんて
恥ずかし気もなく言い出せる。オープンソースなんだからコードぐらい追えよ？ >>851
順当なら間違いなくJS/TS。
どのみちフロントエンドも必要だからJSは習熟するしかない。
それでバックエンドも出来るのだから、Python鯖が嫌ならJS鯖になる。
ただしJSは最速ではない。
(アーキは良いのでコンパイラが出てくれば最速になる可能性もあるが、5～10年は無いだろう）
だから順当には、JS鯖で負荷的に無理になったタイミングで移行を考えればいい。
そして個人レベルのゲーム鯖でこれが必要になる事はまずない。
もし仮に大当たりしてこうなっても、マネタイズがそれなりに出来ていれば、人を雇う事/外注も出来る。
もしコンピューターについて学びたいと思ってるのなら、順当にはCになる。
Rustを最初にやっても、色々意味が分からないはず。
一般的にはRustはC->C++->Rustと学ばないと良さを理解出来ないと言われていて、
Rustやるんだったら結局はCもやる事になるので、最初からCやっとけとなり、
「RustのおかげでRustよりもCを学ぶ連中の方が多くなってしまったではないか！！！！」とRust界隈で話題になってたのが2019だったと思う。
ただし最終的にRustを使うつもりならCの熟練者になる必要はない。ただ、知っておく必要はある。
この辺最近、こいつらはこの処理が何故重いのか全く理解出来てないんだな、と感じる事が多い。
これはコンピューターが複雑化した事もあるが、コンピューターの物理面を知らないで済ませようとしてるからだ。
（論理的なプログラミングに留めている。それを目指したのがJavaでもあるのだが）
だからベンチマークに頼らないといけなくなる。何故それが速いか遅いかを自分で判断出来る能力がないからだ。
だからこの辺、自分で判断出来る能力が欲しければCをやるべきだし、
とはいえ現実的にはフレームワークを使うわけで、フレームワークが最適化されてればそれで良し、駄目なら駄目、
と一生ベンチに頼るのもありだし、現実的にこれでも大した問題がないのも事実だろう。
この場合はCなんてやるだけ無駄、ってことになる。だからどういう能力が欲しいかを自分で考えるべきだね。
ちなみにRustもTSもNodeも無かった時代に同じ事を聞かれるとGoと答えただろう。
Go界隈の最大の問題はここで、最初に運良くブーストした？のに浸ってる。
今はもう違う事を認識出来てない。 >>857
なぜ不便なCを勧めるのか理解できない
Cをやるくらいなら自動的にメモリを解放してくれるRustが楽で良い
スクリプト言語と似た感じで便利にプログラミングできる点も良い Cもなんだけど、TSなんか特に。
マルチコア使うのがめちゃくちゃ下手な言語を、どうしてGoの対抗馬に持ってこれるの？
それら全ての言語を使ってないのでは？
nodeはnodeで便利だがGoと代替にはならんよ。
RustはRustで早いけどGoの代替には簡単にはならない。 objective-c: objectiveが売りなんで頭にもってきたネーミング
c++: cのフリしつつ拡張するつもりの邪悪なネーミング
go: いちにーさんしーごーでシンプルにしーの後に躍り出る命名 >>858
モロクソ書いてるだろ。3行しか読めない馬鹿か？
オレオレゲーム鯖立てるつもりならJS/TS、個人ゲーで負荷的に無理になることはまず無いし、フロントエンドでどのみち使うし。
コンピューターについて学ぶつもりならC、Rustを先にやったところでRustを使えるようにしかならない。
現段階でGoを選ぶ理由がない。Goを学ぶ事が目的ならどうぞだが。 フロントエンドなら最近はWASMが増えてきて記述言語で一番適していて多数派がRustといった状況
もちろんサーバーサイドもRustで行ける
Goは巨大ランタイムのせいでWASMと相性がよくない >>862
そもそもGoは外部と相互運用する事を前提としてない言語だと思う。
少し互換性は失われるけど、isomorphicにしたいならTinyGoかなぁ。 node-jsもjust-jsもJavaScriptの実行環境。just-jsでも
(async()=>{await Promise.all([...Array(10)].map(async(_,i)=>{just.print(i);}));})();
が普通に実行できる。並列かどうかは知らない。 JSである以上、asyncなんて書いてもコールバックであり並列でもなければ、平行ですらありません。というかほんの数年前のJS使いなら
setTimeout()と書いて非同期タイマー呼び出しぐらい理解してるはずなんだが？今では、Nodeなら、nextTick()だろうけど
普通に実行できるとか、そりゃ言語仕様としてGoogleが携わってるV8使ってんだから出来るでしょうよｗ
just-jsおじさんｗ JavaScriptのアーキテクチャが良いと言うのもよくわからんよな。
シングルスレッドだし、別プロセスは前から立てれたが、別スレッドを満足に立てられるようになったのは最近。
epoll使ったイベントループの事を褒めるのであれば、それこそGoのselectの方が賢いんだし。 一応書いておくけど何かをディスってるわけではないよ。訂正してるだけ。
V8はエンジン。言語仕様はES～。
>>856がnon-async by default - can do blocking calls and not use the event loopを引き合いに出していたので、asyncが使えることを示した。
並列になることを期待している可能性もあったが、コードを追って確認したわけではないので、単に「知らない」と書いた。 >>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でも出来るはずだが、やろうとした事はなかったな…) >>868
just-jsのjustコマンドはnodejsのnodeコマンドに相当
consoleオブジェクトがないなど癖が強いので、一般利用なら個人的にはnodeでいいと思う >>868
はびこってるのか理解できないと言うのは誰かと間違ってないか？
俺はnodeはnodeでアリだがGoの分野とは相容れないと言ってるんだが。
考えないと早くならないcppやrustと対比させてるのであって、jsとは全く対比させてない。 >>865
それはJavaScriptに対してあまりにも無知すぎる
async/await登場以前からJSは並行プログラミング言語
async/awaitはどの言語でも同じだがそれを同期して同期風に記述できる付加機能
ちなみにworkerによってJavaScriptは並列プログラミングも可能 >>871
上の「 (async()=>{await Promise.all()」がどこに並列があって、関係のないworkerに話が飛ぶんだｗ誤魔化しマウント野郎ｗ
ウッホウッホホ、ドラミングｗ
おまえのご自慢のnanoexpressとかjust-jsのどこにworkerが使われてるんだ？ >>868
使ったことないのに言い出す奴ｗｗｗ
「JSが何故ここまで蔓延ってるのか」C#おじさんの全方位敵対ｗ nanoとかjustとか全く知らなくて
JSについては普通にブラウザ上とNode.jsしか使っていないが
>>865
> JSである以上、asyncなんて書いてもコールバックであり並列でもなければ、平行ですらありません。
これは明らかにウソ
JavaScriptは基本的に全て並行プログラミングであって並行に動作する
しかもJSの場合は暗黙的に自動並行開始という特徴がある
例えばGoならgo、Rustならspwanしないと並行開始されないが
JSは非同期関数(＝名前にSyncと付いていないもの)を使った時点でスケジューラに登録され並行開始
これはコールバック使用でもPromise使用でも同じでもちろんasync/await使用でも同じ
Web関連の並行性について話をするなら上記の初歩的な知識は必須な基本事項 あっそ、じゃあGoスレじゃなくNodeスレで一人語ってくださいね？言語以前に人としてのマナーを学びましょう >>874
Goの適用範囲のメインがウェブ周辺なのにも関わらずそういう基本的な知識すらないやつ時々いるよな
あと他の言語を知らずしてGoの良い点も悪い点も語れないしな >>875
並行と並列の違いも理解できてないから、あんまり相手にしてもしょうがないよ。Goも知らないっぽい・・・
Goはgo呼び出ししなくてもメインルーチェンがgoroutineだし Goのメイン、Webでは無いだろ。
自分の分野がWebだからハンマー釘になってるのでは？ >>878
そうよね…なんか凄く脱力感あるわ…。
この文脈でTSを推す理由が全くわからん。 >>878
君が理解出来ていないのではないか
JavaScriptはWorker使わない限り全て並行であり並列ではない
もちろんWorkerを使えば並列も可
まさかと思うがGoではどうなのかも理解できていなかったりする？
>>880
TSなんて書き込みをしたこともないのでそれは別人だぜ 内容ゼロの真逆のことを言い出した…
Goのメインはパイプラインデータ処理のバッチ系のほうが大きいと思うね、確かにメニーコアをあまり無駄なく活用するからwebも使えるけど 自分と異なる意見を書いてるやつは敵であり、敵はそいつ一人
という思い込みパターンは5chではよくあるな ID:QeQ2VGy/
「JavaScriptは基本的に全て並行プログラミングであって並行に動作する」
「JavaScriptはWorker使わない限り全て並行であり並列ではない」
(笑)解離性同一性障害かなんなのか、当てるスレ。もうさjavascriptもgoもrustも関係ないなあ >>884
どちらも正しいが何を言いたい？
JavaScriptは基本的に全て並行であって並列ではない
Workerという後から追加された機能を使ったときのみ並列動作が可能 おそらくだけど>>884氏は並行と並列の違いをわかっていないために誤読
さらに暴走して解離性なんちゃら言い出しただけかと はい、ここでトリックです。(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なわけです。 >>887
jsは自前でsleepしてないから妥当すぎてなんとも
シングルスレッドな言語で自前でsleepしてたらイベントも受けとれんわ
時間が来るまで処理のスイッチがなされないだけ >>881
そうだね。そのWorkerがクソ重いって言ったぞ。
worker跨ぐ並行並列の話では？C#のasync awaitは。
Goはworkerを立てずともなってる。 >>887
sleepではなく切れ目無くCPUをガンガンに使う処理入れようか。 >>861
Rust界隈は>>858みたいなバカ多いから……いわゆるゴールデンハンマー。
Rustはもっと学習メソッドと設計思想の解説を強化すべきだと思うわ。一番厄介な所有権についても、実行速度とメモリ安全を両立させるためにどういう管理をしているのか説明すればわかりやすいのに。 sleep自慢なわけです。C#とasyncから始まった今ここに集まってくる奴らは、道具を眺めて優れた何かを作ってない口だけ
自分で作ってもいない日本刀の刀身眺めてニヤニヤしてる気持ち悪いマニアと一緒 >>890
スケジューラの類いを作ってことあるプログラマーならば
sleepとは時間が来るまでそのタスクが寝るだけだあって
その間に他のタスクが動くことくらいわかりそうなものだが理解できないのか？
>>888
sleepなどのタイマー類はスケジューリングランタイムが提供すべきものであって自作するものではないぞ >>893
そもそもsetTimeoutで完全にCPUを明け渡してて何が「並行」なんよ。 その>>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できる >>869
ありがとう。
手元のNode環境で公式ドキュメントのサンプルコードで試したら普通に動いたわ。（当たり前だが）
俺が勝手に鯖専用と勘違いしていただけで、最初からそう作ってあるんだな。
>>870
ん？870＝828≠866と理解してるから、誰かと勘違いしているわけではないぞ。
ただまあ、それだと考えたくない奴がGoを使うという見解には事には同意という事か。
> 考えないと早くならないcppやrustと対比させてるのであって
禿(＝ストロウストラップ、C++の始祖の巨人）曰く、「C++はプログラマを育てる言語だ」
その理由は簡単で、「考える」からだよ。
C++はあらゆる事が出来る言語であり、思いつく事は何でも試せる。
だからこそ最速の地位を保っているわけだが、
基本的に安全装置なんて付いてないため（まあC++はそれでも付けようと努力してる方だが）
失敗する時は派手に失敗する。
そしてこの、色々試して、成功したり、失敗する過程で、プログラマは成長していく。
Goが脳死で出来るのは脳死してる奴にはメリットだけど、考えないと(慣れはするが)成長はしないので、
成長したいプログラマはGoには居ないし、Goのプログラマは成長もしてない。
多分俺が感じるGo界隈の異様さはここなのだろう。ギークさが足りない。
まあ俺がGoやる事はほぼ無いからいいんだが。 Goはアーキが良くない。中途半端なんだよ。Erlangを考えるなら、
Goはループを廃止して全部goroutineにし、基本map/reduceでmap側をgoroutineにし、
依存性のありなしだけを記述、つまり依存部分はチャネルで接続、
独立部分はgoroutineでランタイム内のスケジューラで状況を見て自動的にループに変更、
とかだと面白かったかもしれん。これなら脳死でひたすらgoroutineに切り出しで済むから。
実際はこれをやったらgoroutineが重すぎて余計に遅くなるから
どの程度goroutineにするか「考えないと」いけないわけでさ。
(この顛末をモロに書いてたのが810で俺が探してたブログ(改めて探したけどやっぱり無いが))
ただ実態はGoランライムが(OSのスケジューラと同様に)
チャネル、スタック、エントリ関数ポインタを持つGoroutine型のオブジェクトを大量に用意して
イベントドリブンで動かしているだけだから、チャネルとスタックの『衣』の部分だけどうしても重くなる。
だから普通に他言語でイベントドリブンで書かれたら絶対にその分負けるわけで、この辺もアーキの良くない部分だよ。
「最速を目指す気はない！」ってのが答えなんだろうけどさ。
ただ、簡単に書ける割には速いってのならJS/TSになってしまうし。 「考えて」判断するなら、コンピューターについて学ばなければいけない。
考える気がないから、学ぶ必要もないし知る気もない。
論理的には正しいし、実際問題として動けばいいのならこれで問題ない。
けど、なんだかね。まあ俺が文句を言う筋もないが。
他言語：オレオレ流でも曲がりなりにもいいコードを書こうとはしてる(結果はさておき)
Go信者：Goで書けば全て落着、と信じてる
だから俺ら他言語の連中は基本的にキョロキョロしてる。
「○○では△△が出来るらしいぞ」「それっていいのか？」「いやあ…」と大体空回りしてるけど、
これは自由の代償として受け止めるしかない。
ここをGoの連中は「そんなの面倒だ。Goで書けば全て問題ないんだ」と信じ切れる奴が集まっているのだろう。
そういう連中もいて、そういう言語も必要なのも事実だろう。
ただ、プラットフォームと心中する気ならC#の方が100倍マシだけどな。
元々はLinuxで使えないという問題はあったが、一応解決された（とはいえ現実的にどうなのかは知らんが）
「No is temporary, Yes is forever.」(844のブログ)はその通りなのだが、結果的には少しタイミングが早かった。
2000年代前半はオブジェクト指向＋マルチスレッド全盛だったから、Goはこれらの問題を解決するようには作ってある。
問題はその後非同期が主流になってしまった点で（まあこれも今後変わるかもだが）
goroutine is foreverであれば、非同期が主流の状況が続く限り埋没する未来しかない。
登場時の問題は解決出来てるが、仕様を追加する気がないのだから、それ以降の問題は何ら解決出来ない、
という当然の状態ではあるのだが。
この点C#は変節に変節を重ね、筋が良かったとは言いがたいが、その時の便利機能を取り込み続けた結果、
「今一番生産性が高い」の地位は何だかんだで保持してる。 自分にある引き出しでしか喋ってないのな。
Go書いたこと結局無さそう。
TS早くないってば。 結局最後は速さにこだわりはじめてRustにすればよかったって流れなんだよな >>901
たしかに速さ目当てでRustにも手を出したが
言語としての機能が豊富でGoよりもプログラミングが快適ということに気付いた 色々考えて大体整理が付いたので、ついでにつらつらと。
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がモロパクしたわけだが。 その長い主張はまとめるとこういう主張？
言語機能が貧弱なGoは普通のプログラマーにとっては使いづらいだけの存在だけど
豊富な機能や複雑な機能を使いこなせない劣ったプログラマーにとっては需要がある rust良いんだけど特定の種類のプログラム
例えば赤黒木とか二重リンクリストみたいなポインタを操作しまくるようなプログラムは明らかに向いてないんだよな >>905
unsafe使いまくるから、野良ライブラリに任せないで標準ライブラリ用意して欲しいよな。 >>906
それは標準ライブラリの位置付けに誤解がある
Rustでは最小限のものしか標準ライブラリに入れない方針を明確にしている
だから各用途ごとの重要なライブラリは全て外部にある
例えばasync/awaitやFutureの枠組みは言語仕様と標準ライブラリにあるが
そのための非同期ランタイムは外部にある
あとunsafeの認識は大丈夫と思うが念のため
unsafeは内部に閉じ込めて安全な公開インタフェースを持つ型(type)やモジュールを作るために存在している
だから標準ライブラリも内部はunsafeだらけだが公開インタフェースを用いる限り安全が保証されるといった具合い
どのような安全なインタフェース体系にするかは用途ごとに異なるためそれぞれに適したライブラリを選ぶか自作すればよい >>903
文系理系の切り方も謎だけど、
「適切なところに適切な道具を持ってくる」というのはエンジニアリングの基本。
誰彼構わずF1マシンに乗っても工数だけかかる。銀の弾丸は無い。
JSのasyncはworkerには投げられない。Promiseベースのworkerへの割り振りは単純にはならない(できない)。
async/awaitをなんとかしようとすると例外のためにスタックを持ち回る必要がある。
そしてclusterはマルチプロセス。
もしかしてnodeもエアプなの？ >>907
その方針がRustのダメなところだという話だよ。goは一応"Build fast, reliable, and efficient software at scale"というコンセプトからはあんまり外れていない。
Rustはメモリ安全性が最大のコンセプトなのに、メモリ安全性から外れる部分をカバーしない方針はコンセプトと矛盾している。 >>909
何が問題なのかその文章からはわからないから明確に述べてほしい
RustはC++の方針の失敗を反面教師として上手く機能している
Goの良さはもちろん承知しているがRust視点から見ればGoは言語機能が貧弱なのに巨大なランタイムでGCもあり互いに真逆の立ち位置にいるわけだから >>904
最新のプログラミングをしたい/学びたい層にはGoは駄目だが、
昨今の他言語は常に肥大化しているので、仕様の更新を潔く諦め、
(15年前のプログラミングパラダイムで良ければ、)
『ちょうどいいプログラミング言語』であるGoには一定の需要はあり続けるはず。
なら10年ごとに「ちょうどいいプログラミング言語シリーズ」として改訂していって欲しいところだが。
> 豊富な機能や複雑な機能を使いこなせない劣ったプログラマー
これはわざとだろうがちょっと悪意が酷すぎる。
というか最近の若い奴はどうやら「全機能を使う事＝使いこなす＝有能」と捉えてる感があるが、これは違う。
プログラミング言語はあくまでアプリケーションを作る道具なのだから、
自分が欲しい機能があればそれで十分で、それ以上は必要ないんだよ。 >>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派とは話が噛み合わないかも。 >>912
こういうわかってそうで全くわかってないレスは疲れるわ >>910
「Rustがメモリ安全をコンセプトとするなら、(メモリ安全から外れる)unsafeが必要になる事態を放置するべきではない」ということだよ。
最小ライブラリとかはあくまで開発方針で、コンセプトの根幹となるメモリ安全を犠牲にしてまで優先する話じゃないということ。優先順位付けが間違っている。
まぁ、スレ違いだからこれ以上続けないけど、そういうのを棚に上げてgoを攻撃するのはダサいと思うわ。 >>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は使い物になりません。 >>914
それはunsafeを理解していない
unsafeを悪だと勝手に思い込んでいるようだがそれは違っていてunsafeは必要不可欠なもの
まず言語に関係なく「unsafeな操作無しではほとんどの構造を書けないもしくは効率的に書けない」という当たり前の事実がある
そこでRustは「型やモジュールの内部にunsafeを閉じ込めて安全なインタフェースだけを外に出す」という戦略で出来た言語
したがって標準ライブラリか外部ライブラリかに関係なく両方とも
・それらが提供する型やモジュールの内部はunsafeが存在する(もちろんゼロの場合もある)
・それらが提供する型やモジュールの外部インタフェースは安全である(ことが求められる)
全てがこの原則で作られている
一方で従来の言語C/C++ではunsafeな操作がプログラム全体に散在してしまい安全性を保証できなかった >>912
RustはGoと異なり非同期タスクをスタックレスで実現している上に
RustはGoと同じくtry-catchを採用していないね >>916
だからスレ違いと言ってるだろ。
しかも「メモリ安全から外れるunsafeが必要になる事態を放置している」の反論になってないし(標準ライブラリで赤黒木とか二重リンクリストを持っている方が結果的にメモリ安全にしやすいのは変わらない)。
これ以上やるならRustスレにコメしてくれ。 >>918
それは君の理解不足
unsafeな操作はプログラミングをする際に絶対避けることはできないけど
それをできる限り小さな狭い範囲に閉じ込め、かつ、その外に影響をもたらさないように設計しよう、というのが根幹
次に、二重リンクリストも二分木もRustの標準ライブラリにある
もし万が一その仕様が気に入らないなら他のクレートを探すか自作すればよい
どこに不満があるのかすら君は言うことさえ出来ずに君はイチャモンを付けているだけ Rustスレでいつもホラ吹いてて隔離されてるやつだからさ
Go vs Rustみたいな隔離スレ立ててかまいたいやつだけが相手してやるといい >>919
同意
その点を彼は全く理解できてないんだよ
そして彼は>>914でも「unsafeが必要になる事態を放置するべきではない」とか意味不明な主張をしてる せっかく対処法教えてやったのに
ちなみにそいついつも一人二役で自分のレスに安価付けるからw >>925
俺が>>919で書いたことはRustも書くプログラマーにとっては基本的な常識なのでRustスレにおいては異論すら出ないため無意味だぜ
その基本的な常識を理解せずに間違ったRust批判をこのGoスレでする人がいたから説明したまで こんなおじさん昔はいなかったのにどこから湧いてきたんだろう そのおじさん昔からいるぞ
昔はコテハンも使ってたが相手にされなくなったてやめたみたい
Ruby君と並ぶ有名人 >>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
みたいなスレを作るとか Rust vs その他
みたいなスレにまとめてくれ >>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とは相性がいい。
（というか、だから当時は異端でしかない「非同期」を採用したのかもしれないが） 逆に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だとわきまえてて、ランタイムを自言語で書こうとかいう無駄な事をやってない。 > そして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から見れば卒倒しそうな仕様も、解の一つではあると見てる。 >>937
JavaScriptの非同期呼び出しでも普通は無視せずPromiseにcatch付けて捕獲するぜ
例: async_func_foo.catch(err => console.log(err))
あとRustの非同期呼び出しもResultが帰ってくるからエラーを捕獲できる Goを叩く為にJavaScriptを使ってるだけで、JavaScriptの理解度かなり浅いなこのおじさん。
しかしこんなおじさんがずっと暴れてんのか、全然議論できないじゃん。対策としてはワッチョイ導入くらいしか無いだろうね。 長い文章ダラダラ書く人ってプログラマーの素質ないよ
文章を短く簡潔に書ける人ってプログラムも同様に書ける >>938
> 例: async_func_foo.catch(err => console.log(err))
これは字が赤いか黒いかの違いしかないけどな。
まあ俺はtry-catch消極派だから、Go/Rust方式で問題なく、C#の仕様はオーバースペック過ぎるけど、
Goの場合はJSとは違ってtry-catchはそれなりに機能するはずだから、不満持ってる奴もそれなりにいるはずだけど。
（そういう連中は既に去ってる気もするが） 発想が違う、どの案件でも、その案件にとって1番だから使う、と言う言葉が伝わってないのか？
俺も十分、言外の言葉は理解できないタイプだが、流石に通じると思うんだが。
書きやすい、読みやすいからこれを選定した、と言うのは「1番」でしょ。
基本的にそういう書き方してると言うか、自然に書くとそうなる。これはドキュメントに書いてあっただろ。
非同期とマルチスレッドを分けて考えろよ…。
実際にはnodeもそうだけど、C#のTaskなんかに関してもめちゃくちゃ解像度甘いのでは？ goだと、非同期スタイルで書けるとかでなくて、ブロッキング関数、同期関数を書いたとしてもgoroutine間では適切にスイッチングされて、他の言語で言うawaitがかかってるんよ。常に低コストで。
それはN:M軽量スレッドだからなし得ることなので、他の言語ができてない以上何とも比べづらい。 ローニンでワッチョイ消してるやつ正規表現で弾けばええやん >>943
> ブロッキング関数、同期関数を書いたとしてもgoroutine間では適切にスイッチングされて、他の言語で言うawaitがかかってるんよ。
これは普通はマルチスレッドと言う。Thread/goroutineを複数（マルチ）起動して引っかかったらスイッチングさせるだけなのだから。
そして大概の言語はこれを自然に書けるようになってる。
> それはN:M軽量スレッドだからなし得ることなので、他の言語ができてない以上
これが嘘、というか誤解。他言語でもいくらでもスレッドを起動する事は出来る。（が余計に重くなるので普通はやらない）
goroutineもGo信者が言う程軽くもないのでいくらでも起動していいわけではない。(現実的には)
これを脳死でgoroutineはコストゼロ、だからgoroutineに切り出す事がプログラマの仕事である、と解釈できれば美しいのだが、
これを実際に試して「思ってたよりも全然パフォーマンスが出ねぇ、これならNodeの方が速ぇ…」となった顛末を書いてたのが何度も言ってるブログ。
これは言語と言うよりはランタイムの問題だけど。 JSのPromiseは非同期の扱いとしてはかなり好き >>949
N:Mのグリーンスレッドであって単なるマルチスレッドじゃない。
単に引っかかったら切り替えるんでなくてスティーリングまでやるのは他の言語の言語標準機能にはErlangぐらいにしかない。
どこが嘘なんよ。
コストゼロでは無いが、いわゆるスレッドよりは遥かに軽いぞ。 わからせようとするのが無駄だって何で気づかないかな >>940
論理構成がしっかりしてて読みやすければ長文でもいいんだけどね
このおじさんはそこが壊滅的だから明らかに素質ないわな 抽象化できず同じ事何回も書く傾向にあるから、凄いコード書きそう >>955
というか、
短い=良い
もしくは
simple=beautiful
というセンスが欠落している。
あんな汚い長文ぞっとするわw
まあ.{50}でNGにしてるけど Goの(疑似スレッド＋)goroutineのパフォーマンス計測っていいやつないの？
↓見つけたやつ
Goroutines Are Not Significantly Smaller Than Threads
https://matklad.github.io//2021/03/12/goroutines-are-not-significantly-smaller-than-threads.html Goってぶっちゃけ言語機能とか割とどうでもよくて、
・ビルドやデプロイや運用がシンプル
・本家の開発体制が保守的で、長期的に安定したサポートが期待できる
という点がメリット
極力作りっぱなしで放置したい類のものに向いてると思うんだよね
Goしかできない奴やGo大好きで使ってる奴もまずいないだろうし、こんなもん執拗に叩いて何がしたいの CLIツールはともかく一番使われてるWeb APIは放置したいものとは対極だろう APIはむしろどっちかというと放置したい系じゃね？
フロントと表裏一体みたいなのもあるけど、そういうのにGoはあまり採用されないでしょ 確かにそうだな。わかろうとしないし、伝わらない気がしてきた。
Rust最高とRustスレで言っててくれれば良いか。
>>958
これはあるよね。
1つ前のバージョンどころか、それなりに昔のGoのプログラムですら修正せずにコンパイルできる。 >>951
やってないのはやる必要がないから。
他言語も馬鹿ではないので、改善の努力はしてるし、いい点があったら平気でパクってる。
(Goはgreenthreadで全て解決！と謳っているわけではないけども、そうだとしたら）
そのアイデアは面白かったが、現実的ではなかった。
（ただしこれはランタイムの問題だから改善の余地はあるはず）
非同期はコードがうざくなるのは事実だが、async文法でほぼ払拭された。
だからみんなパクってる。
まあ完全にループだし、材料枯渇でここら辺で終わりかな。
そりゃ信者の念仏を何度聞いても翻意する事はないよ。俺は文系ではないし。
こちらの見解では説明出来ないデータが出て来たら、分析して、考えを修正するけど。
>>957
virtualの40MBを単純に合算したら、今は4倍軽くて、4k/goroutine時代は2.5倍軽かったという事か。
フットプリントだけの比較ではあるが。
だから極めて単純に言えば、他言語のスレッドでジョブを4つずつ束ねて処理する運用をすれば、
フットプリントでは並んで、速度は余分なスケジューラが入ってない分勝てる事になる。 >>960
そりゃWebのフロントエンドに比べりゃなんだって放置したい系になるだろ
Webの場合はバックエンドでもWebフレームワークをサポートバージョンに維持する必要があるから
長くても3〜5年すればコードを変更することになる >>958
言語機能は本当に20世紀に設計された言語なのかと
疑いたくなるね
ほぼGCがあるCを書いてる感覚に近い
C書けない人が書ける言語じゃないと思う >>962
はい、じゃあ言質も取れたのでRustスレに戻って下さいね >>963
そうか？コアAPIに関してはあんまり手を入れないけどな。
Webフレームワーク次第なAPIってどんなの？ >>966
SPAのすぐ裏でUIの要件に合わせて作るようなやつのことじゃね？
そういうのはそもそもGoを採用しないと>>960で書いた通りだ >>967
なるほど。BFF的なやつ。
たしかにGoで書くまでもないし、ノンコーディングもあるよね。 正直なんだかんだ言って、学習コストに対しての性能パフォーマンスが異様に高いというところがGoの魅力
言語仕様がコンパクトだからミスしにくい(気がする)のも良い
チャネルに容量があることを忘れるうっかりさん以外には
得意な機能は限られててGUIとかは苦手だけど、そんなもんC#やらに任せとけばいいや 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++"つって作っただからそらもうみんな嬉しいやろ 結局>>957よりいいパフォーマンス計測ってないのかー
個人的感想としては。。。
パフォーマンスについて特筆すべき利点はない
原理的にスレッドプールを使った他言語のコードと同程度の性能が出る
機能的な利点はグリーンスレッドを言語で持っており、自動でOSスレッドと使い分けられる点(記述量低＆必要メモリ低)
逆に欠点はスケジュールをコントロールする方法がGOMAXPROCS以外ない点ってところかな >>971
優先度がないのはちょっぴり残念ではある
…ないよね？ >>969
> 学習コストに対しての性能パフォーマンスが異様に高い
Cの方が高いけどな。Goよりも小さい仕様で速い。
あとC#もGUIはゴミだぞ。それ以外がいいからunityを制覇してるが。 >>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モデル[ワークスティーリング方式] >>974
それ以下と定義が同じだと、一般的には「ワークスティーリング方式」を「スレッドプール」と呼称するよ。（だからC#のもこれのはずだけど）
https://tech-blog.optim.co.jp/entry/2019/11/08/163000
Rustで何故あえて方言にしているのかは知らん。
というかワークスティーリングじゃない方のメリットなんてない気がするんだが。 >RustもGoと同じM:Nモデルでワークスティーリングもしているよ
VMじゃないのにどうやって実現してるのかな >>975
RustはGoと真逆で標準ライブラリとは最小限のものに限る位置付けなので
標準ライブラリには非同期ランタイムを作るための枠組みだけが存在していてランタイム自体は無しだよ
これは全ての分野について同じ方針でRustでは標準＋準標準(デファクトスタンダード)を使ってプログラミングをするよ >>976
そこは一般的は話としてまずOSスレッド毎にキューと持つかグローバルにキューを持って割り振るかの2大方式があるよ
それぞれに利点と欠点があってそこは省略するけど
GoもRustもそのハイブリッド方式となっていて普段はスレッド毎にキューを持って各OSスレッドが独立に効率よく処理だね
そしてGoもRustもグローバルにも管理して暇なOSスレッドが生じるとそこへ割り振る(OSスレッドから見るとスティール)するよ
詳細はここで書ききれないほどもう少し複雑だから省略してる点はそれぞれの解説サイトなどを見てね >>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は基本そうじゃないだろうから、チューニングミスだと思うけど。 Goは別に最速を目指している言語じゃないからね
もし何かのベンチマークが最速になってしまったら逆に驚くよ
そのベンチ間違ってるだろ、って。 >>977
VMじゃないと起きる問題点は何？
いずれにせよC/C++/RustはVMでもOSでも記述できるのだからそこに不可能は無い
>>980
言語に関係なくシステムスレッド間のグローバルな操作はデータ競合回避など一定のコストがかかる
だから可能な限り個別にシステムスレッドが動くようにしつつアイドルが出ないよう最小限のグローバル操作
この部分はよほど上位で制約のある仕様としていないならば全ての言語で同じ >>978
これがなぁ…。過渡期は混ぜるな危険で困らない？そこが不安。
Rustも良いとは思うんだけど、爪切るのにハサミ使ってる気分になる。 >>982
それはハードによる。
x86はハードウェアでキャッシュコヒーレンシを取ってくれるので実は共有RAMでもコストは安い。
.NETがローカルキューからの取り出しでFIFOとFILOで競合が減るから、というのはそういう事。
Goの場合はARMを見てるのか、MacがARMに乗り換える布石だったのか、
以前からやたら「共有RAMは遅いから使わない」としてきてるが、
ぶっちゃけx86の場合は
（書き込み頻度と量によるが、タスクの起動＝関数ポインタ１つと引数のポインタ程度なら）
OSを利用したチャネル接続よりも共有RAMの方が実は速い。
ここら辺を理解してない奴がグダグダやってるからチューニングし切れてないのだと思うよ。 >>980
>> Goみたいに100,000goroutineとか目指す場合は分かるけど、Rustは基本そうじゃないだろうから、
Rustの非同期タスクはGoroutineよりも更に軽くて
Goとは異なりスタックレスなので付加メモリ消費も非同期ランタイムの管理データ分の1タスクあたり64bytesで済みますよ
そしてグローバルキュー競合コストの件は>>982のように同じですね >>982
問題があると言っているわけじゃなくて、VMやOSじゃなければプリエンプションできないからどうやっているのかなと。 >>973
Cはお爺ちゃんだから…
Cからの乗り換えコストっていう視点でどうかひとつ
あ、でも実装系別の頭おかしくなるコンパイルオプションやらバウンダリやらのメモリモデル考えると、Goのほうが実質勝ってないか学習コスト？ >>973
ちなみに速さやらサイズでは当然にCとかの圧勝だろ普通に
関数呼び出しごとにオーバーヘッドのかかるGoが単純な速度で勝てる道理はない >>973
C#というか.Netのwpfは好き
一般的な手法じゃないだろうけど、MVVMのVM部分を単体テストできて(ディスパッチャ細工してメインスレッドで走らせる) >>985
> Goとは異なりスタックレスなので
やたらこれを強調しているが、goでもgoroutineにローカルキュー（＝関数ポインタの配列）を用意して、順に食わせれば、
各タスク毎にスタックを用意する必要なんて無くて、普通にエミュレーション出来るよ。
(ただしGo信者的にはこれは負けだからやらないとも思うが）
ただこの場合、各タスクが止まらない前提ならこれでいいが、
止めて切り替える分には一般的にはスタック領域が必要になる。
(自動変数を全部ヒープ上に確保すればスタック無しでもいいが、これは遅くなるので多分やってないと思う)
ユーザーが確保しなくていいだけで、実際はランタイムかコンパイラが確保してくれてるだけじゃないか？ >>988
> 関数呼び出しごとにオーバーヘッドのかかるGo
かからないような気がするが、自信はない。かかる理由って何？ >>991
Goは関数呼び出しごとにスタックをチェックして、不足してたなら拡大するから
関数ごとの静的な自動変数サイズと比較してるだけだと思うけど、そういう処理のおかげで初期スタックサイズを抑えてる
https://postd.cc/performance-without-the-event-loop/ >>991
「十分な空間がない場合、ランタイムはヒープに対して大きなスタックセグメントを割り当て、現在のスタックの内容を新しいセグメントにコピーし、古いセグメントを解放し、それから関数呼び出しを再開します。」 >>991
毎回拡張する訳じゃないけどそのためのチェックは毎回走るんで、単にサブルーチンを呼ぶだけの他言語よりは余分な仕事をしている
おそらくチェックは必要な回数だけだとは思う(ループ内での呼び出しとかの最適化は考えてないとは思わないから) compiler explorer(https://godbolt.org/)で、goコンパイル結果を普通のamd64用のアセンブラ見ること出来ないの？(Plan9でなく) >>990
Rustの非同期タスクは内部的には単純な状態マシンとなり何度も再入可能なコルーチンと同じ状況になります
その中の変数はRustのクロージャがその環境の変数をキャプチャするのと同じだからもちろんメモリを確保します
だからスタックレスで何度も呼べるクロージャみたいな状況でスタック自体はプロセス全体で1本のままとなります
もちろんその非同期タスクから他の非同期でない普通の関数を呼べば通常と同じくスタックが伸びて使われていきます
一方でその非同期タスクから他の非同期な関数を呼ぶとその非同期タスクから一旦離脱してスケジューラーへ戻ります
最初に書いたように「単純な状態マシンとなり何度も再入可能なコルーチン」となっているので再び再開できます
以上がスタックレスなのにRustの非同期タスクがメモリの許す限り多く動くことができる仕組みです 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もデカい このスレッドは１０００を超えました。
新しいスレッドを立ててください。
life time: 468日 4時間 2分 1秒 5ちゃんねるの運営はプレミアム会員の皆さまに支えられています。
運営にご協力お願いいたします。
───────────────────
《プレミアム会員の主な特典》
★ 5ちゃんねる専用ブラウザからの広告除去
★ 5ちゃんねるの過去ログを取得
★ 書き込み規制の緩和
───────────────────
会員登録には個人情報は一切必要ありません。
月300円から匿名でご購入いただけます。
▼ プレミアム会員登録はこちら ▼
https://premium.5ch.net/
▼ 浪人ログインはこちら ▼
https://login.5ch.net/login.php レス数が1000を超えています。これ以上書き込みはできません。
