Go language part 6 (70ﾚｽ)

Go language part 6 http://mevius.5ch.net/test/read.cgi/tech/1747750228/

上下前次1-新
通常表示 512ﾊﾞｲﾄ分割 ﾚｽ栞
抽出解除 必死ﾁｪｯｶｰ(本家) (べ) 自ID ﾚｽ栞 あぼーん

---

ﾘﾛｰﾄﾞ規制です｡10分ほどで解除するので､他のﾌﾞﾗｳｻﾞへ避難してください｡

---

12: デフォルトの名無しさん [sage] 2025/06/14(土) 13:13:38.94 ID:/OxuSDvW > 性能向上の要因の半分はネイティブコード化によるものであり、残りの半分は並行処理の利用によるものだとしました。 つまりネイティブ化と並行で3.31倍ずつ 技術的にはそりゃそうだろで凄くはない http://mevius.5ch.net/test/read.cgi/tech/1747750228/12

16: デフォルトの名無しさん [sage] 2025/06/14(土) 17:50:53.17 ID:/OxuSDvW >>13 それはその通りだが… Rust: GC前提のコードからのポーティングは(多分)かなり手間 C++: 全部shared_ptrにすれば『ほぼ』いけるはずだが、『ほぼ』が許せないなら無理 　とはいえ、ビルドツールが多少リークしたところで大して問題ないが C#: 2014年頃からネイティブも出来るようになったらしい として、C#が落ちた(Goに負けた)理由は以下のどれだろう？ > すべてのプラットフォームで完全に最適化されたネイティブバイナリを生成できて、 > データレイアウトの細かな制御が可能で、 > ガベージコレクタによるメモリ管理が自動化され、 > 優れた並列処理が可能 ちな、最後については、元がJS(TS)なのでソースコード上でスレッド間は完全分離してるから、C#でも大して問題ない つまり、この点について、JS->Go、JS->C#の移植は問題ないが、Go->JSの移植はgoroutine使いまくりの場合厳しいかも？ 俺的にはC#でよかったんじゃね？とは思う(まあGoでも特に問題ないが) http://mevius.5ch.net/test/read.cgi/tech/1747750228/16

19: デフォルトの名無しさん [sage] 2025/06/14(土) 20:02:28.20 ID:/OxuSDvW >>17 とりあえずその部分だけ見た つまりC#はclassを多用するOOPがベースで、 元のJSのfunctionalに合わず、Goは逆に合ってるそうな まあ納得の説明ではあるが、 OOPをウップス！と読むのか？(まあ単語としてはそうだが) classesがplusses(って何ぞ？)に聞こえるので、字幕無いと厳しいなこれは (ただ字幕は追従できてるので、俺の耳が悪いのも事実だが) http://mevius.5ch.net/test/read.cgi/tech/1747750228/19

20: デフォルトの名無しさん [sage] 2025/06/14(土) 21:14:48.29 ID:/OxuSDvW ついでに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ということなのだが、どういうケースでどういう選択でそうなったのか知りたい (つってもソースコード読めではあるが、知ってたらよろしく) http://mevius.5ch.net/test/read.cgi/tech/1747750228/20

21: デフォルトの名無しさん [sage] 2025/06/14(土) 21:28:21.25 ID:/OxuSDvW と思ったがTSの連中に聞くことにした https://mevius.5ch.net/test/read.cgi/tech/1640872622/376 http://mevius.5ch.net/test/read.cgi/tech/1747750228/21

26: デフォルトの名無しさん [sage] 2025/06/14(土) 22:56:09.38 ID:/OxuSDvW >>22 そこは整理しないといけないと思う（といっても俺はRustは詳しくないが) ・単なる循環参照(親→子→親で、まとめて廃棄可能＝寿命が同一のオブジェクト間の相互参照…Rustでも楽勝) ・寿命がバラバラのオブジェクト同士の複雑な相互参照(…Rustで無理なのは多分これ) コールバックの結果に「親」も含めて返し、子としては自分でも参照できるようにしておく、 つまりxhr/fetchで {requester: parent, response: Response} で返せば循環参照自体は発生するが、 基本的にこの手のResponseは各所に回覧して終わり、 必要なら各自コピーとっとけ、で、回覧修了後に廃棄、で何も問題ない だから前者であって、後者の「Rustで苦労するタイプの『循環参照』」にはならない Rustで対応無理なのは、Rustの性質上、(ここらへんからだいぶ間違いが入るかもだが) ・誰が所有権を持ってるのか（＝そのローカルで誰が最長寿命なのか) ・誰が借りるのか（＝所有権保持者より短寿命) をソース上で確定させないといけないので、 A->Response B->Response とResponseを複数のオブジェクトから参照させる場合、AとBのどちらが寿命が長いか分からないと詰むし、 これらが複雑怪奇に相互参照してる場合、基本的に ・誰が最長寿命なのか(＝誰が所有権を持つべきか) が静的に確定してないと詰む、という事(だと思う) http://mevius.5ch.net/test/read.cgi/tech/1747750228/26

27: デフォルトの名無しさん [sage] 2025/06/14(土) 22:56:41.09 ID:/OxuSDvW ただ、この辺、単純に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を使えば大幅に手抜きが出来るケースがあるのか？という事 http://mevius.5ch.net/test/read.cgi/tech/1747750228/27

29: デフォルトの名無しさん [sage] 2025/06/14(土) 23:21:32.37 ID:/OxuSDvW >>23 ああ確かにRustで駄目な理由を述べてるだけで、Rustにするとは言ってないな 不用意に信者を召喚してしまう発言は申し訳なかった (が、まあ、そこは本筋ではない) >>25 そこはそう言ってるが、ASTなんてただの木構造だし、相互に複雑に参照されたところで、寿命は同一だろ (＝その中のオブジェクトの全てはソースコードの寿命と同じ) だから全く問題にならない 全部のオブジェクトをルート点の寿命で管理すればいいだけだし、何ならこれはただのグローバルだろ C++的に参照カウンタで管理した場合は無駄にクソ遅くなるが、これはGCなGoでも同じ Rust的に代入/参照する際にいちいち寿命管理しろと言われたら、手間が全く無駄なだけだが、グローバルにも出来たはず まあ最初からグローバルと分かりきってるなら、Cが一番楽ということになるが ソースコード(当然静的)を解析してASTを作りました、なら、 当たり前だが各オブジェクトはソースコードの寿命以上にはならないので、苦労することはないよ func somefunc(){ // ソースコード読み込み // AST木生成 // いろいろ処理 // AST木破棄 } にしかならんだろ 複雑な循環参照はそりゃあるのだろうが、問題になるのは、 『寿命の異なるオブジェクト間の』複雑な循環参照であってね、26のとおり http://mevius.5ch.net/test/read.cgi/tech/1747750228/29

30: デフォルトの名無しさん [sage] 2025/06/14(土) 23:35:56.94 ID:/OxuSDvW >>28 > 移植にあたっては、絶対に既存の挙動を変えないために、一行一行単位の逐次翻訳を行なっている これなら納得だが、なら最初からそう言えよヘルズバーグ、とは思う ただまあ、「TSの方が型が多くて、enumのないGoでは‥」と似たようなことは言ってたが (多分そもそもこの動画がTSer向けで、界隈の状況をある程度知ってる前提で、 俺みたいな門外漢が見る用には出来てないのだろう) 逐次変換するなら、機能的にスーパーセットでないと厳しいので、Rustは論外、Cもまあ無理、 C++は多分行けるはず、C#もおそらく可能、でもGoが一番マシ、というのは分かるかも (しかし厳密に逐次変換を目指すなら《無駄に全部入りの》C++が常道だとも思うが) http://mevius.5ch.net/test/read.cgi/tech/1747750228/30

32: デフォルトの名無しさん [sage] 2025/06/14(土) 23:54:18.51 ID:/OxuSDvW >>31 > つまりTSと別言語のソースコード二重管理となる負荷を最も下げられることが最重要という特殊な条件がある 無いぞ ブログの方見れば分かるが、 https://devblogs.microsoft.com/typescript/typescript-native-port/ JSはTS6.xで止め、TS7.0はGo、の予定だ (JSベースのTS7.x系が出る予定はない) そしてRust信者は死ね http://mevius.5ch.net/test/read.cgi/tech/1747750228/32

---

ﾒﾓ帳

(0/65535文字)

---

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

---

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

---

Google検索

Wikipedia

---

ぬこの手 ぬこTOP 0.014s