Rust part23

**デフォルトの名無しさん** · 2024/02/23(金) 17:37:52.13

公式
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 part22
https://mevius.5ch.net/test/read.cgi/tech/1705760500/

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

**デフォルトの名無しさん** · 2024/02/29(木) 14:51:42.06

技術的選択は突き詰めれば必ずトレードオフが生じるもの
利点だけを見て欠点に目をつぶったまま良し悪しを論じるのは愚の骨頂

**デフォルトの名無しさん** · 2024/02/29(木) 14:52:32.46

Rustの方式の利点は>>180に挙げられているから
もし仮にRustより良い言語が存在するならその言語の方式の利点を挙げればいいんじゃね？

**デフォルトの名無しさん** · 2024/02/29(木) 15:05:04.64

>>191
>それは「批判するなら代案出せ」と同じ議論を潰すだけの態度なのでやめよう
議論を潰すというよりも批判から逃げたいだけだろう

**デフォルトの名無しさん** · 2024/02/29(木) 17:17:49.66

物的な代案や物的証拠により人の心を折ることが検証だと思っているんじゃないか

**デフォルトの名無しさん** · 2024/02/29(木) 17:44:22.90

や、そもそも「人の心」の認識が無いのだろう

**デフォルトの名無しさん** · 2024/02/29(木) 18:01:07.55

わざわざRustスレにまでやって来てRust叩きやってる人だから心の病気なのかもな

**デフォルトの名無しさん** · 2024/02/29(木) 18:25:15.72

>>167
>&&T→&Tの場合
これ調べてみたんだけどビルトインderefが優先的に動いて
Deref for &Tの実装は使われてなかった

**デフォルトの名無しさん** · 2024/02/29(木) 18:37:38.45

ビルトインは*を明示指定しないといけなくない？
coercionは何も指定しなくてもDeref実装があれば自動的に多段に適用してくれるけど

**デフォルトの名無しさん** · 2024/02/29(木) 20:49:33.50

impl Deref for &T
はtrait境界を満たすためだけに定義されてるんだろうな
標準だとDeref境界はPinくらいしか使ってないけど

**デフォルトの名無しさん** · 2024/02/29(木) 23:55:24.58

>>199
*演算子のときもDeref CoercionのときもビルトインderefがDeref::derefよりも優先して使われるよ

**デフォルトの名無しさん** · 2024/03/01(金) 08:46:23.47

derefの仕方は状況によって使い分けかな
例えばVec<T>からスライス&[T]にする場合

// deref operatorを使う方法
// 一番短く頻出
let slice = &*vec;

// RangeFull Indexを使う方法
// Rangeを変えて汎用的に範囲指定ができるメリット
let slice = &vec[..];

// deref coercion先の型を明示する方法
// 関数呼び出しは引数の型が明記されてるのでこのパターン
let slice: &[T] = &vec;

// deref()メソッドを使う方法
// ただしDerefトレイトのuseが必要
use std::ops::Deref;
let slice = vec.deref();

**デフォルトの名無しさん** · 2024/03/01(金) 09:18:59.78

uv、めちゃ速いな
今までの処理時間はなんだったのか
これはRustの印象を良くするツールになるわ

**デフォルトの名無しさん** · 2024/03/01(金) 10:14:36.96

uvというとCで書かれた非同期マルチプラットフォームライブラリ(Rustにはmioがある！)が有名だが
そのuvはRust製のPythonパッケージマネージャーなのか

**デフォルトの名無しさん** · 2024/03/01(金) 11:06:37.60

速さの定義はわかりやすさの定義よりもわかりやすい

**デフォルトの名無しさん** · 2024/03/01(金) 16:15:12.75

JavaScriptでも遅いBabelを速いSWC(Rust製)に換えると爆速

**デフォルトの名無しさん** · 2024/03/01(金) 19:02:46.24

Pythonの管理ツールまたなんか出たの！？という気分

**デフォルトの名無しさん** · 2024/03/02(土) 00:14:54.94

uvはPython版のcargoを目指しているらしい

**デフォルトの名無しさん** · 2024/03/02(土) 16:13:07.16

nvidiaのど汚なさを理解してなさげで不安しかないわ

**デフォルトの名無しさん** · 2024/03/05(火) 04:09:58.03

RustでDB使う時の定番ライブラリって何ですか？

**デフォルトの名無しさん** · 2024/03/05(火) 04:14:48.62

ORMが好きならdiesel
ORMが嫌いならsqlx

**デフォルトの名無しさん** · 2024/03/05(火) 06:15:07.43

>>211
それRDBじゃん

**デフォルトの名無しさん** · 2024/03/05(火) 11:41:51.93

RDBじゃないDBの定番とか聞かんだろJK

**デフォルトの名無しさん** · 2024/03/05(火) 12:54:04.64

RDBMSが定番だからね。

**デフォルトの名無しさん** · 2024/03/05(火) 23:56:12.66

最近RDB以外のDBの存在を知った人にありがちな反応だよな

**デフォルトの名無しさん** · 2024/03/07(木) 15:14:21.16

Rustで一通り文法や機能紹介した入門書の次に読むような定石本ってどのようなのがありますか？C++でいうEffective C++みたいな

**デフォルトの名無しさん** · 2024/03/07(木) 15:28:53.82

しゃぶれよ

**デフォルトの名無しさん** · 2024/03/07(木) 17:13:51.21

>>216
Rust for Rustaceans

**デフォルトの名無しさん** · 2024/03/10(日) 13:14:05.30

Rustはデフォルトのhashが遅いという罠

**デフォルトの名無しさん** · 2024/03/10(日) 20:35:08.28

>>219
Rustはデフォルトのハッシュ関数が最強最善の暗号学的ハッシュ関数であるSipHashを採用しているため衝突にも強くハッシュDOS攻撃に対しても安全
もし強い衝突耐性を必要としない用途ならばFxHasherなどの速さ重視のハッシュへと簡単に置き換えられる

type Hasher = std::hash::BuildHasherDefault<FxHasher>;
let mut map = HashMap::<Foo, Hasher>::default();

**デフォルトの名無しさん** · 2024/03/10(日) 20:38:28.49

こうね
HashMap::<Key, Value, Hasher>

**デフォルトの名無しさん** · 2024/03/10(日) 21:21:36.22

解決案としてはそうなのだが、デフォルト挙動が罠すぎる
デフォルトいらなかったのでは

**デフォルトの名無しさん** · 2024/03/10(日) 21:26:04.39

Rustは利用者はアホだと思ってる
だから徹底的に厳しくしてくる

**デフォルトの名無しさん** · 2024/03/10(日) 21:33:53.98

雨が降ってなくても傘を持つように言って来て外出すらさせてくれない

**デフォルトの名無しさん** · 2024/03/11(月) 00:11:06.91

デフォルトのハッシュ関数が遅くて困るってことはよく知らずに使ってたってことでしょ？
そう考えると初心者向けにデフォルト厳しくしておくのは正解な気がするわ、セキュリティに関わるし
まあ言語側はそんな事考えずにとにかく一番スタンダードなものデフォルトにしろって考え方もわかるが

**デフォルトの名無しさん** · 2024/03/11(月) 00:47:18.65

Rustはimpl std::hash::Hasherで必要なら自由に独自のハッシュ計算器をすぐ作れるし
逆にそれと独立にimpl std::hash::Hashで自分の各型に対してハッシュ計算法を指示できるし
この2種類のトレイトを標準で用意してくれているRustは非常に好環境

**デフォルトの名無しさん** · 2024/03/11(月) 00:59:26.53

「最悪の場合でもほどほど」なやつをデフォルトにするのは妥当だと俺も思う。
状況に合わせて選択できたり自分で作れたりする人はそうするんだから、
デフォルトではそうでない人を想定するだろ。

**デフォルトの名無しさん** · 2024/03/11(月) 02:43:53.87

いやそもそもデフォルトいらんくね？
なんでデフォルト欲しいんだ？

**デフォルトの名無しさん** · 2024/03/11(月) 11:06:00.19

掃除機はAI搭載して吸ってはいけないものを吸ったら止まってくれよ

**デフォルトの名無しさん** · 2024/03/11(月) 11:06:34.84

誤爆した！

**デフォルトの名無しさん** · 2024/03/11(月) 14:30:36.32

デフォルトを用意するかしないかは言語思想によるから正解不正解では語れないよな
rustの場合は何事も「安全」に基づいて設計されてると認識してる

**デフォルトの名無しさん** · 2024/03/11(月) 15:25:18.07

適切なハッシュ関数を選択するのってそんな簡単なことじゃないからな
ハッシュ関数の特性だけじゃなくhashbrownの特性も知らないといけないしその両方を組み合わせた際のハッシュDoS耐性の程度も評価できないといけない

HashMapのように基本的なデータ構造を使うのにどんな場合でもいちいちユーザーがその選択しなきゃいけないようだと辛すぎるわな

**デフォルトの名無しさん** · 2024/03/11(月) 19:01:47.22

HashMapで使われるHashに重いものを使う必要がある局面は限られてる
でも他人のライブラリの外から必要な時にハッシュアルゴリズムを変えることなんかできないので悩ましい人もいるだろう

**デフォルトの名無しさん** · 2024/03/11(月) 20:05:38.98

僕が美少女とセックスするためのプログラムはRustで作れますか

**デフォルトの名無しさん** · 2024/03/11(月) 21:13:52.07

>>233
ライブラリを作成する時にその用途に応じた適切なハッシュを用いればよい
用途により異なるならば安全側に倒すか指定する方法を提供すればよい

**デフォルトの名無しさん** · 2024/03/11(月) 21:28:56.93

とりあえずデフォルトを使って、必要になったら差し替えればいいんじゃないの？
Rustだとなんか問題あるんだっけ？

**デフォルトの名無しさん** · 2024/03/11(月) 21:31:16.84

>>236
ライブラリのハッシュを差し替えられない
デフォルトハッシュを使うような人間がどんどん参戦してきてcratesの名前空間を埋め尽くしていく

**デフォルトの名無しさん** · 2024/03/11(月) 21:41:07.80

ハッシュ衝突強度安全性が必要かどうかの判断ができない者がRustデフォルトの安全なものを用いることになるのは正しい
そこまで必要としない用途であると判断できた者だけがFxHashなどを用いればいい
RustコンパイラもFxHashを用いている
https://github.com/rust-lang/rustc-hash

**デフォルトの名無しさん** · 2024/03/11(月) 21:44:11.78

安全で高速を名乗ってるくせにライブラリがおっせえ言語だなあ
これ治すにはいちいち依存ライブラリ全てをcloneしてきてチマチマ変更していかないといけないってマジかよ

**デフォルトの名無しさん** · 2024/03/11(月) 22:02:54.43

言語とは関係ない
外部からのデータを扱うなど攻撃耐性など必要となる部分には攻撃耐性のあるハッシュが必須
そうでない部分には攻撃耐性は必要ない
各プログラムの中にこれら両者はは共存しうる
この使い分けができているかどうかは各言語の問題ではない

**デフォルトの名無しさん** · 2024/03/11(月) 22:17:15.26

ライブラリやその管理が言語と関係がないとする主張は可能だが、その主張をするとcargoやcratesの存在が言語と関係ないことになり、Rustの良さを支えている理由の大きな割合を失うことになる
やはりエコシステムやそこにある資産も含めての言語の評価だろう

それにユーザーの問題を言語が引き取らないのであればコードを書く人が充分賢いことを仮定することになり、C++で良いということになる

**デフォルトの名無しさん** · 2024/03/11(月) 22:22:30.50

>>241
C++だけでなくスクリプト言語であろうがすべて同じ
攻撃耐性が必要となるところで強度の高いものが使われてなければ欠陥プログラム

**デフォルトの名無しさん** · 2024/03/11(月) 22:24:26.89

>>242
だからデフォルトなんかいらないんだよ
ハッシュごとき使うのにデフォルトがないと使えないような人間がcratesの名前空間を埋めていくのはヤバいよ

**デフォルトの名無しさん** · 2024/03/11(月) 22:32:51.13

>>243
ほとんどの言語の連想配列(hashmap)のハッシュ関数はデフォルトがありますよ
指定しないと使えない言語がもしあるとしてもレアじゃないですか？

**デフォルトの名無しさん** · 2024/03/11(月) 22:38:01.21

>>244
それはJavaScriptやPythonのような馬鹿がライブラリを書いて馬鹿が馬鹿の再生産をすることを推奨している言語の話でしょう？
もしくは仕様だけ緩く決めて実装には何の責任も取らない言語か

**デフォルトの名無しさん** · 2024/03/11(月) 22:39:37.27

スクリプト言語だと速度は求められないという了解があるし

**デフォルトの名無しさん** · 2024/03/11(月) 22:53:49.00

Rust や C++ の思想でいう速さはゼロコスト抽象のことだよ。
抽象化にはコストはない (または十分に小さい) が実行すれば実行内容に相応の実行コストが生じるのは当たり前のことだし、実行内容を最小限にすることを目指したって単に不便になるだけだ。

**デフォルトの名無しさん** · 2024/03/11(月) 23:24:30.57

あらゆる言語のあらゆるプログラムについて以下が成り立つ
【必須】信頼できない外部入力データに対しては攻撃に強いハッシュ関数を用いなければならない
【自由】そうでないデータに対してはどのハッシュ関数を用いてもよい

この状況で安全な言語はデフォルトとして攻撃に強いハッシュ関数が適切
そして後者と判断できるプログラマーのためにハッシュ関数を指定できる仕様が適切

Rustはこの適切な仕様となっている

**デフォルトの名無しさん** · 2024/03/11(月) 23:26:28.61

雨の降らない日に傘をさしてるのがRust

**デフォルトの名無しさん** · 2024/03/11(月) 23:31:49.34

外に出るときはヘルメットを被って110をすでに入力したスマホを持ちながらおむつをしてコンドームつけてるのがRust

**デフォルトの名無しさん** · 2024/03/11(月) 23:39:22.87

雨が降る日のためにいつでも傘をさしてるだけだろ…

**デフォルトの名無しさん** · 2024/03/11(月) 23:47:29.47

デフォルトとFxHasherで比較してみたけどHashMapへのinsertのみで実行時間1.7倍
現実のプログラムだとそれ以外の部分が大量にあるためそれ次第で誤差だね
これはデフォルトが安全側に倒す形を取っていて正解と思う

**デフォルトの名無しさん** · 2024/03/11(月) 23:47:55.83

>>248
>【自由】そうでないデータに対してはどのハッシュ関数を用いてもよい
いやーそれはどうだろう？
ハッシュDoS耐性は不要でも例えばFxHashを使うべきじゃないユースケースも普通にあるよね？

stdに1つしかHasherが用意されておらずサードパーティ頼みな現状は言語的には結構不親切

**デフォルトの名無しさん** · 2024/03/11(月) 23:55:39.88

hash自体は基本的にアホでも作れる
それが適切なのかどうかは不明

**デフォルトの名無しさん** · 2024/03/11(月) 23:59:34.73

Rustはデフォルトハッシュ関数が用意されていておかしいと言うけど
すべての言語で用意されてるでしょ？

Rustは様々なハッシュ関数が標準ライブラリにないと言うけど
それが普通でしょ？

さらにRustの標準ライブラリはなるべく小さくする方針ね

**デフォルトの名無しさん** · 2024/03/12(火) 00:02:16.02

>>255
ここまで読んでそういう解釈になってるなら理解する力が足りてない

重いハッシュ関数がデフォルトになってるのがどうなのかと言う話

**デフォルトの名無しさん** · 2024/03/12(火) 00:06:26.32

普通に考えて攻撃に強いハッシュ関数がデフォルトとなってるのがベストだよね
攻撃の可能性のない部分のみを後でチューンアップつまり弱いハッシュ関数で置き換えるだけだから
これより良い策があるの？

**デフォルトの名無しさん** · 2024/03/12(火) 00:07:45.67

攻撃の可能性のある部分をチューンナップ

**デフォルトの名無しさん** · 2024/03/12(火) 00:10:05.78

>>258
バカなの？
それだとチューンアップする前が攻撃耐性ないじゃん

**デフォルトの名無しさん** · 2024/03/12(火) 00:10:10.84

江戸時代士農工商の身分制度があって
雨の日だけ農民も下駄を履いてよかった

**デフォルトの名無しさん** · 2024/03/12(火) 00:11:17.84

>>259
攻撃されないのに攻撃態勢をつける馬鹿

**デフォルトの名無しさん** · 2024/03/12(火) 00:13:45.61

みんなの言語思想発表会をするのはいいけどRustをそれに巻き込むなよ

**デフォルトの名無しさん** · 2024/03/12(火) 00:15:25.47

IDコロコロ全肯定君

攻撃されるかもしれないのに攻撃の耐性をつけてない人に
対するフールプルーフのために一律全てのコードを遅くする

そもそもその人が設計ミスってるんだろう

**デフォルトの名無しさん** · 2024/03/12(火) 00:15:58.38

SafeSlowHashMapみたいな名前にすれば良いのに

**デフォルトの名無しさん** · 2024/03/12(火) 00:16:19.18

>>264
少なくともこれかな

**デフォルトの名無しさん** · 2024/03/12(火) 00:27:26.16

>>264 >>265
Rustを使ったことすらない人が文句を言ってるのか
RustのHashMapはHasherに対しても多相であり型パラメータでHasherを指定する

**デフォルトの名無しさん** · 2024/03/12(火) 00:32:47.44

>>266
HashMap::new()すらしたことないのかな？

**デフォルトの名無しさん** · 2024/03/12(火) 00:33:47.12

>>266
誰もそんな話してないやろ
これだから複クンは

**デフォルトの名無しさん** · 2024/03/12(火) 00:35:30.45

こいつは結論が先にあってRustのすべてが正しいから後で理屈をつけているだけ
いつもおかしなことを言ってる

**デフォルトの名無しさん** · 2024/03/12(火) 00:36:58.41

ripgrepとかuvとかの既に実用が始まってるRust製アプリでは
デフォルトのハッシュ関数使ってるの？

**デフォルトの名無しさん** · 2024/03/12(火) 01:00:19.76

>>267
やっぱりRustを使ったことないんだな
impl<K, V, S> HashMap<K, V, S>にfn new()は存在しないため
HashMap::<Key, Value, BuildHasherDefault<Hasher>>::default()のように使う

**デフォルトの名無しさん** · 2024/03/12(火) 01:04:13.79

ほらこんな壊れたレスしかできないんだよ
脳が死んでる

**デフォルトの名無しさん** · 2024/03/12(火) 01:05:51.45

常に論点ずらし
何の生産性もない

**デフォルトの名無しさん** · 2024/03/12(火) 01:42:25.91

いつもRustを叩いてRustスレを荒らしてるアンチの言動はいつもワンパターン
今回のHashMapの件で例えると
もしデフォルトのハッシュ関数が安全でなく速いものだと「Rustはデフォルトが安全でない！」と叩く
もしデフォルトのハッシュ関数が安全で遅いものだと「Rustはデフォルトが遅い！」と叩く
どちらになっていても叩くことが目的のキチガイ

**デフォルトの名無しさん** · 2024/03/12(火) 09:25:30.86

「俺が高速なプログラムを作れるのは言語のおかげ」は合ってるが
「俺が低速なプログラムしか作れないのは言語のせい」は間違ってる

**デフォルトの名無しさん** · 2024/03/12(火) 15:42:43.44

『「俺が低速なプログラムしか作れないのは言語のせい」は間違っている』という立場、ユーザーが充分賢いことを仮定しているのでそれならPythonとC++で良い

**デフォルトの名無しさん** · 2024/03/12(火) 16:02:50.20

ほんとどうでもいいな
自転車置き場というより豚小屋の議論

**デフォルトの名無しさん** · 2024/03/12(火) 16:28:46.76

プログラムしかしない人はこういうことしか考えることがないんよ

**デフォルトの名無しさん** · 2024/03/12(火) 17:33:47.15

知識があれば高速化が可能な場合があるのは、言語や項目に関わらず一般的な話。
安全方針のRustとしては、ハッシュ衝突強度を知らなくてもデフォルトで安全がベター。

**デフォルトの名無しさん** · 2024/03/12(火) 18:00:43.49

デフォルトいらんが
ハッシュも自分で選べんガイジがハッシュマップ使うな

**デフォルトの名無しさん** · 2024/03/12(火) 18:49:06.95

>>279
わかってなさそうなので再度書くけど
ハッシュ衝突強度が高いからと言ってハッシュDoS耐性が高いとも限らないしHashMapに適してるとも限らないからね

**デフォルトの名無しさん** · 2024/03/12(火) 18:51:51.27

弱いハッシュでも困るようなプログラム書く人は、自分で判断できるんじゃないの？デフォルトはパフォーマンス優先で良いと思うけどな。

**デフォルトの名無しさん** · 2024/03/12(火) 19:50:55.41

攻撃で困るかどうか攻撃されるまで初心者は判断できないと思う。
そして攻撃されてから対処するのでは遅いかもしれない。
パフォーマンスチューニングは遅いことが問題になってからやるので深刻ではなかろう。

**デフォルトの名無しさん** · 2024/03/12(火) 19:59:05.75

>>283
同意

**デフォルトの名無しさん** · 2024/03/12(火) 20:00:13.63

RustのDefaultHasherは安全かつパフォーマンスのいいSipHashを使っているので普通は気にする必要ない
もちろんPythonやJavaScript(v8)やSwiftなど多くの言語がこのSipHashを使っている
そのうえでRustは必要とするHashMap毎にFxHashなどさらに高速なものを簡単に指定できる

**デフォルトの名無しさん** · 2024/03/12(火) 20:49:08.64

Pythonはハッシュ値計算したらオブジェクトに保存してるでしょ

**デフォルトの名無しさん** · 2024/03/12(火) 20:49:29.65

他の言語たちがRustを参考に同じように後追いしているのね

＞Pythonの文字列やバイト列に対するハッシュアルゴリズムは、HashDoS対策としてPython 3.4から SipHash24が使われていました。
＞その後、ラウンド数を減らしたSipHash13でも十分に安全だとして2015年にRustが、2016年にRubyが、SipHash24からSipHash13への切り替えを行いました。
＞Rust や Ruby からは数年遅れましたが、Pythonもデフォルトの文字列ハッシュアルゴリズムがSipHash13に切り替わりました。

**デフォルトの名無しさん** · 2024/03/12(火) 20:56:37.07

>>286
常にそれをされたら困るが
Rustでもハッシュ値をオブジェクトに持つstring_cacheなどが用途に応じて使われている

**デフォルトの名無しさん** · 2024/03/12(火) 22:08:56.94

>>274
人にキチガイと言う前に自分の脳を使って考えたら？

どちらになっても叩くことはないだろ
他の言語はデフォルトで速いハッシュを使ってるよ

**デフォルトの名無しさん** · 2024/03/12(火) 22:13:42.86

Python　Ruby　スクリプト系言語

**デフォルトの名無しさん** · 2024/03/12(火) 22:30:53.75

他の言語もRustと同じハッシュ関数を用いていることが判明したのにRust叩きを続ける一匹

**デフォルトの名無しさん** · 2024/03/13(水) 01:06:52.67

他の言語の例としてPythonやRubyのような遅いこと前提でとにかく初心者が書いても動けば良いという思想の言語を持ち出してくるのはおかしいでしょう