Go language part 6 (68レス)
1-

1
(1): デフォルトの名無しさん [sage] 2025/05/20(火) 23:10:28.20 ID:C5OyrGcX(1) AAS
Goについて扱うスレッドです。
GoはGoogleによって開発された言語です。

公式
外部リンク:golang.org

公式ドキュメント
外部リンク:golang.org

公式外パッケージドキュメント
外部リンク:godoc.org

ブラウザ上で試し書き
外部リンク:play.golang.org
※前スレ
Go language part 5
2chスレ:tech
2: デフォルトの名無しさん [] 2025/05/21(水) 10:10:58.26 ID:va6/rMba(1) AAS
>>1
O2
3: デフォルトの名無しさん [] 2025/05/28(水) 04:54:08.94 ID:ZTLYIgKF(1) AAS
つるつるわれめ つるつるわれめ
4: デフォルトの名無しさん [sage] 2025/05/28(水) 08:11:47.00 ID:S8gLFyNo(1) AAS
安定してるなぁ
5: デフォルトの名無しさん [] 2025/06/02(月) 15:52:23.57 ID:fdx4Ir3H(1) AAS
なるほどわからん

err := example1()
a, err := example2() // OK
b, err := example2() // OK
// _, err := example2() // ダメー
// err := example1() // ダメー
6
(2): デフォルトの名無しさん [sage] 2025/06/14(土) 07:49:57.64 ID:B+lix1t6(1) AAS
Goって人気とか将来性のある言語だと思う?
7
(1): デフォルトの名無しさん [sage] 2025/06/14(土) 08:34:58.82 ID:BYlCuXj0(1) AAS
>6
マイクロソフト、TypeScriptのコンパイラなどをGo言語に移植することで10倍の処理速度に
外部リンク[html]:www.publickey1.jp

C#やRustよりもGoが選ばれました。人気も将来性もめちゃくちゃありまーす^^
8: デフォルトの名無しさん [sage] 2025/06/14(土) 10:43:58.28 ID:WiumTvVB(1) AAS
>>6
書いてないなら関係なくね?
9: デフォルトの名無しさん [sage] 2025/06/14(土) 11:17:21.04 ID:dtGV1Vl4(1/2) AAS
もうどの言語が好きとかいう時代じゃないからねパフォーマンスの改善を目的としたJSからの単純移植をAIにやらせるにはGoは適していることが証明された、それだけのこと
10: デフォルトの名無しさん [sage] 2025/06/14(土) 12:09:42.28 ID:+l0S6cSK(1) AAS
これってAIによる移植なんか?
11: デフォルトの名無しさん [sage] 2025/06/14(土) 12:43:28.73 ID:4ihnDgSn(1) AAS
AIによる移植でもなければJSからの移植でもない
基本的な認識が間違ってる、それだけのこと
12: デフォルトの名無しさん [sage] 2025/06/14(土) 13:13:38.94 ID:/OxuSDvW(1/10) AAS
> 性能向上の要因の半分はネイティブコード化によるものであり、残りの半分は並行処理の利用によるものだとしました。
つまりネイティブ化と並行で3.31倍ずつ
技術的にはそりゃそうだろで凄くはない
13
(1): デフォルトの名無しさん [sage] 2025/06/14(土) 15:21:50.33 ID:lU2qZKzs(1) AAS
当たり前のことを当たり前にやるのが大切なんでしょ
14: デフォルトの名無しさん [] 2025/06/14(土) 17:10:26.41 ID:IqWN5A4e(1) AAS
RailsとLaravel一筋だった3年目ですがなんかGo(Gin)やることになりました
僕の未来は安泰ですか
ポインタでつまずきました
15: デフォルトの名無しさん [sage] 2025/06/14(土) 17:46:49.96 ID:y4VinIhq(1) AAS
まずはプログラミング言語がキャリアの軸になっているステージを脱することが大切
幸いにもGoはわりと言語どうでもいい段階の人が多いので、ステップアップには良い環境だ
16
(1): デフォルトの名無しさん [sage] 2025/06/14(土) 17:50:53.17 ID:/OxuSDvW(2/10) AAS
>>13
それはその通りだが…

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

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

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

ちな、最後については、元がJS(TS)なのでソースコード上でスレッド間は完全分離してるから、C#でも大して問題ない
つまり、この点について、JS->Go、JS->C#の移植は問題ないが、Go->JSの移植はgoroutine使いまくりの場合厳しいかも?
俺的にはC#でよかったんじゃね?とは思う(まあGoでも特に問題ないが)
17
(1): デフォルトの名無しさん [sage] 2025/06/14(土) 18:29:30.75 ID:R+Velb9Y(1) AAS
>>16
>C#: 2014年頃からネイティブも出来るようになったらしい
2014年は.NET NativeのPreviewリリースのことだな
そいつは今のAOTコンパイラとは全く別のもの
今のやつは2022年正式リリース

C#を選ばなかった理由
動画リンク[YouTube]

18: デフォルトの名無しさん [] 2025/06/14(土) 19:21:06.66 ID:tKqSzfGn(1) AAS
ポインタで躓くなら他の職種に行ったほうが幸せ
お前の周り、ライバルはみんな理解するぐらいの能力有してるから
19: デフォルトの名無しさん [sage] 2025/06/14(土) 20:02:28.20 ID:/OxuSDvW(3/10) AAS
>>17
とりあえずその部分だけ見た

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

まあ納得の説明ではあるが、
OOPをウップス!と読むのか?(まあ単語としてはそうだが)
classesがplusses(って何ぞ?)に聞こえるので、字幕無いと厳しいなこれは
(ただ字幕は追従できてるので、俺の耳が悪いのも事実だが)
20
(3): デフォルトの名無しさん [sage] 2025/06/14(土) 21:14:48.29 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にするが、ポーティングだからね」なので、
彼の見立ては俺に近く、「Cyclicなんて無くても作れるし、スクラッチならそうするからRustで問題ない」なのだろうが、
元々がCyclicを多用してる理由を知りたい、というか、

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

なケースなんて有るか?
まあこれが今回tscということなのだが、どういうケースでどういう選択でそうなったのか知りたい
(つってもソースコード読めではあるが、知ってたらよろしく)
21: デフォルトの名無しさん [sage] 2025/06/14(土) 21:28:21.25 ID:/OxuSDvW(5/10) AAS
と思ったがTSの連中に聞くことにした
2chスレ:tech
22
(1): デフォルトの名無しさん [sage] 2025/06/14(土) 21:29:08.75 ID:dtGV1Vl4(2/2) AAS
>>20
依存関係の循環じゃなくて参照の循環は普通にあるよ
例えば親コンポーネントがその上に乗っている子コンポーネントからの通知をコールバックで受け取るケースでは循環参照が発生する
23
(1): デフォルトの名無しさん [sage] 2025/06/14(土) 22:38:33.86 ID:GCb7U03w(1/2) AAS
>>20
「スクラッチから作るのならRustにする」なんて言ってないだろ
「Cyclicなんて無くても作れるし、スクラッチならそうするからRustで問題ない」なんてことも言ってない

勝手に脳内変換しちゃいかんよ
24: デフォルトの名無しさん [] 2025/06/14(土) 22:43:49.77 ID:eLCz0XU2(1) AAS
組み込みはメモリー周りが厳しいのでRust一択ですよね
25
(1): デフォルトの名無しさん [sage] 2025/06/14(土) 22:51:31.08 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ではそうはいかない
1-
あと 43 レスあります
スレ情報 赤レス抽出 画像レス抽出 歴の未読スレ AAサムネイル

ぬこの手 ぬこTOP 0.459s*