Go language part 6

Go language part 6 (70ﾚｽ)
上下前次 1-新

1(1): 05/20(火)23:10 ID:C5OyrGcX(1) AAS
Goについて扱うスレッドです。
GoはGoogleによって開発された言語です。

公式
外部ﾘﾝｸ:golang.org

公式ドキュメント
外部ﾘﾝｸ:golang.org

公式外パッケージドキュメント
外部ﾘﾝｸ:godoc.org

ブラウザ上で試し書き
外部ﾘﾝｸ:play.golang.org
省3

2: 05/21(水)10:10 ID:va6/rMba(1) AAS
>>1
O2

3: 05/28(水)04:54 ID:ZTLYIgKF(1) AAS
つるつるわれめつるつるわれめ

4: 05/28(水)08:11 ID:S8gLFyNo(1) AAS
安定してるなぁ

5: 06/02(月)15:52 ID:fdx4Ir3H(1) AAS
なるほどわからん

err := example1()
a, err := example2() // OK
b, err := example2() // OK
// _, err := example2() // ダメー
// err := example1() // ダメー

6(2): 06/14(土)07:49 ID:B+lix1t6(1) AAS
Goって人気とか将来性のある言語だと思う？

7(1): 06/14(土)08:34 ID:BYlCuXj0(1) AAS
>6
マイクロソフト、TypeScriptのコンパイラなどをGo言語に移植することで10倍の処理速度に
外部ﾘﾝｸ[html]:www.publickey1.jp

C#やRustよりもGoが選ばれました。人気も将来性もめちゃくちゃありまーす＾＾

8: 06/14(土)10:43 ID:WiumTvVB(1) AAS
>>6
書いてないなら関係なくね？

9: 06/14(土)11:17 ID:dtGV1Vl4(1/2) AAS
もうどの言語が好きとかいう時代じゃないからねパフォーマンスの改善を目的としたJSからの単純移植をAIにやらせるにはGoは適していることが証明された、それだけのこと

10: 06/14(土)12:09 ID:+l0S6cSK(1) AAS
これってAIによる移植なんか？

11: 06/14(土)12:43 ID:4ihnDgSn(1) AAS
AIによる移植でもなければJSからの移植でもない
基本的な認識が間違ってる、それだけのこと

12: 06/14(土)13:13 ID:/OxuSDvW(1/10) AAS
> 性能向上の要因の半分はネイティブコード化によるものであり、残りの半分は並行処理の利用によるものだとしました。
つまりネイティブ化と並行で3.31倍ずつ
技術的にはそりゃそうだろで凄くはない

13(1): 06/14(土)15:21 ID:lU2qZKzs(1) AAS
当たり前のことを当たり前にやるのが大切なんでしょ

14: 06/14(土)17:10 ID:IqWN5A4e(1) AAS
RailsとLaravel一筋だった3年目ですがなんかGo(Gin)やることになりました
僕の未来は安泰ですか
ポインタでつまずきました

15: 06/14(土)17:46 ID:y4VinIhq(1) AAS
まずはプログラミング言語がキャリアの軸になっているステージを脱することが大切
幸いにもGoはわりと言語どうでもいい段階の人が多いので、ステップアップには良い環境だ

16(1): 06/14(土)17:50 ID:/OxuSDvW(2/10) AAS
>>13
それはその通りだが…

Rust: GC前提のコードからのポーティングは(多分)かなり手間
C++: 全部shared_ptrにすれば『ほぼ』いけるはずだが、『ほぼ』が許せないなら無理
　とはいえ、ビルドツールが多少リークしたところで大して問題ないが
C#: 2014年頃からネイティブも出来るようになったらしい

として、C#が落ちた(Goに負けた)理由は以下のどれだろう？

> すべてのプラットフォームで完全に最適化されたネイティブバイナリを生成できて、
> データレイアウトの細かな制御が可能で、
> ガベージコレクタによるメモリ管理が自動化され、
省4

17(1): 06/14(土)18:29 ID:R+Velb9Y(1) AAS
>>16
>C#: 2014年頃からネイティブも出来るようになったらしい
2014年は.NET NativeのPreviewリリースのことだな
そいつは今のAOTコンパイラとは全く別のもの
今のやつは2022年正式リリース

C#を選ばなかった理由
動画ﾘﾝｸ[YouTube]

18: 06/14(土)19:21 ID:tKqSzfGn(1) AAS
ポインタで躓くなら他の職種に行ったほうが幸せ
お前の周り、ライバルはみんな理解するぐらいの能力有してるから

19: 06/14(土)20:02 ID:/OxuSDvW(3/10) AAS
>>17
とりあえずその部分だけ見た

つまりC#はclassを多用するOOPがベースで、
元のJSのfunctionalに合わず、Goは逆に合ってるそうな

まあ納得の説明ではあるが、
OOPをウップス！と読むのか？(まあ単語としてはそうだが)
classesがplusses(って何ぞ？)に聞こえるので、字幕無いと厳しいなこれは
(ただ字幕は追従できてるので、俺の耳が悪いのも事実だが)

20(3): 06/14(土)21:14 ID:/OxuSDvW(4/10) AAS
ついでに13:16のwhy not Rust?も見てみたが、
cyclic structureが使えねえから、とか言ってるんだが、これってどうなんだ？

元がTS(JS)だから子が親を参照してるcyclicとかありまくりで、Rustだと苦労する、と言っている事自体には同意するが、
俺はそもそもcyclicが有用なことがない、という認識で、これは俺がC出身で、

「ヒャッハー、GCだぜ！！！
これまで(自分で寿命を管理しないといけない)Cでは出来なかった複雑怪奇な構造も楽勝だぜ！
ついに俺の真なる力が開放される時が来たぜ！」

と思って色々試したものの、俺的には寿命管理はどんなケースでも出来るし、Cでも全く問題ないとの結論になったから
ただNimの連中は同様に「Cでは出来ないような構造もー」とか言ってるので、Nimも確認しないと駄目かとは思ってた
今回ヘルズバーグは「スクラッチから作るのならRustにするが、ポーティングだからね」なので、
省6

21: 06/14(土)21:28 ID:/OxuSDvW(5/10) AAS
と思ったがTSの連中に聞くことにした
2chｽﾚ:tech

22(1): 06/14(土)21:29 ID:dtGV1Vl4(2/2) AAS
>>20
依存関係の循環じゃなくて参照の循環は普通にあるよ
例えば親コンポーネントがその上に乗っている子コンポーネントからの通知をコールバックで受け取るケースでは循環参照が発生する

23(1): 06/14(土)22:38 ID:GCb7U03w(1/2) AAS
>>20
「スクラッチから作るのならRustにする」なんて言ってないだろ
「Cyclicなんて無くても作れるし、スクラッチならそうするからRustで問題ない」なんてことも言ってない

勝手に脳内変換しちゃいかんよ

24: 06/14(土)22:43 ID:eLCz0XU2(1) AAS
組み込みはメモリー周りが厳しいのでRust一択ですよね

25(1): 06/14(土)22:51 ID:GCb7U03w(2/2) AAS
>>20
cyclic data structureの例はwhy not Rust?のところで説明しとるやろがい

AST with both child and parent pointers
symbols -> decorations -> AST -> reference back to symbols

循環参照のメモリ管理を自動でやってくれる言語の場合は
親子の相互参照みたいなのを特殊な状況を除くと何も気にせず作れる
特別な手順を踏む必要がないだけでなくモデルと実装が乖離しない
CやRustではそうはいかない

26(2): 06/14(土)22:56 ID:/OxuSDvW(6/10) AAS
>>22
そこは整理しないといけないと思う（といっても俺はRustは詳しくないが)

・単なる循環参照(親→子→親で、まとめて廃棄可能＝寿命が同一のオブジェクト間の相互参照…Rustでも楽勝)
・寿命がバラバラのオブジェクト同士の複雑な相互参照(…Rustで無理なのは多分これ)

コールバックの結果に「親」も含めて返し、子としては自分でも参照できるようにしておく、
つまりxhr/fetchで {requester: parent, response: Response} で返せば循環参照自体は発生するが、
基本的にこの手のResponseは各所に回覧して終わり、
必要なら各自コピーとっとけ、で、回覧修了後に廃棄、で何も問題ない
だから前者であって、後者の「Rustで苦労するタイプの『循環参照』」にはならない

Rustで対応無理なのは、Rustの性質上、(ここらへんからだいぶ間違いが入るかもだが)
省9

27(1): 06/14(土)22:56 ID:/OxuSDvW(7/10) AAS
ただ、この辺、単純にAとBの両方より確実に寿命の長いCを定義し、
C->Response
として、Cの廃棄でResponseも廃棄させればいいだけで。
(この書き方では意味不明だが、単純には、ただの入れ子で
func C(Response){ // C:関数ローカルのスコープ
// A->Response としての処理
// B->Response としての処理
} // func 終了タイミングでResponseを破棄してもA->ResponseとB->Responseの処理は終わってるので問題なし
と、要するに、寿命を強制的に入れ子にするだけ)
俺的に、
省14

28(1): 06/14(土)23:10 ID:0RGMG9ga(1) AAS
>>27
回避可能か不可能かの問題ではない
移植にあたっては、絶対に既存の挙動を変えないために、一行一行単位の逐次翻訳を行なっている
Rustでそれができると思うならアンダース氏に凸撃してきたらいい

29: 06/14(土)23:21 ID:/OxuSDvW(8/10) AAS
>>23
ああ確かにRustで駄目な理由を述べてるだけで、Rustにするとは言ってないな
不用意に信者を召喚してしまう発言は申し訳なかった
(が、まあ、そこは本筋ではない)

>>25
そこはそう言ってるが、ASTなんてただの木構造だし、相互に複雑に参照されたところで、寿命は同一だろ
(＝その中のオブジェクトの全てはソースコードの寿命と同じ)
だから全く問題にならない
全部のオブジェクトをルート点の寿命で管理すればいいだけだし、何ならこれはただのグローバルだろ
C++的に参照カウンタで管理した場合は無駄にクソ遅くなるが、これはGCなGoでも同じ
省13

30: 06/14(土)23:35 ID:/OxuSDvW(9/10) AAS
>>28
> 移植にあたっては、絶対に既存の挙動を変えないために、一行一行単位の逐次翻訳を行なっている
これなら納得だが、なら最初からそう言えよヘルズバーグ、とは思う
ただまあ、「TSの方が型が多くて、enumのないGoでは‥」と似たようなことは言ってたが
(多分そもそもこの動画がTSer向けで、界隈の状況をある程度知ってる前提で、
俺みたいな門外漢が見る用には出来てないのだろう)

逐次変換するなら、機能的にスーパーセットでないと厳しいので、Rustは論外、Cもまあ無理、
C++は多分行けるはず、C#もおそらく可能、でもGoが一番マシ、というのは分かるかも
(しかし厳密に逐次変換を目指すなら《無駄に全部入りの》C++が常道だとも思うが)

31(1): 06/14(土)23:43 ID:v07AL1EI(1) AAS
>>7
それは特殊なケースだから一般的にGoを採用する理由にはならない

今回は正確には移植による言語移行ではない
約5万行のchecker.tsで実装されていてそのままTSのCompiler API として公開されていてこれも維持を継続しなければならない
それに加えて並行して別言語によるスピードアップを叶えることが目的
つまりTSと別言語のソースコード二重管理となる負荷を最も下げられることが最重要という特殊な条件がある

C#ではクラスベースとなるためTSから大きく書き換える必要性から条件に合わない
CやRustはその点では問題ないがGCに任せている部分を新たに対応することになるため条件に合わない
そこで今回の条件ではたまたまGoが合致して採用に至っている

もし単なる移植ならば設定から見直し効率よくRustで書けばもっとスピードアップできたであろう

32: 06/14(土)23:54 ID:/OxuSDvW(10/10) AAS
>>31
> つまりTSと別言語のソースコード二重管理となる負荷を最も下げられることが最重要という特殊な条件がある
無いぞ
ブログの方見れば分かるが、
外部ﾘﾝｸ:devblogs.microsoft.com
JSはTS6.xで止め、TS7.0はGo、の予定だ
(JSベースのTS7.x系が出る予定はない)

そしてRust信者は死ね

33: 06/14(土)23:57 ID:tHMbF/HF(1) AAS
元のTSコードと合わせる必要がないならC#でも問題ないよ
だからGoにする必要がない

34: 06/14(土)23:59 ID:V6t1FI0l(1) AAS
>>26
Rustでもアリーナ管理すればよいため循環があろうと大丈夫だよ

35(1): 06/15(日)00:24 ID:lIZk6VUi(1) AAS
>>26
>単なる循環参照(親→子→親で、まとめて廃棄可能＝寿命が同一のオブジェクト間の相互参照…Rustでも楽勝)
親→子→親の構造を表現するためにはRc/RefCell/WeakRefの組み合わせみたいなのが必須
何も気にせず全自動でやってくれる言語と比べれば相当面倒くさいよ
要は前者でも後者でも基本同じ

>A->Response
>B->Response
これがAがResponseを参照している、BがResponseを参照しているの意味なら
AやBより先に他の誰かがResponseを生成して所有しているはずで
その誰かはAやBより長生きするんだから何の問題もないよ
省1

36: 06/15(日)00:53 ID:PrFSErxS(1) AAS
TSで循環定義が書けるからコンパイラも同じ構造のまま扱いたいだけでは

37(1): 06/15(日)01:14 ID:757F+le4(1/5) AAS
>>35
> 親→子→親の構造を表現するためにはRc/RefCell/WeakRefの組み合わせみたいなのが必須
それがarenaで簡単になるらしいぞ、詳しくは知らんが

> これがAがResponseを参照している、BがResponseを参照しているの意味なら
そうだが、
> AやBより先に他の誰かがResponseを生成して所有しているはずで
これはその下のCの話になってる

問題が起きるケースは、
A->Response のオブジェクトAがあり、
オブジェクトBにもResponseの参照が欲しくなったので、B->Responseをつけようとするが、
省14

38: 06/15(日)01:41 ID:757F+le4(2/5) AAS
>>37、例を修正、
(まあ俺がRustに詳しいわけではないからコンセプトだけだが、)

function add_ref(Response, A, B){ // Response,A,Bはすべて所有権を与えられるとする
A.Response = Response; // この辺が書けない
B.Response = Response; // この辺が書けない
return [A,B]; // 2値返し、A,Bのどちらが長寿命かはわからない
}

かな。Responseが与えられ、A,Bにそれぞれ参照を付加するだけだが、
Responseオブジェクトの寿命(所有権？)をどちらに与えればよいか分からない
だからまるごと管理してしまえってのがCなりarenaなのだろうし、
省2

39(1): 06/15(日)03:34 ID:r3H8nvWy(1/4) AAS
コンパイラというのは数少ないGC有りのほうが有利な分野
全力で駆け抜けて終了するまでに一度もコンパクションが発生しなければメモリ管理のコストを丸ごと踏み倒せてGC無し言語よりも速くなる

40(1): 06/15(日)03:49 ID:7JDJ5spc(1) AAS
>>39
それは初心者がよくする勘違い
GC言語は常に不利で遅くなる

41(2): 06/15(日)03:57 ID:r3H8nvWy(2/4) AAS
>>40
そんなことはない。ヒープの構造はGCのほうがコンパクションを前提にできるのでシンプルで割り当ても速いし
手動で解放があることを前提とした前処理も不要になる
C言語でも同タイプの用途には特化したプールを用意して一切解放を行わない最適化戦略は行われる

42(1): 06/15(日)04:03 ID:sHWxg8n8(1/2) AAS
GCしなくてもGC言語が遅い
だから速いコンパイラはGC言語で書かれていない

43: 06/15(日)04:08 ID:r3H8nvWy(3/4) AAS
>>42
既存のGC有り言語は大抵他の凝った機能を備えていてそのペナルティが大きい
JITは勿論、Goならゴルーチン、Haskellなら辞書によるディスパッチ、OCamlなら値の1ビットをタグにしてる
D言語は保守的GCなのでGC特有の最適化が充分にできない等
純粋にGC有りC言語として評価できる言語は実はあんまりない

44: 06/15(日)04:22 ID:r3H8nvWy(4/4) AAS
だから大抵の場合GC部分のみの評価になってない
(もちろんこれらの言語はそうした機能のお陰で保守性良く改良ペースが上がり結果速度向上になる場合もあるので悪いことばかりではない)

あとgoやdmdはC言語で書かれたコンパイラと比べても充分速いと思うけどね

45(1): 06/15(日)04:38 ID:sHWxg8n8(2/2) AAS
Goが必ず遅い

46(1): 06/15(日)04:44 ID:ZyRwwozc(1) AAS
>>45
横だけどGC言語が速い例(ただしJVM系はpeak-memとのバランスが悪い)
外部ﾘﾝｸ:programming-language-benchmarks.vercel.app

47(1): 06/15(日)05:43 ID:8ok6jSUv(1) AAS
Goが5倍も遅いのはなぜ？
まともなベンチに見えない

48: 06/15(日)06:29 ID:gNMJii7n(1) AAS
まともなベンチマークでGC言語が速い例は存在しないからね

49(1): 06/15(日)06:46 ID:757F+le4(3/5) AAS
>>41
> 手動で解放があることを前提とした前処理
とは何ぞ？
仕様的に、何もしなくていいと分かりきってるのなら、本当に何もしないCがどう考えても一番速い

多分お前が言ってるのは、「GCヒープに対して、手動で開放があるオブジェクトを割り当てる場合、『前処理が必要になる』」ということなのだろうが、
それはVC++のように、マネージドヒープ(=GCされるヒープ=CLR側のヒープ)と
アンマネージドヒープ(GCされないヒープ=C++側のヒープ)を明示的に分離してしまえば、実行時の『前処理』等のコストは不要となる

50(1): 06/15(日)08:34 ID:757F+le4(4/5) AAS
>>41
ところでGoは生ポなのでコンパクションは出来ないだろ

コンパクションありのGCは、フラグメンテーションを気にする必要がないので、割り当て自体は速いが、
**pになるのでpのアクセスが無駄に遅くなる
対してコンパクション無しのGCは、最低限サイズ毎の分別は必要なので、割り当て自体は多少遅くなるが、
*pでアクセス出来るので、使用時はCと同速度になる

だから、GCと一括りはまずくて、

コンパクション無しのGC: Go
コンパクションありのGC: C#/Java、多分その他もほぼこっち

と別扱いにしないといけないと思うが
省3

51(1): 06/15(日)09:11 ID:vsQD4t+X(1/2) AAS
RustもGoも詳しくないけど、これらの言語にもRails や Django みたいなフルスタックのフレームワークってあるの？

52(1): 06/15(日)10:28 ID:ujM9EzWd(1) AAS
>>50
それは間違い
GCのコンパクションは移動対象となるオブジェクトに対する全てのオブジェクト参照のアドレスを直接更新する

>>51
あるが一般的ではない
RustやGoはバックエンドに徹し、HTMLの生成(レンダリング)はNext.jsなど別のサービスが行うのが普通

53: 06/15(日)11:42 ID:757F+le4(5/5) AAS
>>52
> GCのコンパクションは移動対象となるオブジェクトに対する全てのオブジェクト参照のアドレスを直接更新する
それはそれで凄いが、
それだとコピーの際に「参照カウンタ＋１」のみならず「コピー先アドレスも控えておく」必要があるので、コピーが重くなる
だから結局、GC方式が異なるので一緒くたには出来ないのは変わらない
まあ各者でそれぞれ一番速いと思ってる方式を採用してはいるのだろうけどね

54(1): 06/15(日)12:31 ID:aUao3Hkb(1) AAS
>>47
GC戦略の違いだよ
RustやC++もArena使って別途手動管理しないとGC言語より遅くなる典型例

55(1): 06/15(日)12:43 ID:HdrNQych(1) AAS
>>54
逆
管理を楽にするためにArenaを使う
もちろん速度も上がる

56: 06/15(日)13:57 ID:nsaCurRA(1) AAS
ﾜｯﾁｮｲの無いスレでRustの話するとすぐこれだ

57(1): 06/15(日)17:27 ID:dAJ+nMeh(1) AAS
>>46(Input depth: 18)のarena version

zig 0.55 (arena)
go 0.58 (arena)
v 0.75
go 1.59
zig 2.78

58: 06/15(日)18:20 ID:lEreEG4E(1) AAS
>>55
何の逆だよ
まさかArenaは”自動管理”とか言わないよね？

>管理を楽にするためにArenaを使う
それは比べる対象を間違えてるでしょ

59(1): 06/15(日)18:48 ID:/MYgDLVa(1) AAS
アリーナ使うと管理が楽になるのは事実
ライフタイムが統一されてめちゃ楽

60: 06/15(日)21:07 ID:vsQD4t+X(2/2) AAS
それはRust特有の事情でしかなくない？

61: 06/15(日)21:27 ID:neMcJSIx(1) AAS
同じ
arenaはownerを一本化できるためshared_ptrやRc管理をなくせて楽

62: 06/15(日)23:28 ID:woCxiWNy(1) AAS
>>59
手動リファレンスカウンティングと手動アリーナ管理を比べられてもね
Goのアリーナ使うコードと使わないコードでも比べたら？

63: 06/15(日)23:38 ID:LkTvbUTI(1) AAS
C++とRustにとってはArenaを使うと管理が楽で高速化されて良いこと尽くし
Goは手間増大か

64(1): 06/16(月)01:19 ID:vcrz/bj1(1) AAS
>>49
mallocひとつとっても解放のために確保時点でヘッダーを構成しないといけない
それに根っこから染み付いてて意識してないだろうが、きちんと後で解放できるような構造を取らなくていいならできる最適化は意外と多い

65: 06/16(月)07:43 ID:ZGVdfSpP(1/2) AAS
>>64
まず俺は40ではない(そしてGo使いでもない)
> mallocひとつとっても解放のために確保時点でヘッダーを構成しないといけない
最低限空き領域リンクリストを構成する必要があるが、
遅いのはヘッダ整備O(1)ではなく、空き領域スキャンO(n)だと思う(が、まあこれはいい)
> C言語でも同タイプの用途には特化したプールを用意して一切解放を行わない最適化戦略は行われる (41)
OOPは各オブジェクト毎にちまちまmalloc/freeしてるから遅い
プールの場合にはこれが1回で済む、ここまではいい

そして
> それに根っこから染み付いてて意識してないだろうが、きちんと後で解放できるような構造を取らなくていいならできる最適化は意外と多い
省3

66: 06/16(月)09:14 ID:ZCbjnjWl(1) AAS
>>57続き
java 0.32s 40MB graal
java 0.44s 202MB
zig 0.55s 16MB arena
go 0.58s 25MB arena

67(3): 06/16(月)20:51 ID:GI5I1Imf(1) AAS
>そしてGo使いでもない
なんでこのスレを覗いてるんですかね…？

68: 06/16(月)21:29 ID:ZGVdfSpP(2/2) AAS
>>67
お前みたいな馬鹿ではないから

69: 07/14(月)16:18 ID:ScqQ9XOL(1) AAS
>>67
使ってない言語見てもいいだろうに。

70: 07/25(金)02:43 ID:STYBTcxW(1) AAS
>>67
現実では誰も相手にしてくれない嫌われてるおじだからどこにでも顔突っ込んで荒らすのかわいい街の寂しい存在www

上下前次 1-新書関写板覧索設栞歴

ｽﾚ情報赤ﾚｽ抽出画像ﾚｽ抽出歴の未読ｽﾚ AAｻﾑﾈｲﾙ

ぬこの手ぬこTOP 0.028s