次世代言語28 TypeScript Swift Go Kotlin Rust Nim

レス数が900を超えています。1000を超えると表示できなくなるよ。
2022/08/29(月) 11:22:16.48ID:5dAad4gs
スレタイ以外の言語もok

前スレ
次世代言語27 TypeScript Swift Go Kotlin Rust Nim
https://mevius.5ch.net/test/read.cgi/tech/1659655598/
827デフォルトの名無しさん
垢版 |
2022/09/16(金) 18:28:16.66ID:fQY5NM7R
GCはメモリ確保やコンパクションや解放をまとめてやりやすいからパフォーマンス出しやすい。
そのおかげでストップザワールドやGCスパイクも享受できる。
負荷を予測したい奴には向いてないかもな。
そういう意味ではGC言語はピーキーなんよ。
お前にはまだ早いかもしれん。
828デフォルトの名無しさん
垢版 |
2022/09/16(金) 18:32:35.16ID:fQY5NM7R
>>824
swiftは問答無用でretain,releaseもつくからじゃんよ
2022/09/16(金) 18:38:52.62ID:9KGaiKu/
GCは〜って言って思考停止してるとRustでも使っているepochとか知らなそう
2022/09/16(金) 18:46:51.84ID:RqiYn650
いずれGCがメモリレイアウトを動的に最適化したり必要に応じて確定的なメモリ解放を行うように動的にJITしたりするようになるから、究極的にはGCが勝利するだろうね
831デフォルトの名無しさん
垢版 |
2022/09/16(金) 18:48:15.45ID:j69kQS4p
Zigの良さがよくわからない
C言語より安全なのはわかるけどでもそれって結局Cでいいじゃんってなるよね
Rustみたいに静的メモリ安全は実現するのは端から諦めてC言語よりちょっと安全な言語を目指しているんだよね
本当にニッチって言葉が似合いすぎている
構文も無駄に複雑だし汚いし将来性ないと思う
2022/09/16(金) 18:49:54.01ID:LN15iZX2
>>830
それ結構難しい話に聞こえるけど、具体的な進展があるの？
2022/09/16(金) 18:52:48.51ID:LN15iZX2
>>831 ZigはBinary生成が優秀だから、依存dll/soとかクロスコンパイルとか。Rustでも使っているよ
2022/09/16(金) 18:59:55.32ID:xvE1RXjk
Zigは構文が好きじゃない
わかりにくいよね
2022/09/16(金) 19:00:01.75ID:EVJZN8ya
>>820
変なこと言ってる人と同一視するのは勘弁してくれ
2022/09/16(金) 19:04:06.25ID:xvE1RXjk
>>820
そういう決めつけで妄想してると統合失調症になるよ
2022/09/16(金) 19:04:06.82ID:LN15iZX2
Zigは作者が会社辞めて専念してるから、華々しくブレイクしなくてもずっと続けてくコミットがすごい
「安全性」は流行っているからリップサービス。マインドは常に実行速度。キレイなBinary。低レイヤー。
構文はちょこちょこ変わるイメージ。ときどき触るだけだけと直ぐに昔のがコンパイル通らなくなる。
2022/09/16(金) 19:13:49.58ID:LN15iZX2
Faster than Cが自慢なのはぶっ飛んでるように聞こえるけど、一時期あったVは嘘だったけど、Zigはときどき本当。
LuaJitでもHaskellでもハマる処理では「簡単な記述で」Cより速いときがある。やってみないとわからない。
2022/09/16(金) 19:19:50.21ID:LN15iZX2
構文なんて飾りですよ。狭い特定の処理がたまたま「簡単な記述で」書けるかどうかだけ。今はまだ時々実験するくらいで十分。深入りは先の話。
2022/09/16(金) 19:23:23.65ID:HUefBg/J
Zigの時代ｷﾀ━━━━(ﾟ∀ﾟ)━━━━!!
2022/09/16(金) 19:24:40.95ID:LN15iZX2
>>830 これ嘘大袈裟かな？w
2022/09/16(金) 19:25:42.72ID:LN15iZX2
まいいや
2022/09/16(金) 19:35:28.83ID:xvE1RXjk
>>830
それインクリメンタルコピーCGのことでは？
2022/09/16(金) 19:36:49.01ID:xvE1RXjk
今のところZig使うならCで良いかな
使う気にはなれないな
2022/09/16(金) 19:54:10.89ID:eTFy07in
ム板のゲハスレ
2022/09/16(金) 20:01:08.19ID:0J+L4jjc
すみませんZigはまだβ、Nimはver1.6という事で....

>>818
>nimなんかはそこを交換可能

NimのGC/ORC/ARCは興味深いですね
https://nim-lang.org/blog/2020/12/08/introducing-orc.html

もっと選べるようだけど、循環参照などデータ構造別に切り替えて混在出来るのかな？
https://nim-lang.github.io/Nim/mm.html

>>843 上記のリストに入ってますか？
2022/09/16(金) 20:08:18.02ID:0J+L4jjc
>>843 教えてください。検索すると30年位前の論文なんかも出てきて実現しているのかどうか、
それが>>830で言っているGCと一致しているのか、ちょっと理解が追いつきません....
2022/09/16(金) 20:23:30.89ID:74dom6Tp
GCの研究が進んでよりよいものができるようになったとき
GC言語はそれをまんまと拝借できるから旨味あるよな
2022/09/16(金) 20:34:49.53ID:0J+L4jjc
>>848 そうなんです。
ただ >>843の「incremental copy garbage collector」が30年以上まえから未だに研究されているのは検索すればすぐにわかるのですが、
nimで選べるくらいの実用段階なのか、更には>>830で言っている ものと一致しているのか、 重要ですよね。
30年以上の研究なんて逆に絵に描いた餅に思えたりするので。
2022/09/16(金) 20:51:30.89ID:paysycNa
GC活用するだけじゃなくて、スタックフレームからエスケープしにくくする仕組みがあると面白いと思うけどね。

Rustほどガチガチだとだるいから、エスケープをコントロールするスマポみたいなクラスを用意するとか。
2022/09/16(金) 21:07:42.67ID:8k9s5Jiv
GC以外だと、JVMや. NetなんかのVMも結構に改善してるんじゃない？
2022/09/16(金) 21:21:31.00ID:74dom6Tp
GCもVMもどんどん改善してくれたまへ
JavaでHotSpotだのJITだの言い出したころワクワク感あったな
プログラマはプラットフォームに対してでなくて
これからはGCやVMに対してプログラミングをするだけでよくて
さらにGCやVMは誰かのおかげで勝手に改善されていくらしいという
2022/09/16(金) 21:27:14.70ID:z5XcLMe6
http://www.kmonos.net/alang/d/garbage.html

ガベージコレクトされたプログラムの方が高速です。 これは直感に反するかもしれませんが、その理由は：

明示的なメモリ管理の際によく使われる手法は、参照カウントです。 代入があるたびにカウントを増やしたり減らしたリソースを挿入するのは、 速度低下の原因になっています。スマートポインタクラスでラップしても、 速度的な解決にはなりません。
(またいずれにせよ、 循環参照を削除できない参照カウント方式は、 一般的な解決策ではありません。)

オブジェクトによって獲得されたリソースの解放には、 デストラクタが使用されます。多くのクラスでは、このリソースとは 割り当てられたメモリのことです。
GCを使えば、 ほとんどのデストラクタが空になり、完全に削除してしまえます。

メモリ管理のためのデストラクタは、 オブジェクトがスタックに置かれたときに影響が顕著になります。
例外が発生したときに、全てのスタックフレームでデストラクタが呼び出され、 メモリを解放するような仕組みが必要となるのです。 もしデストラクタが関係しなければ、例外を処理する特別なスタックフレームを 設定する必要がなくなり、コードは高速に実行されます。

メモリ管理に必要なコードは全てを合わせるとちょっとした量になります。 大きなプログラムになるほど、キャッシュに入らない部分が増え、 ページングが多く発生し、 プログラムが遅くなります。

GCは、メモリが残り少なくなってきたときのみ実行されます。 メモリに余裕があれば、プログラムは全速力で実行され、 メモリ解放に一切時間を取られません。

モダンなGCは、過去の遅いものより遙かに発展しています。 世代型のコピーGCには、 昔のマーク＆スイープアルゴリズムの非効率さはありません。

モダンなGCはヒープの詰め直しを行います。 これによってプログラムが活発に参照するページの数を減らし、 キャッシュヒット率を高め、 スワップ回数が減ります。

GCを使うプログラムは、メモリリークの積み重ねで次第にパフォーマンスが悪化、 という事態に縁がありません。
2022/09/16(金) 21:34:12.96ID:W9x6+yw/
>>830
どちらもJVMで実現済みのことに思えるが…。

メモリレイアウトの最適化
→ 世代別GC(長寿命なオブジェクトは頻繁にGCしない領域に移動する)

確定的なメモリはJITで開放
→ エスケープ解析(短命でスタックに乗せても構わないオブジェクトはスタックに乗せる)
2022/09/16(金) 21:36:23.95ID:9X7PH4Bp
deno=Rust
bun=zig


https://res.cloudinary.com/practicaldev/image/fetch/s--HAhtlbw8--/c_limit%2Cf_auto%2Cfl_progressive%2Cq_auto%2Cw_880/https://dev-to-uploads.s3.amazonaws.com/uploads/articles/oi6yfxenbfcuhlrkl6j7.png
2022/09/16(金) 21:39:12.85ID:paysycNa
>>853
近現代の言語だと例外は飛び抜けて重い機能だよな。c++使うときも自分から例外を使うこと無いし。
例外みたいなエラーフローあると便利なことあるんかね？
2022/09/16(金) 21:39:55.16ID:W9x6+yw/
>>855
それも言語の良し悪しよりもbanがやるべきことをやってないだけだったり、nodeが本質的には不必要なことをやりすぎているだけっぽいと思うんだよな。
2022/09/16(金) 21:44:51.39ID:PbYmvI2Z
>>854 等号の左右、ずいぶん曲解しましたね。
2022/09/16(金) 21:45:22.11ID:lW11Z1GI
GC言語、メモリを山のように積んでるマシンだと走りきるまでGC走らなかったりするしな。
mallocしてfreeしないアプリみたいなもんで、ケースによってはそりゃ速い。
2022/09/16(金) 21:55:33.67ID:9X7PH4Bp
>>857
そうなんだね
2022/09/16(金) 22:04:21.30ID:N1Gu8JHK
>>857
要約すると、RustはZigに比べて本質的には不必要なことをやりすぎている、という事でOK
2022/09/16(金) 22:10:48.13ID:oJjxTP0V
Rust「zero overhead abstraction」は嘘でした
2022/09/16(金) 22:15:51.87ID:8FnpT4Fe
>>856
C++使ってないな。C#ユーザー
2022/09/16(金) 22:19:05.45ID:EVJZN8ya
>>853
この文章10年以上前からあるけど今でも成り立つのだろうか

確かにメモリ解放を遅延させることによって実行命令数がGCの方が少なくなる場合はあると思う
一方でいくつかのmalloc実装がやっているような、直近にfreeされた領域を優先的に再割り当てするようなことは、GCが走らない限り、つまり、メモリを使い切るまではできない
freeされた領域はキャッシュに載っていて高速にアクセスできる可能性が高いので、直近にfreeされた領域を使い回すことはキャッシュヒット率を高める効果がある
GC言語は命令数は少なかったとしても、メモリのアクセスレイテンシの影響をより多く受け、トータルでは遅かったりしないだろうか

この文章の元ネタのベンチマークがあるなら現在のマシンで比較してみたら面白そう
2022/09/16(金) 22:26:31.57ID:EVJZN8ya
>>861
アプリの実装の善し悪しの話と実装言語の善し悪しを意図的に混同させるのはよくないよ
2022/09/16(金) 22:34:26.05ID:TcXL+FD0
>>865 Chrome by C++の場合について聞かせて
2022/09/16(金) 22:44:06.52ID:67q+IuG6
>>864
それソースある？
必ず再利用するにあたって領域を書き換えてんだから、直前にfreeしたかどうかに関わらず書き換え直後にキャッシュに乗るのは当たり前じゃないの？
チープな環境でスワップインを回避する効果はあるかもしれんが
2022/09/16(金) 22:47:07.20ID:W9x6+yw/
>>858
曲解してるかなとは我ながら思った。
けど、GCが勝つというほどインパクトある伸び代が挙げられた項目にこれ以上あると感じないんだよね。
2022/09/16(金) 22:47:38.62ID:aq1cgc5a
>>876 スワップインて。。>>864はまっとうな意見だと思うよ。
2022/09/16(金) 22:54:48.64ID:aq1cgc5a
>>868
>GCが勝つという
そんな場合もある、程度では。

GraalVMでNativeにした場合で
Native Java(+GC) vs Native other(no GC)は気になる
2022/09/16(金) 23:06:36.63ID:yQqW5GbJ
escapeするかしないか、静的と動的でそんなに違うもんかね。
むしろエラー以外はescapeする・しないは静的で相当範囲カバー出来てそう。データはないけど。
2022/09/16(金) 23:12:50.46ID:lW11Z1GI
>>864
これはそう。ただ投機的実行(と昨今のその去勢)とかを考えると結構難しいかなとは。
2022/09/16(金) 23:22:07.28ID:rsr6X2sj
GCを止めたら速いという話は藁人形論法なのでやめませんか？
2022/09/16(金) 23:25:00.60ID:lW11Z1GI
どこが藁人形なの？
2022/09/16(金) 23:26:02.22ID:3cBZTpx6
>>872 vulnerability詳しくないけど、mitigationでfree->mallocがどの程度影響するのか気になるな。
876デフォルトの名無しさん
垢版 |
2022/09/16(金) 23:34:42.72ID:ATWJ//93
>>853
＞GCを使うプログラムは、メモリリークの積み重ねで次第にパフォーマンスが悪化、 という事態に縁がありません。

嘘言うな
2022/09/16(金) 23:42:23.80ID:n2V9aTfB
GCは解放の実タイミングは調整するけど「メモリリーク」とは見なしてないのでは。

むしろ Rust「メモリリークはメモリ安全性保障の範囲外」 の方なんとかして
2022/09/16(金) 23:44:19.41ID:EVJZN8ya
>>867
GCはそもそもfreeから再利用まで間が開くのでその間にキャッシュから外れる可能性が高くなるし、
再利用に当たって領域を書き換えるなら、キャッシュに載ってない場合書き換え処理に時間がかかるのでは
スワップインはよくわからない
2022/09/16(金) 23:45:28.20ID:EVJZN8ya
>>877
メモリリークを静的に検知するのはプログラムに対する制限が相当大きくなってしまうのでは
2022/09/16(金) 23:53:17.42ID:MTo4LOAu
>>879 動的にでも検知する仕組み/試みがあったりするのかな。テスト、プロファイル、そりゃあるかな。
2022/09/17(土) 00:04:48.75ID:Qv9rB708
>>880
valgrindとかAddressSanitizerとかmallocをhookするやつとかいろいろあるよ
2022/09/17(土) 00:05:17.29ID:guSBFHBz
GCはいわばメモリ管理の専門家に幅広い裁量を持たせて仕事させているわけで、
それに比べるとアプリケーションコード内でのメモリ管理はCenter of Excellence的な意味では原理的にどうしても不利よね
メモリ管理の専門家が十分な裁量を持って仕事できるのはせいぜいアロケータの実装くらいで、ほかは高水準のプログラミングモデルやプログラマの能力の制約を強く受けることになる
883デフォルトの名無しさん
垢版 |
2022/09/17(土) 00:13:57.81ID:WaM/gYIx
Javaは実行時最適化によりRustの3倍速い。
2022/09/17(土) 00:21:14.46ID:Qv9rB708
>>883
(場合もある)
885デフォルトの名無しさん
垢版 |
2022/09/17(土) 00:44:08.92ID:wgXFenVD
スパイクの出ないGC出たら即乗り換える予定
2022/09/17(土) 01:02:29.41ID:HP4MaZ5C
それ以来30年間GC技術が進んだ結果の現状が既出のこれ

>>200
>> https://pbs.twimg.com/media/EmYvG8aVkAMdfFG.jpg

全く対等に同条件で多くの人々が同じ問題に対して様々な言語で記述した結果の各実行時間
速く実行できた言語はRustとCとC++の3つでいずれもGCなし
GCする言語は軒並み遅い
一部をGC対象とならないよう回避の努力をしているGoがGC言語の中で最も速い
そうでない普通のGC言語は遅すぎる
2022/09/17(土) 01:35:11.26ID:Qv9rB708
>>886
これってGC性能が支配的になる問題なの？
888デフォルトの名無しさん
垢版 |
2022/09/17(土) 01:41:35.46ID:wgXFenVD
pythonさん
2022/09/17(土) 01:47:29.96ID:5sn184WB
>>887
(1) GCが発生している場合
　　→ GC性能が改善された現在でもGC言語は遅い

(2) GCが発生していない場合
　　→ GC性能と関係なくGCが起きない段階でもGC言語は遅い

どちらのケースであってもGC言語はダメな存在になってしまいますね
2022/09/17(土) 01:50:03.67ID:6EmGuQEd
あれ、D言語はかなり早いイメージだったけど、Goに負けることもあるのか
891デフォルトの名無しさん
垢版 |
2022/09/17(土) 01:52:02.97ID:WaM/gYIx
>>884
無いよ（笑
2022/09/17(土) 01:53:36.44ID:6EmGuQEd
LDCじゃなくてGDC使ってんのかな
2022/09/17(土) 01:57:29.45ID:5J0Fty65
Goは速いよ。

アンチGCはGC言語じゃなければ速い、と思い込みすぎでは？

ミッション車みたいなもんで、自分の設計力の無さがパフォーマンス劣化に直結するというか、いわゆるベンチのスペックは素直には出ないよ。
Rustアンチじゃないけど、これはRustの目的でもない(あくまで安全が目的)

GC言語みたいにだれでも80点が取れます、エンストしませんよ、みたいなもんじゃないんよ。

コンパイラが叱ってくれるからハイパフォーマンスとか、書いてて言ってんのかほんとに謎。
2022/09/17(土) 01:58:13.17ID:g4Vhwu4S
ゲハでやれ
895デフォルトの名無しさん
垢版 |
2022/09/17(土) 01:59:07.17ID:WaM/gYIx
>>886
そいつの読み方は「C＋＋とPyPy3圧倒的じゃないか」ですよ。
新参者から熟練者まで数と質すべてが圧倒的。
C++は熟練すると、黒魔術を含め、やりたいことが全てできる言語なので、突き詰めていく性質の企業におすすめ。
逆に、手数で勝負の乱打スタイル企業には、PythonやRoRがお勧め。
896デフォルトの名無しさん
垢版 |
2022/09/17(土) 02:01:08.18ID:WaM/gYIx
>>893
Javaも速いですよ。
Rustの3倍は冗談だけど。
欠点はメモリーを使いすぎること。
一般的なパソコンはメモリーが少し足りない。
だから、Javaは遅いと思われてる。
ミスマッチです。
897デフォルトの名無しさん
垢版 |
2022/09/17(土) 02:04:15.85ID:WaM/gYIx
ハードウェアを売りたい言語だから、ハードウェアに対する要求が少し厳しかったですね。
2022/09/17(土) 02:25:11.61ID:YHpfxvp6
>>886
やはりGCの言語はいずれも遅いな
GCのせいで遅くなるのではなく
ヒープでメモリ確保するからGCの言語は遅くなる
2022/09/17(土) 03:31:52.64ID:5J0Fty65
>>896
Java速いよね。あんまり適切なXmx知られてないだけだと思う。

>>898
少なくとも知ってる範囲だとGoもc#も取れるときはスタックを確保するぞ。
2022/09/17(土) 03:42:09.24ID:o0T2dyfd
>>899
Javaは遅いです
どのベンチマークでもC/C++/Rustの2倍～数倍はJavaが遅いです
>>886の例でもJavaは数倍遅くなっています
2022/09/17(土) 03:53:04.00ID:5J0Fty65
>>900
abc 182-eはakariって問題なんだけど、読んだ？
Javaで雑に書くとパフォーマンスでない類の問題だよ。

このグラフは言語オタ勢には有名かと思ってたけど、ベンチマークのグラフではなくて、あくまで競技者が書いた言語毎の統計のグラフなので、ポンコツが多ければそれが表現される。
言語人口が多いものの箱ひげが偉いことになってるでしょ。
2022/09/17(土) 04:54:39.17ID:1eeK5YMC
>>901
なるほど
しかしJavaで書いて最も速くできた人でも遅くて
Rustで書いた平均的な人たちにすら負けているな>>886
どんなに優れた人であってもJavaを使った時点で遅いと確定してしまうのは辛いな
2022/09/17(土) 07:28:28.63ID:8assD4qG
>>877
これ訳わからんよね。
そこまでして「GC不要でメモリ安全」を売りにしたかったのか、と思うわ。
c++とかだとメモリリークも普通にバグ扱いされるのに、それを「メモリ安全」と言い切るのは詐欺臭い。
2022/09/17(土) 07:39:14.89ID:8assD4qG
>>902
そもそもRust使える人間は他の言語に詳しい人間しか居ないだろ。

他の言語に詳しく無い人間がRustの絶壁の学習曲線をクリアできるとは思えん。
「Rustしか使えません」なんて人間は存在するのかね？
2022/09/17(土) 07:46:13.48ID:TM5e0HO7
>>903
それは常識
一般的に循環参照の安全な解放を静的に記述したり静的にチェックすることは不可能
デッドロックも同じで静的に発生をチェックして防止することは不可能
だからコンパイラ(＝静的にチェックする存在)がそれらを防ぐことは対象外となる
2022/09/17(土) 07:50:22.53ID:XDvVGFlj
>>904
バカは遅い言語や危険な言語を使い続ければよい
時代の要請は高速で安全でプログラミング効率の良い言語でありそれはRust
使えないバカがついていけずに切り捨てられていくことは業界にとっても朗報だ
2022/09/17(土) 08:47:42.31ID:+hLuAY/P
早い言語は適当に書いても2秒の時間制限に間に合うけど
遅い言語は問題の想定解法じゃないと通らないから結果的に早い言語は上髭多くなるだけ
2022/09/17(土) 09:18:54.40ID:vRd8nzJr
>>902
execution timeの単位はミリ秒だぞ
ベンチヲタは気にするが1000000回ループして1秒か2秒しか差がつかないのに現実的に問題になることってないぞw
現実のループは多くてもせいぜい1000回程度だろ
2022/09/17(土) 09:57:15.90ID:BhE3E6/v
>>908
あんたには遅くてダメな言語で十分なのだから他を気にせず不満を持たずそのままでいいじゃないか
あんたには無縁だが世の中には速くて安全で保守性も良い言語が求められているだけの話だ
2022/09/17(土) 10:21:27.92ID:ktSmkMDB
Rustの他の言語と比べた速度向上って、俺にじゃなく世のほとんどのプロジェクトにとって五十歩百歩の微々たるものなんですわw
2022/09/17(土) 10:29:26.87ID:KEhwIc0k
前に、rustでtsc実装した人、さらにgoで作り直すって、理由がrustには向いてないからって。翻訳記事だからニュアンス違うのかもしれないけれど。
2022/09/17(土) 10:29:40.60ID:8assD4qG
>>905
プログラマサイドにそんな「常識」は無い。プログラマ視点なら「メモリリークはバグ。メモリを圧迫してトラブルになる危険がある」の方が常識。Rust関係者はそういうことを説明の奥の方に隠して「メモリ安全」とか誇大広告するから詐欺だと指摘しているわけで。

常識とかけ離れた俺俺定義を使うならちゃんと注意書きしろよ。
「メモリ安全*」
*メモリリークを除きます。
みたいに。
2022/09/17(土) 10:35:04.81ID:xfq0iQEs
Amazonの>>9の記事にもあるけど
Rustへ書き換えるだけだけでリソースコストや電気代それに伴うCo2排出量などが少なくとも50%は削減できる
さらにセキュリティの要請から安全性も求められている
土方でないまもともなプログラマーならばJavaでもRustでも他の言語でもプログラミングに支障なく書ける
それらの状況から選ぶべき言語がRust一択になっているだけでしょう
2022/09/17(土) 10:39:04.61ID:ktSmkMDB
https://stackoverflow.com/questions/55553048/is-it-possible-to-cause-a-memory-leak-in-rust
> Is it possible to cause a memory leak in Rust?
> You can also leak memory if you create a cycle of shared references:
> You can also use Box::leak to create a static reference, or Box::into_raw in an FFI situation.
> You might've forgotten about Box::leak and Box::into_raw which are pretty common in ffi situations for passing around states.

https://doc.rust-lang.org/book/ch15-06-reference-cycles.html#reference-cycles-can-leak-memory
> Reference Cycles Can Leak Memory
2022/09/17(土) 10:46:39.42ID:vRd8nzJr
RustでなくVBAを使うことでエネルギー削減になることもあるな
2022/09/17(土) 10:55:22.36ID:8assD4qG
>>913
Rustを学習した人間の感想の多くが「Rustは難解」と言っているのに、「まともなプログラマなら支障なく書ける」とする根拠は？
根拠が個人の感想なら、「まともなドライバーならマニュアル車を支障なく運転できる」と言うくらい傲慢だと思うがね。
2022/09/17(土) 10:55:41.70ID:gI44iNXP
>>912
それはちょっと知識不足じゃないかしら
もし循環参照を作っちゃった場合はそれを安全に解放する局所的な方法は理論的に存在しないんですよ
GCでも局所的に解決できる参照カウント方式では循環参照を解放できないため
GCの中でも全体のマークスイープ方式や全体の使用中分コピー方式でようやく解放されます
そららは非常にコストが重いだけでなく発動までに時差もあります

したがってプログラミング言語界ではそんなコストがかかるものに依存するのではなく
最初から循環参照を作らない方向で進んでいます
そのため最近は多くの言語で弱参照がサポートされており循環参照の発生を防ぐことができます

今回の話のJavaでももちろん弱参照が用意されていて最初から循環参照を作らないようにプログラミングします
そのほうが有利だからです
2022/09/17(土) 11:04:35.77ID:ktSmkMDB
>>917
C#では参照はツリーで管理されるから循環参照も問題なく一瞬で開放される
2022/09/17(土) 11:12:08.51ID:/Lpl+zOG
>>917
Wikipediaですら「メモリ安全性」の解説でメモリリークをメモリエラーとしているのに、実装側の都合で一般に使われている用語の意味をひん曲げて「常識」とな？

そういうのが詐欺だと指摘しているだけだけどなぁ。

今度からちゃんと
「メモリ安全*」
*メモリリークを除きます。
と注釈付けろよ。
2022/09/17(土) 11:17:11.83ID:gI44iNXP
>>918
それはC#でもJavaでもRustでも他の言語でも全て同じ方法です
どの言語も弱参照を併用して参照はツリー状のみにすることで循環参照の発生を防ぎます
もちろんそこには弱参照による弱い循環参照がありますが通常の参照はツリー状なので
おっしゃる通りに一瞬で解放することが可能です
2022/09/17(土) 11:20:08.51ID:Qv9rB708
>>919
wikipediaのメモリ安全性のメモリリークで挙げられてる項目は循環参照によるリークは含まれてないっぽいが
https://ja.m.wikipedia.org/wiki/%E3%83%A1%E3%83%A2%E3%83%AA%E5%AE%89%E5%85%A8%E6%80%A7
2022/09/17(土) 11:32:35.56ID:yVMylSLT
ところで所有権は複製されるってことでいいの？
2022/09/17(土) 11:33:28.06ID:8assD4qG
>>921
リンク先にある「メモリリーク」の項ぐらい読めよ。
2022/09/17(土) 11:34:17.29ID:ktSmkMDB
今時循環参照くらいでメモリリークするような言語でよく安全を名乗れたもんだ
退化してるやん
2022/09/17(土) 11:39:26.07ID:/MEkW9dR
昔は保守的GCというGCに人気があった
本当はゴミなのにゴミではないと判断することはバグではなく安全、という注釈つきのGCだった

この注釈は嘘だったという見方の方が今は優勢
2022/09/17(土) 11:42:22.70ID:yVMylSLT
予想される次の手：
・循環参照の矮小化
　循環参照なんてめったに起こらないし
　普通に書いてたら発生しようがない
・問題の転嫁
　循環参照なんて書くほうが悪い
　循環参照によるメモリリークなんかを問題視するほうが悪い
・飛躍した結論
　とにかくRustは素晴らしい
レス数が900を超えています。1000を超えると表示できなくなるよ。
5ちゃんねるの広告が気に入らない場合は、こちらをクリックしてください。
ニューススポーツなんでも実況