Go language part 6

**デフォルトの名無しさん** · 2025/05/20(火) 23:10:28.20

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

公式
https://golang.org

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

公式外パッケージドキュメント
https://godoc.org

ブラウザ上で試し書き
https://play.golang.org
※前スレ
Go language part 5
https://mevius.5ch.net/test/read.cgi/tech/1645915400/

**デフォルトの名無しさん** · 2025/05/21(水) 10:10:58.26

>>1
O2

**デフォルトの名無しさん** · 2025/05/28(水) 04:54:08.94

つるつるわれめつるつるわれめ

**デフォルトの名無しさん** · 2025/05/28(水) 08:11:47.00

安定してるなぁ

**デフォルトの名無しさん** · 2025/06/02(月) 15:52:23.57

なるほどわからん

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

**デフォルトの名無しさん** · 2025/06/14(土) 07:49:57.64

Goって人気とか将来性のある言語だと思う？

**デフォルトの名無しさん** · 2025/06/14(土) 08:34:58.82

>6
マイクロソフト、TypeScriptのコンパイラなどをGo言語に移植することで10倍の処理速度に
ttps://www.publickey1.jp/blog/25/typescriptgo10.html

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

**デフォルトの名無しさん** · 2025/06/14(土) 10:43:58.28

>>6
書いてないなら関係なくね？

**デフォルトの名無しさん** · 2025/06/14(土) 11:17:21.04

もうどの言語が好きとかいう時代じゃないからねパフォーマンスの改善を目的としたJSからの単純移植をAIにやらせるにはGoは適していることが証明された、それだけのこと

**デフォルトの名無しさん** · 2025/06/14(土) 12:09:42.28

これってAIによる移植なんか？

**デフォルトの名無しさん** · 2025/06/14(土) 12:43:28.73

AIによる移植でもなければJSからの移植でもない
基本的な認識が間違ってる、それだけのこと

**デフォルトの名無しさん** · 2025/06/14(土) 13:13:38.94

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

**デフォルトの名無しさん** · 2025/06/14(土) 15:21:50.33

当たり前のことを当たり前にやるのが大切なんでしょ

**デフォルトの名無しさん** · 2025/06/14(土) 17:10:26.41

RailsとLaravel一筋だった3年目ですがなんかGo(Gin)やることになりました
僕の未来は安泰ですか
ポインタでつまずきました

**デフォルトの名無しさん** · 2025/06/14(土) 17:46:49.96

まずはプログラミング言語がキャリアの軸になっているステージを脱することが大切
幸いにもGoはわりと言語どうでもいい段階の人が多いので、ステップアップには良い環境だ

**デフォルトの名無しさん** · 2025/06/14(土) 17:50:53.17

>>13
それはその通りだが…

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

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

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

ちな、最後については、元がJS(TS)なのでソースコード上でスレッド間は完全分離してるから、C#でも大して問題ない
つまり、この点について、JS->Go、JS->C#の移植は問題ないが、Go->JSの移植はgoroutine使いまくりの場合厳しいかも？
俺的にはC#でよかったんじゃね？とは思う(まあGoでも特に問題ないが)

**デフォルトの名無しさん** · 2025/06/14(土) 18:29:30.75

>>16
>C#: 2014年頃からネイティブも出来るようになったらしい
2014年は.NET NativeのPreviewリリースのことだな
そいつは今のAOTコンパイラとは全く別のもの
今のやつは2022年正式リリース

C#を選ばなかった理由
https://youtu.be/10qowKUW82U?t=1208

**デフォルトの名無しさん** · 2025/06/14(土) 19:21:06.66

ポインタで躓くなら他の職種に行ったほうが幸せ
お前の周り、ライバルはみんな理解するぐらいの能力有してるから

**デフォルトの名無しさん** · 2025/06/14(土) 20:02:28.20

>>17
とりあえずその部分だけ見た

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

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

**デフォルトの名無しさん** · 2025/06/14(土) 21:14:48.29

ついでに13:16のwhy not Rust?も見てみたが、
cyclic structureが使えねえから、とか言ってるんだが、これってどうなんだ？

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

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

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

・Cyclic(や出鱈目参照ありまくり構造)を許可すれば楽勝に組めるが、無しでは手間が増える

なケースなんて有るか？
まあこれが今回tscということなのだが、どういうケースでどういう選択でそうなったのか知りたい
(つってもソースコード読めではあるが、知ってたらよろしく)

**デフォルトの名無しさん** · 2025/06/14(土) 21:28:21.25

と思ったがTSの連中に聞くことにした
https://mevius.5ch.net/test/read.cgi/tech/1640872622/376

**デフォルトの名無しさん** · 2025/06/14(土) 21:29:08.75

>>20
依存関係の循環じゃなくて参照の循環は普通にあるよ
例えば親コンポーネントがその上に乗っている子コンポーネントからの通知をコールバックで受け取るケースでは循環参照が発生する

**デフォルトの名無しさん** · 2025/06/14(土) 22:38:33.86

>>20
「スクラッチから作るのならRustにする」なんて言ってないだろ
「Cyclicなんて無くても作れるし、スクラッチならそうするからRustで問題ない」なんてことも言ってない

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

**デフォルトの名無しさん** · 2025/06/14(土) 22:43:49.77

組み込みはメモリー周りが厳しいのでRust一択ですよね

**デフォルトの名無しさん** · 2025/06/14(土) 22:51:31.08

>>20
cyclic data structureの例はwhy not Rust?のところで説明しとるやろがい

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

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

**デフォルトの名無しさん** · 2025/06/14(土) 22:56:09.38

>>22
そこは整理しないといけないと思う（といっても俺はRustは詳しくないが)

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

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

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

・誰が所有権を持ってるのか（＝そのローカルで誰が最長寿命なのか)
・誰が借りるのか（＝所有権保持者より短寿命)

をソース上で確定させないといけないので、
A->Response
B->Response
とResponseを複数のオブジェクトから参照させる場合、AとBのどちらが寿命が長いか分からないと詰むし、
これらが複雑怪奇に相互参照してる場合、基本的に

・誰が最長寿命なのか(＝誰が所有権を持つべきか)

が静的に確定してないと詰む、という事(だと思う)

**デフォルトの名無しさん** · 2025/06/14(土) 22:56:41.09

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

・回覧方式で、回覧終了後に破棄する前提なので、必要なら各自コピー取れ
・寿命は入れ子で、最長寿命の親が一人居るから、それ以外の連中は寿命を気にする必要ない

のどちらかで対応できないケースはなく、どちらかにすることも大して難しくないので、Cで十分という結論になってる

この辺は原理的にも当たり前で、
変数自体の寿命が「どこかのローカルで入れ子」で、最外(=最長)が「グローバルでアプリと同じ寿命」なので、
変数に代入してる限り、代入されるオブジェクトもそれ以上の寿命になりようがない
だから代入してる時点で、「これまで代入(参照)された最長変数(オブジェクト)よりも寿命が長いか」が確定してれば
・長い場合→所有権を渡す
・短い場合→所有権を渡さない
と明示的にやるのがRustで、黙ってプログラマが勝手に管理しろ、というのがCであるだけ
だから代入(参照)時点で寿命が確定出来ない場合、Rustは詰むのだが、
原理的に、代入先(=変数/参照元)の寿命は確定してるから、これはない
結果、GCがないと現実的に無理なことは「存在しない」というのが俺の見方
ただtscはやりまくってるのだから、何かcyclicを使えば大幅に手抜きが出来るケースがあるのか？という事

**デフォルトの名無しさん** · 2025/06/14(土) 23:10:53.20

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

**デフォルトの名無しさん** · 2025/06/14(土) 23:21:32.37

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

>>25
そこはそう言ってるが、ASTなんてただの木構造だし、相互に複雑に参照されたところで、寿命は同一だろ
(＝その中のオブジェクトの全てはソースコードの寿命と同じ)
だから全く問題にならない
全部のオブジェクトをルート点の寿命で管理すればいいだけだし、何ならこれはただのグローバルだろ
C++的に参照カウンタで管理した場合は無駄にクソ遅くなるが、これはGCなGoでも同じ
Rust的に代入/参照する際にいちいち寿命管理しろと言われたら、手間が全く無駄なだけだが、グローバルにも出来たはず
まあ最初からグローバルと分かりきってるなら、Cが一番楽ということになるが

ソースコード(当然静的)を解析してASTを作りました、なら、
当たり前だが各オブジェクトはソースコードの寿命以上にはならないので、苦労することはないよ

func somefunc(){
// ソースコード読み込み
// AST木生成
// いろいろ処理
// AST木破棄
}

にしかならんだろ
複雑な循環参照はそりゃあるのだろうが、問題になるのは、
『寿命の異なるオブジェクト間の』複雑な循環参照であってね、26のとおり

**デフォルトの名無しさん** · 2025/06/14(土) 23:35:56.94

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

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

**デフォルトの名無しさん** · 2025/06/14(土) 23:43:33.04

>>7
それは特殊なケースだから一般的にGoを採用する理由にはならない

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

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

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

**デフォルトの名無しさん** · 2025/06/14(土) 23:54:18.51

>>31
> つまりTSと別言語のソースコード二重管理となる負荷を最も下げられることが最重要という特殊な条件がある
無いぞ
ブログの方見れば分かるが、
https://devblogs.microsoft.com/typescript/typescript-native-port/
JSはTS6.xで止め、TS7.0はGo、の予定だ
(JSベースのTS7.x系が出る予定はない)

そしてRust信者は死ね

**デフォルトの名無しさん** · 2025/06/14(土) 23:57:18.48

元のTSコードと合わせる必要がないならC#でも問題ないよ
だからGoにする必要がない

**デフォルトの名無しさん** · 2025/06/14(土) 23:59:27.91

>>26
Rustでもアリーナ管理すればよいため循環があろうと大丈夫だよ

**デフォルトの名無しさん** · 2025/06/15(日) 00:24:06.66

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

>A->Response
>B->Response
これがAがResponseを参照している、BがResponseを参照しているの意味なら
AやBより先に他の誰かがResponseを生成して所有しているはずで
その誰かはAやBより長生きするんだから何の問題もないよ
Rustだからといって面倒くさくなるパターンでもない

**デフォルトの名無しさん** · 2025/06/15(日) 00:53:43.71

TSで循環定義が書けるからコンパイラも同じ構造のまま扱いたいだけでは

**デフォルトの名無しさん** · 2025/06/15(日) 01:14:15.92

>>35
> 親→子→親の構造を表現するためにはRc/RefCell/WeakRefの組み合わせみたいなのが必須
それがarenaで簡単になるらしいぞ、詳しくは知らんが

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

問題が起きるケースは、
A->Response のオブジェクトAがあり、
オブジェクトBにもResponseの参照が欲しくなったので、B->Responseをつけようとするが、
この際に、元のAと追加するBのオブジェクトの寿命が別々に管理されており、どちらが長いか判断できない場合
だから上位なりで確実にAとBの寿命を内包する階層や
> 他の誰か
を作り、それで管理するという話

Rustのコードなんて書けんし、Goでも怪しいからJSで書いておくと、(この辺正確にしておかないと余計に混乱するだろうから)

function add_ref(A,B){
B.Response = A.Response;
return [A,B]; // 2値返し
}

とBにAのプロパティをコピーするだけのマヌケな関数で、AもBも所有権を渡された場合に、書きようがないだろ
だからおそらく上位でこういうことがないように対応するはずだが

ただ調べてたら Leakpocalypse が2015年に発見されて、それ以来「Rustではメモリリークは防げません」になってるようだな
まあ俺はRustは死ぬと見てるし、ザマアとしか思えないが
(Rustの方法でメモリ管理するのは無理だと思ってる)

**デフォルトの名無しさん** · 2025/06/15(日) 01:41:02.18

>>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なのだろうし、
無理やりでも個別に管理して1バイトも無駄にしない、というのがRc/RefCell/WeakRefで、
これを全自動でやってくれるのがGCなわけだが

**デフォルトの名無しさん** · 2025/06/15(日) 03:34:28.75

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

**デフォルトの名無しさん** · 2025/06/15(日) 03:49:42.94

>>39
それは初心者がよくする勘違い
GC言語は常に不利で遅くなる