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

**デフォルトの名無しさん** · 2022/08/29(月) 11:22:16.48

スレタイ以外の言語もok

前スレ
次世代言語27 TypeScript Swift Go Kotlin Rust Nim
https://mevius.5ch.net/test/read.cgi/tech/1659655598/

**デフォルトの名無しさん** · 2022/09/17(土) 13:55:15.51

>>944 >Rustでは意図的に頑張らない限り循環参照が勝手に作られることはない
よくわからないので聞くけど、
Rustでは意図的に頑張れば、Weakにせずに循環参照データ構造を定義してzeroじゃない実データ構築をするコードがコンパイル通るの？

**デフォルトの名無しさん** · 2022/09/17(土) 13:59:18.77

>>943
ならトップページに「Rustにおけるメモリ安全性」として「*メモリリークは除く」くらいはやらないと優良誤認だろ。

**デフォルトの名無しさん** · 2022/09/17(土) 14:14:04.83

>>945
https://doc.rust-jp.rs/book-ja/ch15-06-reference-cycles.html

**デフォルトの名無しさん** · 2022/09/17(土) 14:16:59.16

>>947 ありがとう

**デフォルトの名無しさん** · 2022/09/17(土) 14:26:47.74

>>945

https://play.rust-lang.org/?version=stable&mode=release&edition=2021&gist=0d4932743de9a2d3f91b215fe3a4757b

>最後のprintln!のコメントを外してプログラムを実行したら、aがbを指して、bがaを指してと、スタックがオーバーフローするまでコンパイラはこの循環を出力しようとするでしょう。

確かに
thread 'main' has overflowed its stack
fatal runtime error: stack overflow
timeout: the monitored command dumped core

**デフォルトの名無しさん** · 2022/09/17(土) 14:30:22.04

>>937
循環参照によるリークを含むようにメモリ安全性を定義してる文献ってある？

Wikipediaの定義ではメモリリークという分類はあるけど、
"メモリ使用量が追跡されていない又は誤って追跡されている場合"
と説明されていて、前者は当てはまらないし、後者はダングリングポインタなどを意図しているようで、循環参照は含まないように読める

SwiftやChromeやAOSPやDのメモリ安全性に関するドキュメントでもメモリリークについては触れられていないようだった

**デフォルトの名無しさん** · 2022/09/17(土) 14:33:34.46

>>949
[BUILD]にしてみたが「循環しるよ」的なwarningはないのね

**デフォルトの名無しさん** · 2022/09/17(土) 14:37:56.61

>>951
>>944 >Rustでは意図的に頑張らない限り循環参照が勝手に作られることはない
warningがないし、当該データの使い方次第で実行時エラーにもならないので
意図しなくても、「偶発的に」循環参照が作られることはありそうだ。

**デフォルトの名無しさん** · 2022/09/17(土) 14:42:00.12

潜伏した循環参照が後々深刻な事態になるかどうかは別の話だが
Rustだからと言って、コンパイル通ったからと言って、油断は禁物で

**デフォルトの名無しさん** · 2022/09/17(土) 14:43:28.60

「常識」でしょw

**デフォルトの名無しさん** · 2022/09/17(土) 14:44:11.19

>>937
> 今まである「メモリ安全性」の常識
お前の脳内の話じゃないなら具体的にどういう事なのか示してみそ

**デフォルトの名無しさん** · 2022/09/17(土) 15:27:41.65

すげーくだらないことで盛り上がってんなw
さすが次世代w言語wwスレwww

**デフォルトの名無しさん** · 2022/09/17(土) 15:28:08.55

メモリリークだけでは安全性には差し障らんでしょ。一般的に。
スタック、ヒープが枯渇することはメモリ安全性に差し障るけど。

リークしてるけど走りきった、とか、GCがまとめて解放した、はセーフだと思うよ。

**デフォルトの名無しさん** · 2022/09/17(土) 15:58:19.63

>>950
そんなことよりもまず
「メモリ安全性は(プログラムによる)メモリエラーを許容するのか、しないのか」
はどちらだと思うのか考えてもらいたいね。Rustは「メモリエラーが発生するけどRustはメモリ安全」て言っている。
>>955も同じな。お前もRustみたいに断言するのかね。

まぁ、「c++よりもメモリ安全」というならまだ正確だが、それならそうと正直に言うべきだと思うがね。俺俺メモリ安全をwebページの奥の方に置かないで。

**デフォルトの名無しさん** · 2022/09/17(土) 16:03:03.55

>>957
いやメモリリークはDoS攻撃に対する脆弱性になりうるから安全性に差し障るよ

**デフォルトの名無しさん** · 2022/09/17(土) 16:11:02.02

>>958
「メモリ安全性」という用語の定義の話に変な造語持ち込んで話題そらすのやめてよ

Rustによるメモリ安全性の定義が俺俺というなら、ちゃんとした定義を示して欲しいな
「常識だから分かるでしょ？」というのは自分の思いの表明にしかならないよ

**デフォルトの名無しさん** · 2022/09/17(土) 16:15:15.87

>>958
だからお前の思う「メモリー安全性」の定義を示せよ
まあ示せないからぐだぐだはぐらかすしか無いんだろうけどw

**デフォルトの名無しさん** · 2022/09/17(土) 16:22:09.35

>>957
だとするとRustで常駐系のプログラムの開発をするのは安全では無いですな。
常駐系プログラムがメモリを食い潰すのは良くあるバグだけど、Rustだとそれは「仕様」で「メモリ安全の対象外」なんだから。
まぁ、Rcの循環参照だけの話だから、外部のコードを含めてRc使っていないor循環参照していないことを検証できれば安全なんだろうけど、Rustファンが言うような「Rustを使えば安全」というようなことは無い。

>>960
素直にWikipediaの「RAMアクセス時に発生するバグやセキュリティホールなどから保護されている状態のこと」でいいだろ。
Rust公式はなんて定義しているの？>>931は定義じゃないよな。

**デフォルトの名無しさん** · 2022/09/17(土) 17:12:30.63

「定義」や「常識」「一般的に」の話とは別だが、このスレ見てる個人的印象だと、
Rustで宣伝商売したい人たちは、Rustを知らない人(意思決定者)が「メモリ安全性」を「優良誤認」(自己責任)するのを密かに期待してそう
Rustプログラマーはそうじゃないと言い切れるのか

**デフォルトの名無しさん** · 2022/09/17(土) 17:14:19.56

>>962
あんさんキチガイやな
それはRustの問題じゃない
>>939の説明が一番わかりやすいが言語全般における問題で原理的に解決できない問題やで

**デフォルトの名無しさん** · 2022/09/17(土) 17:28:19.48

https://insights.stackoverflow.com/survey/2021#section-most-popular-technologies-programming-scripting-and-markup-languages
頑張ってるじゃないか
Rubyよりは使われてるみたいだな

**デフォルトの名無しさん** · 2022/09/17(土) 17:33:54.35

>>925
今はしらんがrubyのgcも保守的gcだったよ。

**デフォルトの名無しさん** · 2022/09/17(土) 17:35:17.75

>>934
じゃあなんで弱参照が用意されてるんですかねぇ？

**デフォルトの名無しさん** · 2022/09/17(土) 17:40:51.90

>>926の論法分析が的中してる

>>964
>言語全般における問題で原理的に解決できない問題やで

言語全般が「メモリ安全性」を宣伝してるって言ってる？

>原理的に解決できない問題

原理的もなにもRustプログラマーが常に:

>>919
>「メモリ安全*」
>*メモリリークを除きます。
>と注釈付

すれば良い

**デフォルトの名無しさん** · 2022/09/17(土) 17:42:57.37

>>962
メモリ安全性に循環参照によるメモリリークの抑止が含まれないことは認めてくれた感じかな？

Rustを使えば絶対安全とか言ってる人の言うことを信じるのは良くないよ
匿名掲示板の変な人の発言じゃなくてちやんとしたドキュメントを読んだ方が良い

Rustはメモリ安全性について独自の定義はしてなくて、Wikipediaに書かれているような意味でのメモリ安全性を保証するよ

**デフォルトの名無しさん** · 2022/09/17(土) 17:46:34.02

>>967
グローバルなキャッシュを実装するときなど、参照先のGCを妨げることなく長時間参照を持ち続ける必要がある場合に使用する
基本的にトレーシングGCで弱参照が必要になるのは極めてレアケース

**デフォルトの名無しさん** · 2022/09/17(土) 17:54:50.07

>>964
新しい藁人形連れてくんなよ。
最初から
Rustの問題は>>903で、本来なら
「メモリ安全*」
*メモリリークを除きます。
とちゃんと注意書きすべき
という主張。原理的に解決できるかどうかとか主張していない。

>>964の言うとおり、原理的に解決できないのに>>963を狙って「メモリ安全」と宣伝しているなら邪悪すぎるな。>>964は「Rust公式は邪悪」と言いたいのかな？

**970** · 2022/09/17(土) 17:57:12.28

なお、トレーシングGCにおいて循環強参照を避けることを目的に弱参照を使用することは全く何の意味もない
トレーシングGCのアルゴリズムを知っていれば循環強参照がGCのパフォーマンスやメモリ効率を悪化させることが無いのは明らかであるし、
弱参照の使用はレアケース故に概してあまり最適化されていないため、パフォーマンスは大抵の処理系においてむしろ悪化する

**デフォルトの名無しさん** · 2022/09/17(土) 18:01:07.97

GCあるほうが楽だと思うんだけど、スパイクの無いGCって実現できないの？

**デフォルトの名無しさん** · 2022/09/17(土) 18:02:24.90

>965
>Rubyよりは使われてるみたいだな
逆逆 Stackoverflowは精度がイマイチ

jetbrains
Ruby https://i.imgur.com/zqmf96u.png お一人様 7% ほとんどの人が仕事で使っている
Rust https://i.imgur.com/olB9F6L.png お一人様 86% ほとんどの人が個人の趣味

**デフォルトの名無しさん** · 2022/09/17(土) 18:03:21.53

>>969
いや？全然。
循環参照によるメモリリークはメモリエラーだろ。メモリ安全「RAMアクセス時に発生するバグやセキュリティホールなどから保護されている状態」じゃない。

それにRustファンの言うことを信じているとか、冗談を言うのはやめてくれよ。気持ち悪いから。

**デフォルトの名無しさん** · 2022/09/17(土) 18:04:26.55

>>972
え？
C#では循環参照を避けるためなどの目的で弱参照を使うけど
これは悪化させているとでも言いたいの？

**デフォルトの名無しさん** · 2022/09/17(土) 18:05:04.82

>>962
「どの言語でも基本的には、OOMキラーに殺される前にGCが走らせたり、手動でメモリーを解放できること」ができないと安全では無いんじゃないかな。なので環境依存よ。
そう、Rustを使えば安全では無い。

**デフォルトの名無しさん** · 2022/09/17(土) 18:07:30.72

>>976
そんな事実はない
嘘だと思うならC#スレで聞いてきなさい

**デフォルトの名無しさん** · 2022/09/17(土) 18:17:28.35

今回の件でGC言語がなぜ何倍も遅いのかよく分かった
世代別ガベージコレクションをするため頻繁にコピーGCを行なうことが遅くなる敗因の一つ

**デフォルトの名無しさん** · 2022/09/17(土) 18:27:42.60

>>973
昔、ハードウェア側でGCするJVM(?)があったような…。

**デフォルトの名無しさん** · 2022/09/17(土) 18:30:08.29

>>973
RustはGC無いけど即座に自動的にメモリ解放されて楽だよ

**デフォルトの名無しさん** · 2022/09/17(土) 18:36:24.89

参照カウントって GC じゃないの?

**デフォルトの名無しさん** · 2022/09/17(土) 18:37:21.32

四天王で最弱のGC。

**デフォルトの名無しさん** · 2022/09/17(土) 18:37:25.76

>>981 それの何が楽だと言っているの?

**デフォルトの名無しさん** · 2022/09/17(土) 18:38:14.76

俺の考えたGCが最強だけど、サブマリン特許やる予定だから教えない。

**デフォルトの名無しさん** · 2022/09/17(土) 18:39:44.29

はよ次スレ

**デフォルトの名無しさん** · 2022/09/17(土) 18:40:19.19

GC言語を使うと大して楽になるわけではないのに劇的に遅くなるからな
無能にはGC言語が向いている

**デフォルトの名無しさん** · 2022/09/17(土) 18:40:33.78

>>979
世代間GCのアリナシもそうだし、
>>927と同じく、言語と解決したい課題によるよ。

**デフォルトの名無しさん** · 2022/09/17(土) 18:42:13.95

Java製アプリはオメガテーつこてるけど、遅いとか重いとか一切ない。
サクサク快適。
だがしかし、キャレットの位置が異常なのでテキストの選択がやりにくい。
この動作はJava GUIの仕様だが、仕様が間違っていると思う。
Windowsと同じ動作にするべき。

**デフォルトの名無しさん** · 2022/09/17(土) 18:47:25.27

>>980 次スレ気づいてない誰か代理俺は無理

**デフォルトの名無しさん** · 2022/09/17(土) 18:47:35.21

>>982
プログラマー指定せずとも自動的に参照カウントが使われる言語(PerlとかPythonとかSwiftなど)の場合はGCで合ってるよ
C++のshared_ptrやRustのRcのように特殊な用途のみにプログラマーが明示的に指定して使うものはGCとは呼ばれず単なるデータ管理構造

**デフォルトの名無しさん** · 2022/09/17(土) 18:48:56.73

>>981
いつも出てくるこの自動解放されて楽って感覚がわからない。自動解放とか出来て当たり前じゃないの？

GCありと同等のルーズさが許されなら良いけれど、実際はメモリ管理を明確にさせられるよね。

**デフォルトの名無しさん** · 2022/09/17(土) 18:51:00.89

>>989
Javaは遅い
少なくともC/C++/Rustなどの2倍～数倍は遅い
Javaは仮想マシンだしGCあるし遅くなるのは仕方ない

**デフォルトの名無しさん** · 2022/09/17(土) 18:51:29.16

お子様　→　Python
おんな　→　Ruby
真の男　→　Rust

こう言いたいのでは？
岡くんは。

**デフォルトの名無しさん** · 2022/09/17(土) 18:52:46.32

>>993
ってことは、2~3倍遅くても何も問題ないってことだろ。

**デフォルトの名無しさん** · 2022/09/17(土) 18:55:08.60

パイソンとかジャッカルには厨二を惹きつける響きがある。
女がなぜRubyを使いたがるのかはよく知らん。
岡くんがRust推しなのは本読んでわかった気になったから。

**デフォルトの名無しさん** · 2022/09/17(土) 18:55:32.40

>>992
C並に高速なプログラミング言語では自動メモリ解放は普通は行われない
これは例えば新世代言語であるZigなどでも同じで手動メモリ解放となる
唯一の例外が常に自動的にメモリ解放されるRust

**デフォルトの名無しさん** · 2022/09/17(土) 18:56:42.77

次スレはワッチョイ付けるよね。

**デフォルトの名無しさん** · 2022/09/17(土) 18:57:28.27

>>997
循環参照除く

**デフォルトの名無しさん** · 2022/09/17(土) 18:58:09.16

1000

**1001** · Over 1000

このスレッドは１０００を超えました。
新しいスレッドを立ててください。
life time: 19日 7時間 35分 53秒