Rust part25

**デフォルトの名無しさん** · 2024/07/31(水) 00:46:26.17

公式
https://www.rust-lang.org/
https://blog.rust-lang.org/
https://github.com/rust-lang/rust

公式ドキュメント
https://www.rust-lang.org/learn

Web上の実行環境
https://play.rust-lang.org

※Rustを学びたい人はまず最初に公式のThe Bookを読むこと
https://doc.rust-lang.org/book/

※Rustを学ぶ際に犯しがちな12の過ち
https://dystroy.org/blog/how-not-to-learn-rust

※Rustのasyncについて知りたければ「async-book」は必読
https://rust-lang.github.io/async-book/

※次スレは原則>>980が立てること

前スレ
Rust part24
https://mevius.5ch.net/test/read.cgi/tech/1716759686/

ﾜｯﾁｮｲスレ
プログラミング言語 Rust 4【ﾜｯﾁｮｲ】
https://mevius.5ch.net/test/read.cgi/tech/1514107621/

**デフォルトの名無しさん** · 2024/09/18(水) 12:51:56.38

>>906
ソース見たらコストの高いハッシュ衝突安全性を必要としない計算ベンチでそれを使っているいつもの話だった
知識がないとそういうミスをしてしまいがち
他にもVecをインデックスでシーケンシャルアクセスしたりRustに不慣れすぎ

**デフォルトの名無しさん** · 2024/09/18(水) 13:01:04.32

それより>>890ってどうなの

**デフォルトの名無しさん** · 2024/09/18(水) 13:54:44.95

>>906 >>907
HashMapはnohash_hasher、
Vecシーケンシャルアクセス(to_list内)もiterにしても遅いな

上限を10倍にして
g++ 0.542
clang++ 0.689
Zig 0.595
Rust 1.393 (nohash_hasher)

気になる人がPR出せば良いかと

**デフォルトの名無しさん** · 2024/09/18(水) 14:41:44.76

>>906
Rsutってインタープリター言語だっけ？

**デフォルトの名無しさん** · 2024/09/18(水) 15:08:51.57

>>906
Rustは二重ループ内（141行目）の
let new_prefix = prefix.clone() + &ch.to_string();
が負担になってそう
他の言語と比べてないけどcloneはいらないはず

**デフォルトの名無しさん** · 2024/09/18(水) 15:25:03.39

zigの実装に寄せるなら
let new_prefix = format!("{prefix}{ch}");
でいいのかな
全部見てないから動くか分からんけど

**デフォルトの名無しさん** · 2024/09/18(水) 15:26:20.88

>>829
これ最初マジでわかりにくかったわ
中身を借用してたんだな
C++の感覚でいたらは？ってなった

**デフォルトの名無しさん** · 2024/09/18(水) 19:11:45.89

>> 909
Go & trie-rs 追加

Go 0.845
Rust 1.306 (trie-rs)

>> 912
影響ないっぽい、ブレの範囲内だった

**デフォルトの名無しさん** · 2024/09/18(水) 22:13:43.11

>>906
意図的なのかわからないがそのコード
ZigではArenaAllocatorつまりアリーナを用いている
C++ではmonotonic_buffer_resorceつまりアリーナを用いている
Rustではなぜかアリーナが使われていない
その差が速度差となっている
前にもこのアリーナ利用の有無で速度が全く異なる話がこのスレで出ていたような

**デフォルトの名無しさん** · 2024/09/19(木) 03:23:22.25

>>915
GoはアリーナアロケータなしでRustより速い

**デフォルトの名無しさん** · 2024/09/19(木) 03:57:37.37

そもそも Rust のアリーナアロケータってなんで全部独自コンテナみたいな感じで実装されてんの？
allocator_api がまだ unstable だから？

**デフォルトの名無しさん** · 2024/09/19(木) 04:11:09.43

真面目に改善しようと思うなら、プロファイル取った上で alloc/dealloc が本当にボトルネックだったのか、そこから検証しなきゃ

**デフォルトの名無しさん** · 2024/09/19(木) 04:44:55.41

>>916
Goはガベージコレクタ依存言語だから
アリーナを使用するか否かでそれほど大きくは変わらない
特に今回はGCが起きる前に終わるため影響は限りなく小さい
アリーナを使用するか否かで非常に大きく影響を受けるのはGCを前提としない言語

**デフォルトの名無しさん** · 2024/09/19(木) 07:08:15.45

一般にガベコレ言語はalloc/freeが速い
特にfreeが速い
さらに小さなプログラムでは、遅延させたfreeを結局実行しないまま終わるのでさらに速い

**デフォルトの名無しさん** · 2024/09/19(木) 09:38:22.33

> アリーナ利用の有無
×
> アリーナを使用するか否か
×

○ Rustはアリーナアロケーターなトライ木をポンと書ける程に整備されてない

**デフォルトの名無しさん** · 2024/09/19(木) 10:26:52.55

Sorena

**デフォルトの名無しさん** · 2024/09/19(木) 12:34:03.58

アリーナ関係ない前段のsieve部分もrustが遅い

programming-language-benchmarks.vercel.app/problem/nsieve

前まで最適化に熱心だった信者がZigに移ったんかな

**デフォルトの名無しさん** · 2024/09/19(木) 12:48:12.80

またなんかできてるな
ちょっと Jetpack Compose 風味？

https://ribir.org/

**デフォルトの名無しさん** · 2024/09/19(木) 13:03:22.18

>>923
BunでZigが始まった感ある

**デフォルトの名無しさん** · 2024/09/19(木) 16:25:47.59

>>925
1.0に達してから出直してくれ

**デフォルトの名無しさん** · 2024/09/19(木) 17:04:35.08

いい加減ベンチでHashMap使うのやめてくれんかな

**デフォルトの名無しさん** · 2024/09/19(木) 17:04:45.88

>>926
1.0 を過ぎても変更だらけなのが現代やで。
セマンティックバージョニングもあてにならんしな。

**デフォルトの名無しさん** · 2024/09/19(木) 17:18:19.21

Zig 1.0 は 2025 年にリリース予定らしいので、その後はどうなるかね

**デフォルトの名無しさん** · 2024/09/19(木) 18:00:30.55

>>906のAtkin sieve部分のみ、最後10個表示(to_list処理なし、flag見て10個だけのvectorで処理)
Rust & Goはbitvect版追加

Zig 0.107
g++ 0.115
Rust 0.129 (bit-vect)
clang++ 0.131
Go 0.202 (godropbox/container/bitvector)
Rust 0.284 (Vec<bool>)
Go 0.326 ([]bool)

>>923と似た順序

**デフォルトの名無しさん** · 2024/09/19(木) 18:00:52.16

Zigはasync/awaitなどの非同期対応を捨てたまま狭い領域でやっていくのかな

**デフォルトの名無しさん** · 2024/09/19(木) 18:04:31.95

Zigはstd.DynamicBitSet
C++はvector<bool>
を使っている

**デフォルトの名無しさん** · 2024/09/19(木) 21:18:23.55

>>909 >>914
ZigのgenerateTrieの中のkey contains判定してからの(無ければputして)getをgetOrPut一発にしたら速くなった
(std.fmt.allocPrintをstd.fmt.bufPrintなどその他細かい所も変えたけど軽微)

Zig 0.433 (getOrPut)
Zig 0.595 (もともとのcontains/put/get)

**デフォルトの名無しさん** · 2024/09/19(木) 21:23:20.81

それと一番最初Zigはコンパイルエラーだったので>>909の段階でstd.TailQueueはstd.DoublyLinkedListにした

**デフォルトの名無しさん** · 2024/09/19(木) 22:39:32.91

>>115
Zigはそんな安全性無視なことをして速さを得ているの？

**デフォルトの名無しさん** · 2024/09/19(木) 23:08:32.65

範囲外チェックに突っ込むならC/C++もそうですがな
RustはC/C++ほどには速さを優先してなくて、安全性の方を重視してる
HashMapがデフォルトで「遅いけど安全」なハッシュアルゴリズムを使うのもそう

Rustが良いのは安全性や型による表現力の高さが提供されてて、その上で十分に速いところ
純粋な速さだけであれば、よりCに近いZigの方が上というのも妥当といえば妥当

**デフォルトの名無しさん** · 2024/09/19(木) 23:24:05.93

そういう方針のZigを採用する企業は極少数になりそう
アメリカ政府が安全な言語に置き換えよう！と言ってるけどZigはNG側だね

**デフォルトの名無しさん** · 2024/09/19(木) 23:46:52.22

「言語が」というだけでなく「デフォルトでは」という前提が付く。
広く使われるようになるとカスい判断をする人も出てくるし、比較的マシなほうをデフォルトにしておくのは合理的な判断だ。
Zig はまだ言語をよく理解しようとする好事家 (いわゆるアーリーアダプタ) のものであってしょうもないユーザは参加してない段階 (なので低能なユーザを考慮してない) というだけかもしれない。
状況や用途によって判断は違ってくるので単純な良し悪しでは測れない。

**デフォルトの名無しさん** · 2024/09/19(木) 23:56:50.81

ホワイトハウスの意向で今は安全な言語への移行を推奨という状況だけど近いうちにもっと厳しくなる
その時にZigの立場はない

**デフォルトの名無しさん** · 2024/09/19(木) 23:57:18.58

unsafe Rustを使う分野だとRustも安全だと言い切れなくない？
RustほどではないけどZigもCに比べれば安全なコードを書きやすいし、Better Cとしての価値は十分にあると思う
将来的に採用が増えるかは分からないけど、C開発者にとって移植しやすい・学習コストが小さいという理由でZigを選ぶケースはありそう

**デフォルトの名無しさん** · 2024/09/20(金) 00:04:52.33

いくら悪いと主張したところで低レイヤは C が支配している (OS やデバイスドライバは大抵の場合に C で書かれている) という現実があるのは変わらんからな。
過渡的な措置として (充分に安全ではなくても) C から移植しやすい言語に出番がありうるというのはわかる。

**デフォルトの名無しさん** · 2024/09/20(金) 00:12:09.61

とはいえ最近のLinuxカーネルメンテナの話とか見るに彼ら（の一部）はC以外に移行する気は一切なさそうだよね
あと組み込み系でC使っている人は多いけど、あっちはあっちでコンパイラ認証必須だったりして
Zigが使い物になるにはまだ10年とかかかりそう
そこまでZigがちゃんと生きているかというと結構難しいところなんでは…

**デフォルトの名無しさん** · 2024/09/20(金) 00:20:40.07

>>940
そのスレにいるならそろそろ学習しようよ
「unsafe Rustを使う分野」というものは存在しない
標準ライブラリがunsafeで作られているためどんな分野であろうとunsafeのお世話になる
しかしunsafeは特定の関数やモジュールに閉じ込められていてそれ以外の部分の安全性をRust(コンパイラ)が保証してくれる

新たな分野であろうとこの原理は同じ
プログラムのほとんどの部分は自動的に安全性が保証される
どうしても必要な極一部のunsafe部分のみに人間の監視リソースを集中できる
この原理によりRustは安全であるとされて選ばれている

**デフォルトの名無しさん** · 2024/09/20(金) 02:06:23.53

Republic of safe Rust

http://www.lisperati.com/landoflisp/panel57.html

警備員[Lv.30] · 2024/09/20(金) 02:10:32.66

楽になるから単価下げるねって言われたら使わないだろうな

**デフォルトの名無しさん** · 2024/09/20(金) 08:14:15.43

走行中に連結器が外れたら
そのまま走り続けるのがC言語
緊急停止がabort
そもそも外れないのがRust
でFA?

**デフォルトの名無しさん** · 2024/09/20(金) 08:19:24.68

>>940
unsafe Rust は安全だ

**デフォルトの名無しさん** · 2024/09/20(金) 08:22:06.57

>>941
> (充分に安全ではなくても) C から移植しやすい言語に出番がありうるというのはわかる。

(充分に安全な) C から移植しやすい言語(もちろんRust)を使えば良いやん

**デフォルトの名無しさん** · 2024/09/20(金) 08:26:57.74

Cから移植するのはZig
C++から移植するのはRust
明快だ

**デフォルトの名無しさん** · 2024/09/20(金) 08:36:43.29

というより充分に安全でないならわざわざCから移植する必要がないんだよな
Rustは安全というメリットがあるから移植コストを払える（人もいる）けど
Zigがbetter Cであるのはわかるけど、現実にはCを使い続ける人がほとんどじゃないかと思う

**デフォルトの名無しさん** · 2024/09/20(金) 08:41:47.73

ZigはDとかNimと同じ匂いがするんだよね
確かに便利になってる部分はいろいろあるんだけど、すでに慣れ親しんだ言語から移行するだけの強力なモチベーションがないというか

**デフォルトの名無しさん** · 2024/09/20(金) 09:54:00.87

C/C++より安全でC/++から移植し易いのはNim

**デフォルトの名無しさん** · 2024/09/20(金) 09:57:45.63

>>949
>C++から移植するのはRust
これは絶対無い断言する。
移植ではなく完全書き換えなら在り得るが移植は絶対無理。

**デフォルトの名無しさん** · 2024/09/20(金) 10:26:50.19

Rustは管理者・経営者という強力な味方がいるから、コーダーに強制するのは簡単だな。

かつてのJavaの流れになれるかどうか。

**デフォルトの名無しさん** · 2024/09/20(金) 10:47:55.86

>>942
Cプログラマ「Cで十分。はい論破！」
の世界やからな。どうしようもない。

**デフォルトの名無しさん** · 2024/09/20(金) 11:17:57.80

問題は想定しないところから出てくる。
想定されるところは対処済みだから。
想定漏れを潰すには実際に運用して、出てきた問題を潰してというループを繰り返すしかない。
実務者の考えはそういうものだ。
運用実績があることが保証の裏付けなんだよ。

Rust の保証が C に比べて強力なのはメモリアクセスまわりの違反検出くらいなので
Rust で書きなおすなら他の要素は検証しなおしになる。
OS が保証しなけりゃならないのはメモリアクセス違反がないことだけじゃないんだぞ。

**デフォルトの名無しさん** · 2024/09/20(金) 11:24:36.15

Rustは清書用(キリっ

**デフォルトの名無しさん** · 2024/09/20(金) 11:35:22.91

組み込み系はMISRA Cとかあるがお作法レイヤーだからな。
rustの場合は言語レベルの層で対応できるのがメリットでかい。

**デフォルトの名無しさん** · 2024/09/20(金) 11:36:34.54

>>941
既にデバイスドライバはRustで記述されている
わざわざRustのスレに来て批判をしたいなら現状を把握してからにしろ

**デフォルトの名無しさん** · 2024/09/20(金) 11:48:11.57

>>956
モダンな言語を使ったことがない時代遅れの人から見るとそういう間違った勘違いをしてしまいがちだけど
C言語と比較するとモダンな言語はいずれも驚くほど様々なことを保証してくれていたりミスが減ったりするよ
Rustはさらにメモリ競合なども防止してくれて強力だよ

警備員[Lv.31] · 2024/09/20(金) 12:36:21.81

バースト転送モードとかも書けるの？

**デフォルトの名無しさん** · 2024/09/20(金) 13:06:37.11

>>960
余計なことを付け足したから主旨がぶれたな。
もう一度書く。
「問題は想定してないところから出てくる」

**デフォルトの名無しさん** · 2024/09/20(金) 13:13:40.32

>>959
意味がわからん。
Linux のカーネルと大半のデバイスドライバが C で書かれている現実が存在しないというのがあなたの主張？

**デフォルトの名無しさん** · 2024/09/20(金) 13:22:45.84

>>961
どの用途の話かわからないけど何でも対応できるよ
Rustの変数を用いたインラインでのアセンブラ記述もできるのでRustは万能

**デフォルトの名無しさん** · 2024/09/20(金) 13:38:51.47

>>963
全体の文意を読まないで「デバイスドライバは大抵の場合に C で書かれている」の部分だけ拾って反応しちゃったんだと思う

**デフォルトの名無しさん** · 2024/09/20(金) 13:47:00.37

>>827
C++はそのようなデータ競合を見逃すけど
Rustはコンパイルエラーにしてくれる

let mut v = vec![0, 1, 2, 3, 4, 5, 6, 7];
let p5 = &v[5];
v.push(8);
assert!(*p5 == 5);

error[E0502]: cannot borrow `v` as mutable because it is also borrowed as immutable
|　let p5 = &v[5];
|　　　　　　- immutable borrow occurs here
|　v.push(8);
|　^^^^^^^^^ mutable borrow occurs here
|　assert!(*p5 == 5);
|　　　　　--- immutable borrow later used here

**デフォルトの名無しさん** · 2024/09/20(金) 14:22:18.97

>>966
そういうのはもうおなか一杯だから
Cで出来るのにRustで出来ないことを挙げてよ

**デフォルトの名無しさん** · 2024/09/20(金) 14:47:29.30

>>966
シングルスレッド上で同一アドレスに読み書きが発生することをデータ競合とは言わない
https://en.cppreference.com/w/cpp/language/multithread#Data_races
https://doc.rust-lang.org/nomicon/races.html

**デフォルトの名無しさん** · 2024/09/20(金) 15:06:48.25

>>827がシングルスレッドでもデータ参照に競合が起きてバグが発生している例
>>966がシングルスレッドでもデータ参照の競合をコンパイラが検出してバグを防いでいる例

**デフォルトの名無しさん** · 2024/09/20(金) 15:27:19.87

>>969
>>827のASAN実行結果
AddressSanitizer: heap-use-after-free

$ clang++ -O1 -g -fsanitize=undefined,address -fno-omit-frame-pointer main.cpp -o main
$ ./main
=================================================================
==26132==ERROR: AddressSanitizer: heap-use-after-free on address 0x...
WRITE of size 4 at 0x... thread T0
#0 0x7ff62e7716d4 in main ~/main.cpp:15:9
...

0x... is located 20 bytes inside of 32-byte region [0x...,0x...)
freed by thread T0 here:
...
#9 0x... in main ~/main.cpp:13:7
...

previously allocated by thread T0 here:
...
#7 0x... in main ~/main.cpp:5:22
...
...

**デフォルトの名無しさん** · 2024/09/20(金) 15:35:56.11

このようにC++だとサニタイザーで実行するまでわからない
レアケースで発生するものだと実行しても何日間も見つからないこともある
そして本番へ投入してレアケースが発生して大惨事となる
つまりサニタイザーでは本質的な解決にならないのだ
Rustのように実行せずともコンパイル時に確実に判明することが正しい解決策だ

**デフォルトの名無しさん** · 2024/09/20(金) 15:36:26.98

>>827のような操作がバグかどうかは状況による
Rustがやってるのはバグと見做されるような挙動を生みやすいパターンを弾く安全側のアプローチ
言語によっちゃ同名変数の宣言によるシャドウイングを禁止してたりするが、それと似たようなもんだ

**デフォルトの名無しさん** · 2024/09/20(金) 15:41:33.93

>>972
開放された無効領域を指すダングリングポインタとなっている>>827は明確なバグ
セキュリティホールにもなりうる深刻なバグ

**デフォルトの名無しさん** · 2024/09/20(金) 15:51:51.16

>>973
それはpush_backの実装がたまたま領域を解放しうるから結果的にバグなだけで、
Rustのチェックがそこまで考慮してこのエラーを出しているわけじゃないでしょ
安全側に倒した結果としてたまたまバグを検出できた例と考えるのが適切

**デフォルトの名無しさん** · 2024/09/20(金) 15:51:55.07

>>959
政治的な理由でマージされないなら、それは記述されているとは言えない

**デフォルトの名無しさん** · 2024/09/20(金) 16:13:04.26

>>966,971が裏でJS/TS書いてると思うとほっこりする

**デフォルトの名無しさん** · 2024/09/20(金) 17:24:13.84

>>974
結果的も何も、たまたまも何もバグじゃん。
バグは早期に発見できるほうがいいだろ。

**デフォルトの名無しさん** · 2024/09/20(金) 18:37:17.32

>>974
↑こういう認識だからいつまでたってもバグがなくならない
主要なOSやブラウザで毎年数千単位の脆弱性が出てる現実を分かってない

**デフォルトの名無しさん** · 2024/09/20(金) 18:46:47.16

今rustでグラフィックスプログラミングって実用的？
dx12とかvulkanとか
いい加減c++捨てたいと思ってるけどrustで性能でないなら使えない

**デフォルトの名無しさん** · 2024/09/20(金) 18:57:32.01

>>974
一般的に参照を保持したままそのデータへの別の可変参照が用いられる(＝データが書き換わる)と
意味論的に最初の参照が期待していたものと異なるデータ状態になっている可能性があるためバグの発生要因となる
その例のうち最も極端なものがデータがメモリ開放されてしまっているベクタ伸長による自動メモリ移動の例
もちろんメモリ開放を伴わなくてもデータの状態が変わってしまって意味論的に食い違いが起きることでのバグが生じる
特に複雑な状況だとその食い違いが起きていることを人間が把握しきれなくなり見落としてしまう
Rustではそのようなデータ参照の競合を検出してコンパイルエラーにしてくれるため安全である

**デフォルトの名無しさん** · 2024/09/20(金) 19:02:50.08

>>977,980
Rustはコンパイルが超遅いから、Rustがコンパイルエラーを吐くより先に、C++がコンパイルとサニタイザー検出を終えてるだろ

**デフォルトの名無しさん** · 2024/09/20(金) 19:28:29.22

>>981
サニタイズはプログラムを実行しなければならず更に問題が発生する条件がたまたま揃うまで無限に待たなければいけない
したがって必ずしも問題が検出できるとは限らない非常に劣った方法
しかも対象領域がメモリ問題などいくつかに限られた項目のみ
Rustはデータ参照競合を一般的にコンパイル時点で確実に検出できる

**デフォルトの名無しさん** · 2024/09/20(金) 19:54:50.23

>>982
データ競合の間違い指摘でデータ参照競合と言い出す奴

**デフォルトの名無しさん** · 2024/09/20(金) 20:22:52.87

>>909 >>933
C++も速くなった

g++ 0.406 (martinus/unordered_dense, try_emplace他)
Zig 0.433 (getOrPut他)
g++ 0.542 (元々のpmr::unorderd_map, find/emplace)
Zig 0.595 (元々のcontains/put/get)

**デフォルトの名無しさん** · 2024/09/20(金) 20:25:25.31

>>930
C++ boost::dynamic_bitsetも試したけど効果なかった
起動終了時間も含んでいるからその違いでZigと差が付いている可能性はありそう

**デフォルトの名無しさん** · 2024/09/20(金) 20:32:05.98

>>951
現状はドキュメントが直ぐに古くなってソース見ることになる
とりあえずC/C++より速いとなると原因を探すきっかけに出来るベンチマーク言語

**デフォルトの名無しさん** · 2024/09/20(金) 20:37:14.78

>>982
> Rustはデータ参照競合を一般的にコンパイル時点で確実に検出できる

「データ競合」の誤用はさておき、このたった一文のために unsafe Rust は決して健全性を破壊しないように書かれなくてならないのですが
safe Rust の健全性保証を一切受けられないその開発者たちは、一体どうやって検証していると思っているんですか？

unsafe ライブラリ開発者のこと、ちゃんとリスペクトしてますか？

**デフォルトの名無しさん** · 2024/09/20(金) 21:14:33.29

>>987
unsafeブロック内でも借用(参照)関係のルールは同じ

**デフォルトの名無しさん** · 2024/09/20(金) 21:23:28.17

>>979
WGPU

**デフォルトの名無しさん** · 2024/09/20(金) 21:28:48.15

次スレよろ

**デフォルトの名無しさん** · 2024/09/20(金) 22:02:42.38

次スレ
https://mevius.5ch.net/test/read.cgi/tech/1514107621/

**デフォルトの名無しさん** · 2024/09/20(金) 22:22:54.89

次スレ

Rust part26
https://mevius.5ch.net/test/read.cgi/tech/1726838318/

**デフォルトの名無しさん** · 2024/09/20(金) 22:27:40.78

>>975
既にマージされている
LinuxではデバイスドライバもカーネルモジュールもRustで誰でも記述することができる環境が整備されており動作している

**デフォルトの名無しさん** · 2024/09/21(土) 06:57:11.60

>>993
マージされてないって聞いたんだが？

**デフォルトの名無しさん** · 2024/09/21(土) 07:19:00.02

rust for linuxのトップメンテナーが一抜けしたよな
いわくnontechnical nonsenseなことに飽きただと
言語変えても何か新しい機能が作れるわけじゃないからな
熱量は下がってる

**デフォルトの名無しさん** · 2024/09/21(土) 08:01:00.78

>>994
とっくにマージされている
誰でも作れるようになったため
「RustでLinuxカーネルモジュール」を作った日本語の記事もたくさんあるのでどうぞ

**デフォルトの名無しさん** · 2024/09/21(土) 09:01:51.68

Linuxの新たな機能やデバイスドライバが次々とRustで書かれるようになってきたね

**デフォルトの名無しさん** · 2024/09/21(土) 09:23:20.76

安全性には新しさがないと？
敵に危害を加えると新しさを感じて熱量が上がる理由がそれなのか

**デフォルトの名無しさん** · 2024/09/21(土) 09:51:32.91

RustはCVE出している時点で安全性の新しさはないな

**デフォルトの名無しさん** · 2024/09/21(土) 09:52:42.78

しかもRust製のTauriがCVE出してるのが安全性の新しさがない証明になっている

**1001** · Over 1000

このスレッドは１０００を超えました。
新しいスレッドを立ててください。
life time: 52日 9時間 6分 17秒