[過去ﾛｸﾞ] Go language part 3 (918ﾚｽ)
上下前次1-新
このｽﾚｯﾄﾞは過去ﾛｸﾞ倉庫に格納されています｡
次ｽﾚ検索 歴削→次ｽﾚ 栞削→次ｽﾚ 過去ﾛｸﾞﾒﾆｭｰ
1(1): デフォルトの名無しさん [sage] 2019/10/17(木) 21:38:04 ID:wMsZ+t6y(1) AAS
Goについて扱うスレッドです。
GoはGoogleによって開発された言語です。
公式ドキュメント
外部ﾘﾝｸ:golang.org
日本語訳
外部ﾘﾝｸ:golang.jp
※前スレ
Go language part 2
2chｽﾚ:tech
894: デフォルトの名無しさん [sage] 2020/11/04(水) 12:03:20 ID:q9h9Yk1J(2/5) AAS
参照カウント方式には結構なメリットがある。
別スレッドも必要ないし、速度も出る。ストップザ・ワールドも必要ない。
オブジェクトの開放が「かならず」「一定の場所」で行われてデストラクタの動作タイミングを保証できる。
弱参照がきっちりしてればそれこそ循環参照もそれほど恐れることはない。
組み合わせて使うのが良いと思うよ。俺的には。
だからこそ引き合いに出したんだが。
C++好きならshared_ptrあたりから理解が及びそうなもんなんだが。
895: デフォルトの名無しさん [sage] 2020/11/04(水) 12:04:06 ID:q9h9Yk1J(3/5) AAS
>>887887(4): デフォルトの名無しさん [sage] 2020/11/04(水) 08:59:07 ID:thexrnOY(3/4) AAS
>>886
参照カウンタのGCとマーク&スイープのGCは意味合いが全然違う。
それを一緒くたにしてるようでは駄目だよ。
そこら辺がGoスゲーって言ってる奴のレベルが低いところだよ。
それ以外も君は間違いすぎていちいち指摘するのは諦めたけど、
多分もうちょっと勉強した方がいい。
Goは酷い言語でもないけど、凄い言語でもない。
860の本家にRustと冷静に比較しているコメントがあるから読んでくるといい。
で、指摘してみろよ。
お前が間違ってることは懇切丁寧に指摘してるんだから。
896(2): デフォルトの名無しさん [sage] 2020/11/04(水) 12:22:41 ID:Q20JRtoy(1) AAS
循環参照検出付きの参照カウント方式は、GC?
897: デフォルトの名無しさん [sage] 2020/11/04(水) 15:06:50 ID:q9h9Yk1J(4/5) AAS
>>896
自動的にメモリを開放してくれて、フラグメントを解消してくれる仕組みは、大雑把に言ってガベージコレクションの仲間に入れるもんじゃない？
898: デフォルトの名無しさん [sage] 2020/11/04(水) 16:33:07 ID:bB+A/rRK(2/2) AAS
誰かこの人形劇を止めてくれよ
899: デフォルトの名無しさん [sage] 2020/11/04(水) 18:33:48 ID:q9h9Yk1J(5/5) AAS
とりあえずGoのリリースノートを全部読んでから話してほしいな。彼には。
1.14あたりでgoroutineのスケジューラちょっと変わってるし。
900(3): デフォルトの名無しさん [sage] 2020/11/04(水) 22:39:50 ID:thexrnOY(4/4) AAS
>>889889(1): デフォルトの名無しさん [] 2020/11/04(水) 10:57:28 ID:BNFfXKWA(4/4) AAS
>>887
広義では参照カウンタもgcじゃん。
gcも色々改良されてるし未だに古典的なマークスイープgcのみってのはあまり無いんじゃろか。
だから案件の多いweb系とかアプリとかの上のレイヤーでgcが問題になるケースはあまり無い。
gcはそれより下のエンジンとかのシステムレイヤーで問題視されることが多い。
で、一応goはc/c++/rust同様のシステム言語のくくりで語られることもあるからその辺から叩かれたりするけど、そうじゃなくて上のレイヤーの言語として使えばいい感じの言語だと思う。
> 広義では参照カウンタもgcじゃん。
そう。俺も「参照カウンタのGC」とも言っている。
馬鹿は放置として、君も疑問のようだから回答しておくと、
参照カウンタ方式は「ユーザーが間違ってない」前提が必要で、「ユーザー補助」でしかない。
対してマーク＆スイープは「ユーザーが間違ってても」GCが為されるから、「システム保護」なんだよ。
だから役割が全然違う。少なくとも真面目に24時間365日動作させるつもりなら、単純に交換は出来ない。
これが結局何だかんだでマーク＆スイープから離れられない理由で、
JavaもC#もJSも、勿論Goもマーク＆スイープしてる。
勿論それが重いのはみんな分かってるから、色々工夫してるけど、最終的にはやるしかないから。
だから参照カウンタ方式のGCでマーク＆スイープと同様に「システム保護」を得る為には、
「ユーザーがどんな書き方をしても」解放されることが必要で、
例えば>>896のようなのが有ればいいけど、これで実装してる例ってあったっけ？
（なお循環参照の検出自体は簡単だが、適切に起動する為のイベントがないから、実装時に困るのはそこだと思うが）
> そうじゃなくて上のレイヤーの言語として使えばいい感じの言語だと思う。
そこは今どっかりとC#が根を下ろそうとしている。
C#は俺は良い言語だと思うけど、Javaに食われて死にそうなのがなあ、という見方だったが、
少なくとも俺の予想以上には大健闘していて、生き残るかもしれないなあ、とは思いつつある。
これまではC#もC++もWeb系が手薄だったけど、どっちもガチで整備し始めてるから、それが完了した時にどうなるかだね。
そしたら本当にGoを使う意味が全くなくなる。
逆にRustはCPU負荷無しで「システム保護」出来るわけだから、GC言語を皆殺しにかかってる。
そしてC並に速いのだから、確かに最終兵器ではあるんだよ。盛り上がる理由はそれ。
901: デフォルトの名無しさん [sage] 2020/11/04(水) 23:37:57 ID:7oWZmWjZ(1) AAS
>>900
長文連投しても知識が薄っぺらい
外部ﾘﾝｸ[md]:github.com
902: デフォルトの名無しさん [sage] 2020/11/05(木) 00:53:39 ID:iOSFoZGZ(1) AAS
>>900
ユーザーが参照カウントを上げ下げすることなんてほぼないぞ
言語内の仕組みなんだから
C拡張とか書く場合もたいていスコープ抜けたら
それまでの一時変数は全解放するって書き方があるし
他のGCでもそれは同じ
だからほとんど中身の仕組みを意識しなくても良い
むしろそれができないなら実装がしょぼい
903: デフォルトの名無しさん [sage] 2020/11/05(木) 01:09:47 ID:dYXzTkiF(1) AAS
Goが人気出た大きな理由の一つは、過不足がなく比較的高品質な標準ライブラリ
その点でいえばNodeも同じだが、Nodeと違って変なのを噛まさず標準ライブラリを素のまま普通に使うことを美徳とする文化があるのも効いてる
くだらない流行り廃りに惑わされずに決まったものをただ普通に使えばよいというのが近年の複雑化しすぎたWeb界には受けた
Rustはそのへんは全然ダメだね
904: デフォルトの名無しさん [sage] 2020/11/05(木) 01:17:10 ID:x7P4NeVz(1/2) AAS
またそんな煽りを…
まったくオマイラときたら変な輩を呼び寄せる呪文を唱える
才能に関しては天才的だな
905: デフォルトの名無しさん [sage] 2020/11/05(木) 07:04:56 ID:40Zkap5B(1) AAS
>>900
それで実装してる例がPython
906(1): デフォルトの名無しさん [sage] 2020/11/05(木) 07:24:03 ID:td0oky8W(1) AAS
RustはRustでC++の標準ライブラリがゴテゴテと九龍城が如く聳え立ってきた反動でもあるので許してやれという気持ちがある
それにしたって初期の標準が貧弱で標準に取り込むまでの右往左往が長すぎるというのも分かるが
907: デフォルトの名無しさん [sage] 2020/11/05(木) 09:00:41 ID:/CgVmiK8(1/3) AAS
>>906
Rustは去年ようやく並列処理APIが固まったレベルだから、将来性はともかく現時点ではまだヨチヨチ歩きな幼児と見てる
十年後に期待
908(2): デフォルトの名無しさん [sage] 2020/11/05(木) 09:25:14 ID:gkJnxR7E(1) AAS
Rustは今でも面白いよ。標準ライブラリが貧弱でも大して困らんけ、並列ランタイムだけは標準に入れて欲しかった。
メジャーなtokioとasync-stdの両対応してる場合も有るけど、大抵枝分かれしてて共存も出来ないから無駄なんだよな。
909: デフォルトの名無しさん [sage] 2020/11/05(木) 10:34:46 ID:/CgVmiK8(2/3) AAS
>>908
Javaで言えば1.0レベルだろ
当時から面白かったんで使ってたけど、実用性は微妙だった。特にファイルIOとコレクション
910: デフォルトの名無しさん [] 2020/11/05(木) 10:59:39 ID:OMGYJi8L(1) AAS
参照カウントって、本当に「言語の仕組み」なの？
911: デフォルトの名無しさん [sage] 2020/11/05(木) 11:05:21 ID:x7P4NeVz(2/2) AAS
こっち↓で聞いてみたら
GCは失敗。メモリは自分で管理せよ！ その2
2chｽﾚ:tech
912: デフォルトの名無しさん [sage] 2020/11/05(木) 11:08:21 ID:+m168BhN(1/3) AAS
C#が充実したらGoが要らなくなる論は全然わからんな。
一体どういう理屈なんだろうか。
同じサーバサイドでもお互いに分担するエリア全然違うくないか？
というか、全然手薄でもなかったし。C#。
913: デフォルトの名無しさん [sage] 2020/11/05(木) 11:27:44 ID:pymKzIg5(1) AAS
ファットなランタイムに依存しながらも比較的デプロイ時の取り回しが良い
わりと固定されたツールセットで無難に迷わずに使える
まあ近いと言えば近いんじゃないかな
C#をバリバリ使ってるとこだとGoの出番はないだろうし
914: デフォルトの名無しさん [sage] 2020/11/05(木) 11:59:24 ID:/CgVmiK8(3/3) AAS
C#ならGUIもサービスも書けるし遅くもないから、Windowsアプリを書くなら鉄板の選択肢だよな
どうしても高速化したいとか解析されたくない時だけC++
ただ事前にランタイムのインストールが必要なんで、Linuxとかマルチプラットフォーム展開の敷居がちょっとあるんで、CLIツールとか書いてもGoに比べてデプロイが不便
充分に住み分けされてるからどっちを使う論争は不毛
915: デフォルトの名無しさん [sage] 2020/11/05(木) 12:39:02 ID:+m168BhN(2/3) AAS
Windowsアプリを作るときの鉄板に関しては異論はないが、C#のデプロイはガッカリ仕様だぞ。
.Net 5でも。
916(1): デフォルトの名無しさん [sage] 2020/11/05(木) 13:08:26 ID:LX/aXWmP(1) AAS
SCDも知らんのか
917: デフォルトの名無しさん [sage] 2020/11/05(木) 13:22:01 ID:+m168BhN(3/3) AAS
>>916
SCDでデプロイしたことあるか？
むちゃくちゃファイル数多いぞ。
SingleBinaryが自己展開ではなく直接アセンブリをロードする形にやっと.Net5でなったけど、そのままだとSingleBinaryと言ってるくせに数ファイル漏れるので、
それも完全にSingleBinaryにするには結局自己展開ファイルにせざるを得ない。
ファイルサイズも結構でかくて、最近は使ってるメソッドのみと言う形でTrimできるようになったけど、誤爆もまだまだあって実用とは言えんし。
ホントにやってみ。期待してただけにすごくガッカリしたから。
918: デフォルトの名無しさん [] 2020/11/05(木) 14:44:49 ID:BWbga0la(1) AAS
>>908
Rustは非同期まわりが不安だよな。
上下前次1-新書関写板覧索設栞歴
ｽﾚ情報 赤ﾚｽ抽出 画像ﾚｽ抽出 歴の未読ｽﾚ AAｻﾑﾈｲﾙ
ぬこの手 ぬこTOP 0.178s*