Rust part23
■ このスレッドは過去ログ倉庫に格納されています
>>242
だからデフォルトなんかいらないんだよ
ハッシュごとき使うのにデフォルトがないと使えないような人間がcratesの名前空間を埋めていくのはヤバいよ >>243
ほとんどの言語の連想配列(hashmap)のハッシュ関数はデフォルトがありますよ
指定しないと使えない言語がもしあるとしてもレアじゃないですか？ >>244
それはJavaScriptやPythonのような馬鹿がライブラリを書いて馬鹿が馬鹿の再生産をすることを推奨している言語の話でしょう？
もしくは仕様だけ緩く決めて実装には何の責任も取らない言語か スクリプト言語だと速度は求められないという了解があるし Rust や C++ の思想でいう速さはゼロコスト抽象のことだよ。
抽象化にはコストはない (または十分に小さい) が実行すれば実行内容に相応の実行コストが生じるのは当たり前のことだし、実行内容を最小限にすることを目指したって単に不便になるだけだ。 あらゆる言語のあらゆるプログラムについて以下が成り立つ
【必須】信頼できない外部入力データに対しては攻撃に強いハッシュ関数を用いなければならない
【自由】そうでないデータに対してはどのハッシュ関数を用いてもよい
この状況で安全な言語はデフォルトとして攻撃に強いハッシュ関数が適切
そして後者と判断できるプログラマーのためにハッシュ関数を指定できる仕様が適切
Rustはこの適切な仕様となっている 外に出るときはヘルメットを被って110をすでに入力したスマホを持ちながらおむつをしてコンドームつけてるのがRust デフォルトとFxHasherで比較してみたけどHashMapへのinsertのみで実行時間1.7倍
現実のプログラムだとそれ以外の部分が大量にあるためそれ次第で誤差だね
これはデフォルトが安全側に倒す形を取っていて正解と思う >>248
>【自由】そうでないデータに対してはどのハッシュ関数を用いてもよい
いやーそれはどうだろう？
ハッシュDoS耐性は不要でも例えばFxHashを使うべきじゃないユースケースも普通にあるよね？
stdに1つしかHasherが用意されておらずサードパーティ頼みな現状は言語的には結構不親切 hash自体は基本的にアホでも作れる
それが適切なのかどうかは不明 Rustはデフォルトハッシュ関数が用意されていておかしいと言うけど
すべての言語で用意されてるでしょ？
Rustは様々なハッシュ関数が標準ライブラリにないと言うけど
それが普通でしょ？
さらにRustの標準ライブラリはなるべく小さくする方針ね >>255
ここまで読んでそういう解釈になってるなら理解する力が足りてない
重いハッシュ関数がデフォルトになってるのがどうなのかと言う話 普通に考えて攻撃に強いハッシュ関数がデフォルトとなってるのがベストだよね
攻撃の可能性のない部分のみを後でチューンアップつまり弱いハッシュ関数で置き換えるだけだから
これより良い策があるの？ >>258
バカなの？
それだとチューンアップする前が攻撃耐性ないじゃん 江戸時代士農工商の身分制度があって
雨の日だけ農民も下駄を履いてよかった みんなの言語思想発表会をするのはいいけどRustをそれに巻き込むなよ IDコロコロ全肯定君
攻撃されるかもしれないのに攻撃の耐性をつけてない人に
対するフールプルーフのために一律全てのコードを遅くする
そもそもその人が設計ミスってるんだろう SafeSlowHashMapみたいな名前にすれば良いのに >>264 >>265
Rustを使ったことすらない人が文句を言ってるのか
RustのHashMapはHasherに対しても多相であり型パラメータでHasherを指定する >>266
HashMap::new()すらしたことないのかな？ >>266
誰もそんな話してないやろ
これだから複クンは こいつは結論が先にあってRustのすべてが正しいから後で理屈をつけているだけ
いつもおかしなことを言ってる ripgrepとかuvとかの既に実用が始まってるRust製アプリでは
デフォルトのハッシュ関数使ってるの？ >>267
やっぱりRustを使ったことないんだな
impl<K, V, S> HashMap<K, V, S>にfn new()は存在しないため
HashMap::<Key, Value, BuildHasherDefault<Hasher>>::default()のように使う ほらこんな壊れたレスしかできないんだよ
脳が死んでる いつもRustを叩いてRustスレを荒らしてるアンチの言動はいつもワンパターン
今回のHashMapの件で例えると
もしデフォルトのハッシュ関数が安全でなく速いものだと「Rustはデフォルトが安全でない！」と叩く
もしデフォルトのハッシュ関数が安全で遅いものだと「Rustはデフォルトが遅い！」と叩く
どちらになっていても叩くことが目的のキチガイ 「俺が高速なプログラムを作れるのは言語のおかげ」は合ってるが
「俺が低速なプログラムしか作れないのは言語のせい」は間違ってる 『「俺が低速なプログラムしか作れないのは言語のせい」は間違っている』という立場、ユーザーが充分賢いことを仮定しているのでそれならPythonとC++で良い ほんとどうでもいいな
自転車置き場というより豚小屋の議論 プログラムしかしない人はこういうことしか考えることがないんよ 知識があれば高速化が可能な場合があるのは、言語や項目に関わらず一般的な話。
安全方針のRustとしては、ハッシュ衝突強度を知らなくてもデフォルトで安全がベター。 デフォルトいらんが
ハッシュも自分で選べんガイジがハッシュマップ使うな >>279
わかってなさそうなので再度書くけど
ハッシュ衝突強度が高いからと言ってハッシュDoS耐性が高いとも限らないしHashMapに適してるとも限らないからね 弱いハッシュでも困るようなプログラム書く人は、自分で判断できるんじゃないの？デフォルトはパフォーマンス優先で良いと思うけどな。 攻撃で困るかどうか攻撃されるまで初心者は判断できないと思う。
そして攻撃されてから対処するのでは遅いかもしれない。
パフォーマンスチューニングは遅いことが問題になってからやるので深刻ではなかろう。 RustのDefaultHasherは安全かつパフォーマンスのいいSipHashを使っているので普通は気にする必要ない
もちろんPythonやJavaScript(v8)やSwiftなど多くの言語がこのSipHashを使っている
そのうえでRustは必要とするHashMap毎にFxHashなどさらに高速なものを簡単に指定できる Pythonはハッシュ値計算したらオブジェクトに保存してるでしょ 他の言語たちがRustを参考に同じように後追いしているのね
＞Pythonの文字列やバイト列に対するハッシュアルゴリズムは、HashDoS対策としてPython 3.4から SipHash24が使われていました。
＞その後、ラウンド数を減らしたSipHash13でも十分に安全だとして2015年にRustが、2016年にRubyが、SipHash24からSipHash13への切り替えを行いました。
＞Rust や Ruby からは数年遅れましたが、Pythonもデフォルトの文字列ハッシュアルゴリズムがSipHash13に切り替わりました。 >>286
常にそれをされたら困るが
Rustでもハッシュ値をオブジェクトに持つstring_cacheなどが用途に応じて使われている >>274
人にキチガイと言う前に自分の脳を使って考えたら？
どちらになっても叩くことはないだろ
他の言語はデフォルトで速いハッシュを使ってるよ 他の言語もRustと同じハッシュ関数を用いていることが判明したのにRust叩きを続ける一匹 他の言語の例としてPythonやRubyのような遅いこと前提でとにかく初心者が書いても動けば良いという思想の言語を持ち出してくるのはおかしいでしょう >>283
判断できない人まで言語側で救う必要性が分からない。
それなら、unsafeもカジュアルに使えないように仕掛けを用意した方が良いんじゃないかと。 必要なことしかやりませんって言語は他にあるからそちら使えばいいのでは？ 安全と速度は両立するかそれともトレードオフか
トレードしかしない人にとって、コストは支払うと決めたら絶対にキャンセルできない印象があるよね
有償かと思ったけどよく考えたらやっぱゼロコストだったという現象は許せない Rustなんかに手を出すのはC++まともに書けない馬鹿なんだから、「充分賢ければ速く書ける」は実質「速く書けない」なんだよな
賢いならRustなんかやらない 自由があればデフォルト設定を強制されないのは自明な事実
ただし、賢い人間が自由を所有しているのか、道具自体が自由度を持っているのか
そもそも「所有している」というのはただの感想なのか客観的事実なのか アホ vs バカの不毛な争いが続くのは隔離スレにﾜｯﾁｮｲつけたやつの責任だからな 本スレにワッチョイつけず隔離スレと称して余計なスレ立ててそっちにワッチョイつけるバカども。
5chでRust使ってるって言ってるやつらはそんなもの 不毛の判断が早いなあ
後世の歴史家が判断するという定型文に縛られないから早いんだな 安全と速度を両立させたのが
RustやPythonなどが採用しているSipHash13 >>295
いや、unsafeは判断できる人が使うものだろ。 >>300
分かってるんならﾜｯﾁｮｲ付きRustスレの盛り上げに協力してくれんかえ ワッチョイなんか盛り上がる訳ねえ
そんな話題あったらこのスレに投下してつまらない議論を流した方が余程生産的 高齢化でコーディングできなくなったおじいさんを叩くのは良くないと言う話 30後半でコーディングしてるやつなんて9割コミュ障で出世できなかったやつだろ 能力が低下してコーディングできないのとしないのでは大違い 結局スクリプト言語で書かれた原作が必要か
他のジャンルでも原作なしのオリジナルは難しそうだろう Rustで書き直してパフォーマンスが上がったので注目浴びる！みたいなプロダクトはなんか白けるよな。
JSとかPythonの基盤ツールをRustで書き換えて激速！みたいなのはもう汎用言語としてのアイデンティティ捨てられててオワットル。 日本みたいに、何とかするには人投入しよう！スキルどうでもいいからとにかく人集めて！なところじゃね～。 おそらく植山類が新しいリンカを作ったあたりが開発ツール高速化の機運の始まりだと思う。
歴史的事情でごちゃごちゃしてて遅いのが仕方がないと思われていたものについて
速度を意識して書いてみたら数百倍単位で速くなってわひゃーーというのが強烈なインパクトだった。
(それは C++ で書かれてるんだけどね。)
商売で開発ツールを提供している会社にとっては少なくともそれと同程度のものを出さないと面子が立たない。
リンカを作ってるところはこぞって高速化に努めた。
リンカ以外にもその機運が波及しているのが今。
で、高速化のキモはデータ構造であるというのが明瞭になったんだけど
メモリ管理の部分を処理系 (ランタイムサポート) の側でやるようなものだとそこんところのチューニングが出来ない。
Rust である必然性が強いわけではないけど C++ とかよりは今なら Rust のほうがいいかなってのはまあ自然な判断ではある。 コードを書けない
プログラムできなくなるとこういうことしか書けなくなると言う見本 だが読むより書くほうが優れているという前提から
原作を正しく読解するよりも正しくない二次創作のほうが優れているという結論が出てくる >>315
辛辣で草
そういう似非技術者系おじいちゃんおちょくると
怒って自分が唯一知ってる知識振り回してくるから面白いぞ Rustコードを書けない似非技術者系おじいちゃんたちは他のスレでやりとりしなさい
ここはRust専用スレ コーディングが出来なくなると人生はつらいと思うけどな… できなくなるんじゃなくて
元々できてないんよね>>314みたいな人は
というより単に職業マじゃないのかもな
趣味でプログラム触ったことあるパソコン少年的な 人はいつか何もできなくなって死んでいくんだよな
つまらないね 肉屋がレッドオーシャンになれば豚はブルーだからこれでいい Rustで書けば速くてリソースコスト下げられるうえに保守性も良くていいことずくめだからだな
ただしまともなプログラマーしか使い こなせない 無効なアドレスを参照しない
運が良ければSegmentation Fault、運が悪ければ変な値が使われて何か起こる
無効なアドレスを更新しない
運が良ければSegmentation Fault、運が悪ければそこの値が壊れて何か起こる
メモリリークは割とどうでもいい >>330
メモリ安全性のうち特に重要な一つがメモリ競合の安全性
まだ使っている値を意図せずに書き換えてしまい矛盾してしまう
プログラミングで起こるバグの代表的な一つ
Rustではこれを防ぐことができる >>331
ありがとう
「運が悪ければ変な値が使われて何か起こる」
そういえばメモリの概念理解せずにC言語使って、動かすたびに結果がかわるバグプログラム生み出してビビリ倒したことを思い出しました…… >>332
ありがとう
「運が悪ければ変な値が使われて何か起こる」
そういえばC言語の現在時刻取得関数がポインタ返し&参照先書き換えるタイプの関数だったので大ハマリしたことありますね… WebAssemblyバイナリの実行環境を提供する「Rust」で作成されたランタイム「Wasmi」に脆弱性が明らかになった。
ttps://www.security-next.com/154875 デフォルトで制限よりも多くのパラメーターを指定すると域外に書き込みを行うおそれがある「CVE-2024-28123」が明らかとなった。
2023年12月にリリースされた「同0.31.1」にて脆弱性は修正された。
パラメーターが128個以下であることを確認する回避策についてもアナウンスしている。 >>336
そういうのRust関係ないからわざわざここに書かなくてもいいよ 関係無いわけないでしょｗ
rustで書かれてたら安全なんじゃなかったん？ｗ ガベージコレクションのあるスクリプト言語であるPythonですら脆弱性でCVE出まくってるよ unsafe使用箇所だからメモリ安全の外だろうな
インタプリタのスタックフレーム参照で毎回境界チェックする実装も微妙だししゃーない ■ このスレッドは過去ログ倉庫に格納されています
