Rust part23 - 暇つぶし2ch

Rust part23 ..

149:デフォルトの名無しさん
24/02/27 20:23:00.40 20aYglde.net
>>147
サンクス。愛してる

150:デフォルトの名無しさん
24/02/27 21:54:58.65 Tx+RemT0.net
Tのスマートポインタの参照 -> Tの参照
文字の配列の参照 -> 文字のスライス
一連の流れを見るとみんなポインタに熱狂している

151:デフォルトの名無しさん
24/02/27 22:22:03.42 TDjpaGuA.net
>>150
そこはポインタと参照の根本的な違いを理解しできるかどうかかな

「Boxというスマートポインタ」の参照を扱うから意外に感じているのかもしれないが
「Boxというスマートポインタ」はヒープ領域の解放責任つまり所有権を持つ
したがってBox自体を他の関数などへ渡してしまってはmoveしてしまい継続して使えなくなる
だからスマートポインタの参照を渡すことになる
一見するとこれはポインタのポインタで無駄な間接参照に感じるかもしれない
しかし参照＝ポインタではなく参照は抽象的なものなのだ

152:デフォルトの名無しさん
24/02/27 22:43:38.35 NfALWDmT.net
Rust の参照は借用規則に関わることを除けばポインタとそんなに差はないし普通にオブジェクトの一種なんだよな。
C++ の参照はオブジェクトではなく参照の参照もとれないし参照のポインタもないし、
参照のサイズも取得できないというのに比べたら Rust の参照は実体のあるものとして感じられてしまう。

153:デフォルトの名無しさん
24/02/27 22:57:53.18 FQe9Y4YD.net
その橋渡し役がDeref coercion
&Box<T>はそのままだとTのポインタを持つBoxへのポインタとなってしまうが
Box<T>→TのDerefがあるため
&Box<T>→&TとDeref coercionが適用できる
静的にコンパイル時点で行われるため実行時コストはかからない

154:デフォルトの名無しさん
24/02/27 23:09:15.00 xLBlGeUv.net
>>142
この辺り最初理解するまで訳分からんかったな
理解すると大したことはないのだが

155:デフォルトの名無しさん
24/02/27 23:37:04.57 IkmURqSK.net
>>142
>deref coreceは必ず参照から参照へのみ起きる
&**との違いを認識してもらうための例を出したんだけど伝わらなかったみたいだね
それは別にいいんだけど書いてる内容を見る限り
Deref Coercionの動きを単に擬似的に再定義しようとして&**になると言ってるだけじゃなく
実際に&**が適用されると思ってるみたいに感じるね
だとしたらそれは完全な間違い
derefの実装の中で*演算子が使われることはあってもDeref Coercion自体は*演算子とは関係ないんだよ
Boxのderef実装だって*演算子を使わずself.ptr.as_ref()的な実装で実現してもいいわけだし

156:デフォルトの名無しさん
24/02/27 23:45:58.16 Tx+RemT0.net
とにかく、間接参照から直接参照を得る演算の名前はderefでいいんだよね

157:デフォルトの名無しさん
24/02/27 23:58:10.03 cJjIIFX3.net
Derefは*
Deref coercionは&**
前者は明示が必要な点が違い
x: &Box<T> とすると
*x: Box<T>　(by Deref &T→T)
**x: T　(by Deref Box<T>→T)
&**x: &T　(xのDeref coercion結果)
x: &Vec<T> とすると
*x: Vec<T>　(by Deref &T→T)
**x: [T]　(by Deref Vec<T>→[T])
&**x: &[T]　(xのDeref coercion結果)
x: &String とすると
*x: String　(by Deref &T→T)
**x: str　(by Deref String→str)
&**x: &str　(xのDeref coercion結果)

158:デフォルトの名無しさん
24/02/28 00:29:07.11 ZZ90UZAT.net
>>157
とりあえずDerefの定義が

pub trait Deref {
type Target: ?Sized;

// Required method
fn deref(&self) -> &Self::Target;
}
（URLﾘﾝｸ(doc.rust-lang.org)）

でderef()の戻り値には自動的に&がつくから
*x: Box<T>
*x: Vec<T>
*x: String
はDeref traitと関係ないことを抑えておこう
そこに（by Deref…）を書かれると話がおかしくなる

*Tができることの一部をDeref traitではできない
正確な表現かは分からないけどDerefは&の向こう側でしか*を適用できない

159:デフォルトの名無しさん
24/02/28 00:41:03.68 PK7EwTQ6.net
こうだろ

x: &Box<T> とすると
*x: Box<T>　(by Dereference)
**x: T　(by Deref Box<T>→T)
&**x: &T　(xのDeref coercion結果)

x: &Vec<T> とすると
*x: Vec<T>　(by Dereference)
**x: [T]　(by Deref Vec<T>→[T])
&**x: &[T]　(xのDeref coercion結果)

x: &String とすると
*x: String　(by Dereference)
**x: str　(by Deref String→str)
&**x: &str　(xのDeref coercion結果)

160:デフォルトの名無しさん
24/02/28 00:49:10.38 ZZ90UZAT.net
なんかゲシュタルト崩壊してきたんだがｗ

関係ないけど微積のdxとかdyを思い出してしまった

161:デフォルトの名無しさん
24/02/28 01:22:37.90 0HAFGBLs.net
C/C++書いてる者からすると勝手に変換してくれて楽ちんだなあって感じ

162:デフォルトの名無しさん
24/02/28 01:32:01.63 upo0sX/6.net
Deref coercion &**のうち
右側の*は参照に対する参照外しで
左側の*はDerefで定義(実装)されてるものなのね

163:デフォルトの名無しさん
24/02/28 04:46:46.07 EOw65cJZ.net
let s = String::from("xyz");
let x: &str = &s;
let x: &str = &&s;
let x: &str = &&&s;
これ全てコンパイル通ってderef coercionされるから
『by Deref &T→T』も適用されていると思うぞ

164:デフォルトの名無しさん
24/02/28 11:30:56.58 eNJqE6SH.net
>>163
&&T→&Tのことを&T→Tとは書かないわな
前者の用途にDeref for &Tは存在してる

165:デフォルトの名無しさん
24/02/28 17:44:48.30 8gSKFNHr.net
>>156
演算の名前はdereference
derefはDerefトレイトに定義してあるメソッドの名前
 >>157
>Derefは*
違う
Derefはトレイト
*はdereference operator
>Deref coercionは&**
違う
Deref Coercionとはcoercionが行われる場合に「&Tを&<T as Deref>::Target」にcoerceすること
Deref Coercionと*などの演算子は全く別の独立したものとして扱われている
それぞれの処理の一部で必要に応じてDerefに定義されたderefメソッドを活用してるというだけ
片方がもう片方に依存してたりもしない
Deref Coercionの処理の一部として呼び出されるderefメソッドを
演算子で擬似的に再定義しようとすれば&**になるというの話はかろうじて理解できるが
前述のように定義が循環してるだけでなく再定義する価値を見いだせない

166:デフォルトの名無しさん
24/02/28 18:08:21.49 8fminEVJ.net
なるほどね。勉強になるわ。

167:デフォルトの名無しさん
24/02/28 18:17:32.89 8gSKFNHr.net
>>164
&&T→&Tの場合もreference用のビルトインderefが先に動いてDeref for &Tの実装コードは動いてない可能性ない？

168:デフォルトの名無しさん
24/02/28 18:20:50.27 nghz9NTX.net
>>164
Deref coercionの定義を理解しよう
Deref T→Uが実装されている時に
(つまり*TがUとなる時に)
&T→&UのDeref coercionが自動適用される
&String→&str　(by Deref String→str)
&Vec<T>→&[T]　(by Deref Vec<T>→[T])
&Box<T>→&T　(by Deref Box<T>→&T)
&&T→&T　(by Deref &T→T)
これらはすべてDeref coercion

169:デフォルトの名無しさん
24/02/28 18:22:38.09 nghz9NTX.net
>>165
Deref T→Uが実装されている時に
(つまり*TがUとなる時に)
&T→&UのDeref coercionが自動適用される
U＝*T
↓　&Tから出発すると
U＝**(&T)
↓　両辺の参照をとると
&U＝&**(&T)
つまり
Deref coercionとは&**の自動適用のこと

170:デフォルトの名無しさん
24/02/28 18:49:11.26 T3/1RdIi.net
*xが左辺値なら代入、*xが右辺値なら複製とかいう演算に
ビルトインderefみたいな名前をつけるのが間違っている

171:デフォルトの名無しさん
24/02/28 19:13:20.58 fjfA+uEG.net
>>170
mutabilityを除けば左右どちらも同じ型だから形が同じであることは問題ない
左はmutabiltyが必要だからderefではなくderef_mutと区別されていてその点でも問題ない

172:デフォルトの名無しさん
24/02/28 20:06:21.19 ZLPgyFVM.net
判りにくい仕組みだけどこれから開発が進むと
文法変えたりするのかな？

173:デフォルトの名無しさん
24/02/28 20:12:51.73 eWXh2LH7.net
これほど分かりやすくて便利な明確な仕組みはない
他の言語と比較すれば明らか

174:デフォルトの名無しさん
24/02/28 21:00:40.37 ZLPgyFVM.net
これが分かりやすいと思ってる人間には聞いてないよ

175:デフォルトの名無しさん
24/02/28 21:10:22.04 RYfxXFlC.net
他の言語でこれより良いものが存在しないね

RustのDeref
・自動適用されプログラマーの負担を軽減し利便性も良い
・魔法ではなくtrait Derefの実装に基づき動作して分かりやすく自作の型にも適用可能
・コンパイル時に静的に解決され実行時の付加コストゼロで高速動作

176:デフォルトの名無しさん
24/02/28 23:39:05.31 T3/1RdIi.net
>>172
Pythonが分かりやすいのは知ってるけど
RustとPythonは両極端だから文法を微調整してもしょうがない
文法を変える必要があるのは両極端を否定する言語だけだ

177:デフォルトの名無しさん
24/02/28 23:49:09.85 ZZ90UZAT.net
Derefなのに&が消えてない（小並感）
背景を理解しないと引っかかりやすいRustの七不思議候補

178:デフォルトの名無しさん
24/02/29 01:04:43.74 rccXx8PF.net
この仕組みがベストであるという主張は3種類ある
一つは馬鹿な信者が言ってるだけという可能性
一つは本当にこの仕組みがベストである可能性
最後は信者ではないけど素直な馬鹿だからもっと良い仕組みを知らない可能性

このどれであるかは賢い人間がもっと良い仕組みを教えてあげると判別できる
馬鹿な反論が返ってきたら馬鹿な信者
合理的な反論が返ってきたら本当にこの仕組みがベストかもしれない
意見を翻されたら素直な馬鹿

179:デフォルトの名無しさん
24/02/29 01:16:58.91 s7mEAt1S.net
この仕組みがない方が良いということ？
下手で全部書くべきと？

180:デフォルトの名無しさん
24/02/29 01:51:37.80 zTVrVDmh.net
RustのDerefとそのcoercion枠組みの利点
・プログラマーの負担が減る
・コードが見やすくなる
・枠組みはDerefトレイト利用で明白かつ汎用的になっている
・自分で作った型にも実装して作動させることができる
・静的に解決しているためミスしてもコンパイル時にわかる
・実行時に付加的な動作がなく高速に実行される

これらの利点を上回る方法があるならば知りたい
既存の言語でも新規の方法でも

181:デフォルトの名無しさん
24/02/29 03:43:48.10 JSOAwYd/.net
URLﾘﾝｸ(manishearth.github.io)
Boxのまほう

182:デフォルトの名無しさん
24/02/29 10:19:46.23 IetxPnTw.net
>>179
>下手で全部書くべきと？
どこかの方言？

183:デフォルトの名無しさん
24/02/29 12:07:39.99 /e0OxROz.net
>>178
いずれにせよRust信者は自分の信仰を他人に押し付けるために検証可能性を潰すから、科学とはほど遠い姿勢かと。

184:デフォルトの名無しさん
24/02/29 12:33:18.56 sM99e4qp.net
Rustの方式の利点は>>180に挙げられているから
もしRustより良い言語が存在するならば
その方式およびRustの利点を上回る利点を挙げればいいんじゃね？

185:デフォルトの名無しさん
24/02/29 12:41:20.92 JSOAwYd/.net
そんなに比較したいならﾜｯﾁｮｲスレ行けばいいんじゃね？
URLﾘﾝｸ(mevius.2ch.sc)

186:デフォルトの名無しさん
24/02/29 13:11:40.55 WGw1+Mi1.net
検証可能とはコンパイラが無謬であることではない
ここが難しい
コンパイラが未完成の状況でも人間が正解の一部をなぜか知っていること
これが検証可能

187:デフォルトの名無しさん
24/02/29 14:11:14.15 s7mEAt1S.net
>>182
この仕組みがない方が良いということ？

188:デフォルトの名無しさん
24/02/29 14:14:12.31 s7mEAt1S.net
単に理解できないから難癖つけてるだけだよねこの人
自分の主張も一切ないし

189:デフォルトの名無しさん
24/02/29 14:15:14.41 s7mEAt1S.net
誰かの難癖を自分が思い付いたかのように言ってるだけで
何一つまともな批判はない

190:デフォルトの名無しさん
24/02/29 14:15:53.86 s7mEAt1S.net
全く相手にすべき人間ではないと判断する
よって今後無視する

191:デフォルトの名無しさん
24/02/29 14:45:30.61 NVSKcdtL.net
>>184
それは「批判するなら代案出せ」と同じ議論を潰すだけの態度なのでやめよう
技術者なら自分が使っている道具の限界や弱点とは真摯に向き合うべき
その際他の道具との比較も必須ではない

192:デフォルトの名無しさん
24/02/29 14:51:42.06 bXdMb/7T.net
技術的選択は突き詰めれば必ずトレードオフが生じるもの
利点だけを見て欠点に目をつぶったまま良し悪しを論じるのは愚の骨頂

193:デフォルトの名無しさん
24/02/29 14:52:32.46 sM99e4qp.net
Rustの方式の利点は >>180に挙げられているから
もし仮にRustより良い言語が存在するならその言語の方式の利点を挙げればいいんじゃね？

194:デフォルトの名無しさん
24/02/29 15:05:04.64 Sa1lr1bM.net
>>191
>それは「批判するなら代案出せ」と同じ議論を潰すだけの態度なのでやめよう
議論を潰すというよりも批判から逃げたいだけだろう

195:デフォルトの名無しさん
24/02/29 17:17:49.66 WGw1+Mi1.net
物的な代案や物的証拠により人の心を折ることが検証だと思っているんじゃないか

196:デフォルトの名無しさん
24/02/29 17:44:22.90 JSOAwYd/.net
や、そもそも「人の心」の認識が無いのだろう

197:デフォルトの名無しさん
24/02/29 18:01:07.55 OWFCi11w.net
わざわざRustスレにまでやって来てRust叩きやってる人だから心の病気なのかもな

198:デフォルトの名無しさん
24/02/29 18:25:15.72 uwbVoB9N.net
>>167
>&&T→&Tの場合
これ調べてみたんだけどビルトインderefが優先的に動いて
Deref for &Tの実装は使われてなかった

199:デフォルトの名無しさん
24/02/29 18:37:38.45 OsB1rmqt.net
ビルトインは*を明示指定しないといけなくない？
coercionは何も指定しなくてもDeref実装があれば自動的に多段に適用してくれるけど

200:デフォルトの名無しさん
24/02/29 20:49:33.50 NE3ms/ho.net
impl Deref for &T
はtrait境界を満たすためだけに定義されてるんだろうな
標準だとDeref境界はPinくらいしか使ってないけど

201:デフォルトの名無しさん
24/02/29 23:55:24.58 uwbVoB9N.net
>>199
*演算子のときもDeref CoercionのときもビルトインderefがDeref::derefよりも優先して使われるよ

202:デフォルトの名無しさん
24/03/01 08:46:23.47 SBTwWOM0.net
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();

203:デフォルトの名無しさん
24/03/01 09:18:59.78 LWQ/+31h.net
uv、めちゃ速いな
今までの処理時間はなんだったのか
これはRustの印象を良くするツールになるわ

204:デフォルトの名無しさん
24/03/01 10:14:36.96 gvn/awFT.net
uvというとCで書かれた非同期マルチプラットフォームライブラリ(Rustにはmioがある！)が有名だが
そのuvはRust製のPythonパッケージマネージャーなのか

205:デフォルトの名無しさん
24/03/01 11:06:37.60 C9bgbnyF.net
速さの定義はわかりやすさの定義よりもわかりやすい

206:デフォルトの名無しさん
24/03/01 16:15:12.75 lzR4RBgp.net
JavaScriptでも遅いBabelを速いSWC(Rust製)に換えると爆速

207:デフォルトの名無しさん
24/03/01 19:02:46.24 I+/u+ffT.net
Pythonの管理ツールまたなんか出たの！？という気分

208:デフォルトの名無しさん
24/03/02 00:14:54.94 F+x2UUkM.net
uvはPython版のcargoを目指しているらしい

209:デフォルトの名無しさん
24/03/02 16:13:07.16 bMlzFBHT.net
nvidiaのど汚なさを理解してなさげで不安しかないわ

210:デフォルトの名無しさん
24/03/05 04:09:58.03 n3bQlkHC.net
RustでDB使う時の定番ライブラリって何ですか？

211:デフォルトの名無しさん
24/03/05 04:14:48.62 nMHII26b.net
ORMが好きならdiesel
ORMが嫌いならsqlx

212:デフォルトの名無しさん
24/03/05 06:15:07.43 Uplx2IYd.net
>>211
それRDBじゃん

213:デフォルトの名無しさん
24/03/05 11:41:51.93 6drsihdZ.net
RDBじゃないDBの定番とか聞かんだろJK

214:デフォルトの名無しさん
24/03/05 12:54:04.64 iKkb/Eo4.net
RDBMSが定番だからね。

215:デフォルトの名無しさん
24/03/05 23:56:12.66 blmx074I.net
最近RDB以外のDBの存在を知った人にありがちな反応だよな

216:デフォルトの名無しさん
24/03/07 15:14:21.16 /no0RfP4.net
Rustで一通り文法や機能紹介した入門書の次に読むような定石本ってどのようなのがありますか？C++でいうEffective C++みたいな

217:デフォルトの名無しさん
24/03/07 15:28:53.82 5c4tHUTp.net
しゃぶれよ

218:デフォルトの名無しさん
24/03/07 17:13:51.21 NLgNYFMG.net
>>216
Rust for Rustaceans

219:デフォルトの名無しさん
24/03/10 13:14:05.30 XsimGsv7.net
Rustはデフォルトのhashが遅いという罠

220:デフォルトの名無しさん
24/03/10 20:35:08.28 8NU5B5F+.net
>>219
Rustはデフォルトのハッシュ関数が最強最善の暗号学的ハッシュ関数であるSipHashを採用しているため衝突にも強くハッシュDOS攻撃に対しても安全
もし強い衝突耐性を必要としない用途ならばFxHasherなどの速さ重視のハッシュへと簡単に置き換えられる
type Hasher = std::hash::BuildHasherDefault<FxHasher>;
let mut map = HashMap::<Foo, Hasher>::default();

221:デフォルトの名無しさん
24/03/10 20:38:28.49 8NU5B5F+.net
こうね
HashMap::<Key, Value, Hasher>

222:デフォルトの名無しさん
24/03/10 21:21:36.22 yMMzzxd+.net
解決案としてはそうなのだが、デフォルト挙動が罠すぎる
デフォルトいらなかったのでは

223:デフォルトの名無しさん
24/03/10 21:26:04.39 hwVh1yHa.net
Rustは利用者はアホだと思ってる
だから徹底的に厳しくしてくる

224:デフォルトの名無しさん
24/03/10 21:33:53.98 hwVh1yHa.net
雨が降ってなくても傘を持つように言って来て外出すらさせてくれない

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

226:デフォルトの名無しさん
24/03/11 00:47:18.65 2r+51Qz1.net
Rustはimpl std::hash::Hasherで必要なら自由に独自のハッシュ計算器をすぐ作れるし
逆にそれと独立にimpl std::hash::Hashで自分の各型に対してハッシュ計算法を指示できるし
この2種類のトレイトを標準で用意してくれているRustは非常に好環境

227:デフォルトの名無しさん
24/03/11 00:59:26.53 lga6QF6v.net
「最悪の場合でもほどほど」なやつをデフォルトにするのは妥当だと俺も思う。
状況に合わせて選択できたり自分で作れたりする人はそうするんだから、
デフォルトではそうでない人を想定するだろ。

228:デフォルトの名無しさん
24/03/11 02:43:53.87 aDyedTxf.net
いやそもそもデフォルトいらんくね？
なんでデフォルト欲しいんだ？

229:デフォルトの名無しさん
24/03/11 11:06:00.19 WfvY/WS3.net
掃除機はAI搭載して吸ってはいけないものを吸ったら止まってくれよ

230:デフォルトの名無しさん
24/03/11 11:06:34.84 WfvY/WS3.net
誤爆した！

231:デフォルトの名無しさん
24/03/11 14:30:36.32 emAmKvKR.net
デフォルトを用意するかしないかは言語思想によるから正解不正解では語れないよな
rustの場合は何事も「安全」に基づいて設計されてると認識してる

232:デフォルトの名無しさん
24/03/11 15:25:18.07 WOvDUzj/.net
適切なハッシュ関数を選択するのってそんな簡単なことじゃないからな
ハッシュ関数の特性だけじゃなくhashbrownの特性も知らないといけないしその両方を組み合わせた際のハッシュDoS耐性の程度も評価できないといけない
HashMapのように基本的なデータ構造を使うのにどんな場合でもいちいちユーザーがその選択しなきゃいけないようだと辛すぎるわな

233:デフォルトの名無しさん
24/03/11 19:01:47.22 srElBTmD.net
HashMapで使われるHashに重いものを使う必要がある局面は限られてる
でも他人のライブラリの外から必要な時にハッシュアルゴリズムを変えることなんかできないので悩ましい人もいるだろう

234:デフォルトの名無しさん
24/03/11 20:05:38.98 3y0FGSJo.net
僕が美少女とセックスするためのプログラムはRustで作れますか

235:デフォルトの名無しさん
24/03/11 21:13:52.07 2r+51Qz1.net
>>233
ライブラリを作成する時にその用途に応じた適切なハッシュを用いればよい
用途により異なるならば安全側に倒すか指定する方法を提供すればよい

236:デフォルトの名無しさん
24/03/11 21:28:56.93 vmVry2mm.net
とりあえずデフォルトを使って、必要になったら差し替えればいいんじゃないの？
Rustだとなんか問題あるんだっけ？

237:デフォルトの名無しさん
24/03/11 21:31:16.84 aDyedTxf.net
>>236
ライブラリのハッシュを差し替えられない
デフォルトハッシュを使うような人間がどんどん参戦してきてcratesの名前空間を埋め尽くしていく

238:デフォルトの名無しさん
24/03/11 21:41:07.80 6xtSsnXH.net
ハッシュ衝突強度安全性が必要かどうかの判断ができない者がRustデフォルトの安全なものを用いることになるのは正しい
そこまで必要としない用途であると判断できた者だけがFxHashなどを用いればいい
RustコンパイラもFxHashを用いている
URLﾘﾝｸ(github.com)

239:デフォルトの名無しさん
24/03/11 21:44:11.78 uBu+z/S9.net
安全で高速を名乗ってるくせにライブラリがおっせえ言語だなあ
これ治すにはいちいち依存ライブラリ全てをcloneしてきてチマチマ変更していかないといけないってマジかよ

240:デフォルトの名無しさん
24/03/11 22:02:54.43 2hCRIQro.net
言語とは関係ない
外部からのデータを扱うなど攻撃耐性など必要となる部分には攻撃耐性のあるハッシュが必須
そうでない部分には攻撃耐性は必要ない
各プログラムの中にこれら両者はは共存しうる
この使い分けができているかどうかは各言語の問題ではない

241:デフォルトの名無しさん
24/03/11 22:17:15.26 1Ss4PFRT.net
ライブラリやその管理が言語と関係がないとする主張は可能だが、その主張をするとcargoやcratesの存在が言語と関係ないことになり、Rustの良さを支えている理由の大きな割合を失うことになる
やはりエコシステムやそこにある資産も含めての言語の評価だろう
それにユーザーの問題を言語が引き取らないのであればコードを書く人が充分賢いことを仮定することになり、C++で良いということになる

242:デフォルトの名無しさん
24/03/11 22:22:30.50 2hCRIQro.net
>>241
C++だけでなくスクリプト言語であろうがすべて同じ
攻撃耐性が必要となるところで強度の高いものが使われてなければ欠陥プログラム

243:デフォルトの名無しさん
24/03/11 22:24:26.89 1Ss4PFRT.net
>>242
だからデフォルトなんかいらないんだよ
ハッシュごとき使うのにデフォルトがないと使えないような人間がcratesの名前空間を埋めていくのはヤバいよ

244:デフォルトの名無しさん
24/03/11 22:32:51.13 Zfy+Gd54.net
>>243
ほとんどの言語の連想配列(hashmap)のハッシュ関数はデフォルトがありますよ
指定しないと使えない言語がもしあるとしてもレアじゃないですか？

245:デフォルトの名無しさん
24/03/11 22:38:01.21 1Ss4PFRT.net
>>244
それはJavaScriptやPythonのような馬鹿がライブラリを書いて馬鹿が馬鹿の再生産をすることを推奨している言語の話でしょう？
もしくは仕様だけ緩く決めて実装には何の責任も取らない言語か

246:デフォルトの名無しさん
24/03/11 22:39:37.27 1Ss4PFRT.net
スクリプト言語だと速度は求められないという了解があるし

247:デフォルトの名無しさん
24/03/11 22:53:49.00 lga6QF6v.net
Rust や C++ の思想でいう速さはゼロコスト抽象のことだよ。
抽象化にはコストはない (または十分に小さい) が実行すれば実行内容に相応の実行コストが生じるのは当たり前のことだし、実行内容を最小限にすることを目指したって単に不便になるだけだ。

248:デフォルトの名無しさん
24/03/11 23:24:30.57 pnxYU4a7.net
あらゆる言語のあらゆるプログラムについて以下が成り立つ
【必須】信頼できない外部入力データに対しては攻撃に強いハッシュ関数を用いなければならない
【自由】そうでないデータに対してはどのハッシュ関数を用いてもよい
この状況で安全な言語はデフォルトとして攻撃に強いハッシュ関数が適切
そして後者と判断できるプログラマーのためにハッシュ関数を指定できる仕様が適切
Rustはこの適切な仕様となっている

249:デフォルトの名無しさん
24/03/11 23:26:28.61 srElBTmD.net
雨の降らない日に傘をさしてるのがRust

250:デフォルトの名無しさん
24/03/11 23:31:49.34 srElBTmD.net
外に出るときはヘルメットを被って110をすでに入力したスマホを持ちながらおむつをしてコンドームつけてるのがRust

251:デフォルトの名無しさん
24/03/11 23:39:22.87 H3LWtGm6.net
雨が降る日のためにいつでも傘をさしてるだけだろ…

252:デフォルトの名無しさん
24/03/11 23:47:29.47 1gRl0SR3.net
デフォルトとFxHasherで比較してみたけどHashMapへのinsertのみで実行時間1.7倍
現実のプログラムだとそれ以外の部分が大量にあるためそれ次第で誤差だね
これはデフォルトが安全側に倒す形を取っていて正解と思う

253:デフォルトの名無しさん
24/03/11 23:47:55.83 eCeLdHKW.net
>>248
>【自由】そうでないデータに対してはどのハッシュ関数を用いてもよい
いやーそれはどうだろう？
ハッシュDoS耐性は不要でも例えばFxHashを使うべきじゃないユースケースも普通にあるよね？
stdに1つしかHasherが用意されておらずサードパーティ頼みな現状は言語的には結構不親切

254:デフォルトの名無しさん
24/03/11 23:55:39.88 srElBTmD.net
hash自体は基本的にアホでも作れる
それが適切なのかどうかは不明

255:デフォルトの名無しさん
24/03/11 23:59:34.73 o1bdd8gz.net
Rustはデフォルトハッシュ関数が用意されていておかしいと言うけど
すべての言語で用意されてるでしょ？
Rustは様々なハッシュ関数が標準ライブラリにないと言うけど
それが普通でしょ？
さらにRustの標準ライブラリはなるべく小さくする方針ね

256:デフォルトの名無しさん
24/03/12 00:02:16.02 YqCvYydB.net
>>255
ここまで読んでそういう解釈になってるなら理解する力が足りてない
重いハッシュ関数がデフォルトになってるのがどうなのかと言う話

257:デフォルトの名無しさん
24/03/12 00:06:26.32 hhdv8qp2.net
普通に考えて攻撃に強いハッシュ関数がデフォルトとなってるのがベストだよね
攻撃の可能性のない部分のみを後でチューンアップつまり弱いハッシュ関数で置き換えるだけだから
これより良い策があるの？

258:デフォルトの名無しさん
24/03/12 00:07:45.67 YqCvYydB.net
攻撃の可能性のある部分をチューンナップ

259:デフォルトの名無しさん
24/03/12 00:10:05.78 hhdv8qp2.net
>>258
バカなの？
それだとチューンアップする前が攻撃耐性ないじゃん

260:デフォルトの名無しさん
24/03/12 00:10:10.84 YqCvYydB.net
江戸時代士農工商の身分制度があって
雨の日だけ農民も下駄を履いてよかった

261:デフォルトの名無しさん
24/03/12 00:11:17.84 YqCvYydB.net
>>259
攻撃されないのに攻撃態勢をつける馬鹿

262:デフォルトの名無しさん
24/03/12 00:13:45.61 c71xUORt.net
みんなの言語思想発表会をするのはいいけどRustをそれに巻き込むなよ

263:デフォルトの名無しさん
24/03/12 00:15:25.47 YqCvYydB.net
IDコロコロ全肯定君
攻撃されるかもしれないのに攻撃の耐性をつけてない人に
対するフールプルーフのために一律全てのコードを遅くする
そもそもその人が設計ミスってるんだろう

264:デフォルトの名無しさん
24/03/12 00:15:58.38 ltF5NefG.net
SafeSlowHashMapみたいな名前にすれば良いのに

265:デフォルトの名無しさん
24/03/12 00:16:19.18 YqCvYydB.net
>>264
少なくともこれかな

266:デフォルトの名無しさん
24/03/12 00:27:26.16 hEPMmb8p.net
>>264 >>265
Rustを使ったことすらない人が文句を言ってるのか
RustのHashMapはHasherに対しても多相であり型パラメータでHasherを指定する

267:デフォルトの名無しさん
24/03/12 00:32:47.44 YqCvYydB.net
>>266
HashMap::new()すらしたことないのかな？

268:デフォルトの名無しさん
24/03/12 00:33:47.12 P8rBcnCc.net
>>266
誰もそんな話してないやろ
これだから複クンは

269:デフォルトの名無しさん
24/03/12 00:35:30.45 YqCvYydB.net
こいつは結論が先にあってRustのすべてが正しいから後で理屈をつけているだけ
いつもおかしなことを言ってる

270:デフォルトの名無しさん
24/03/12 00:36:58.41 4FnCuSr/.net
ripgrepとかuvとかの既に実用が始まってるRust製アプリでは
デフォルトのハッシュ関数使ってるの？

271:デフォルトの名無しさん
24/03/12 01:00:19.76 hEPMmb8p.net
>>267
やっぱりRustを使ったことないんだな
impl<K, V, S> HashMap<K, V, S>にfn new()は存在しないため
HashMap::<Key, Value, BuildHasherDefault<Hasher>>::default()のように使う

272:デフォルトの名無しさん
24/03/12 01:04:13.79 YqCvYydB.net
ほらこんな壊れたレスしかできないんだよ
脳が死んでる

273:デフォルトの名無しさん
24/03/12 01:05:51.45 YqCvYydB.net
常に論点ずらし
何の生産性もない

274:デフォルトの名無しさん
24/03/12 01:42:25.91 O5aTP+Ks.net
いつもRustを叩いてRustスレを荒らしてるアンチの言動はいつもワンパターン
今回のHashMapの件で例えると
もしデフォルトのハッシュ関数が安全でなく速いものだと「Rustはデフォルトが安全でない！」と叩く
もしデフォルトのハッシュ関数が安全で遅いものだと「Rustはデフォルトが遅い！」と叩く
どちらになっていても叩くことが目的のキチガイ

275:デフォルトの名無しさん
24/03/12 09:25:30.86 2ftxmqwc.net
「俺が高速なプログラムを作れるのは言語のおかげ」は合ってるが
「俺が低速なプログラムしか作れないのは言語のせい」は間違ってる

276:デフォルトの名無しさん
24/03/12 15:42:43.44 qP6Ph9LT.net
『「俺が低速なプログラムしか作れないのは言語のせい」は間違っている』という立場、ユーザーが充分賢いことを仮定しているのでそれならPythonとC++で良い

277:デフォルトの名無しさん
24/03/12 16:02:50.20 O51IPiXd.net
ほんとどうでもいいな
自転車置き場というより豚小屋の議論

278:デフォルトの名無しさん
24/03/12 16:28:46.76 6k71yQCv.net
プログラムしかしない人はこういうことしか考えることがないんよ

279:デフォルトの名無しさん
24/03/12 17:33:47.15 +dm3OZRm.net
知識があれば高速化が可能な場合があるのは、言語や項目に関わらず一般的な話。
安全方針のRustとしては、ハッシュ衝突強度を知らなくてもデフォルトで安全がベター。

280:デフォルトの名無しさん
24/03/12 18:00:43.49 ZUpYWJV7.net
デフォルトいらんが
ハッシュも自分で選べんガイジがハッシュマップ使うな

281:デフォルトの名無しさん
24/03/12 18:49:06.95 hIsWcrJS.net
>>279
わかってなさそうなので再度書くけど
ハッシュ衝突強度が高いからと言ってハッシュDoS耐性が高いとも限らないしHashMapに適してるとも限らないからね

282:デフォルトの名無しさん
24/03/12 18:51:51.27 wv71s4mp.net
弱いハッシュでも困るようなプログラム書く人は、自分で判断できるんじゃないの？デフォルトはパフォーマンス優先で良いと思うけどな。

283:デフォルトの名無しさん
24/03/12 19:50:55.41 WtXn1sYk.net
攻撃で困るかどうか攻撃されるまで初心者は判断できないと思う。
そして攻撃されてから対処するのでは遅いかもしれない。
パフォーマンスチューニングは遅いことが問題になってからやるので深刻ではなかろう。

284:デフォルトの名無しさん
24/03/12 19:59:05.75 1eKk9IjK.net
>>283
同意

285:デフォルトの名無しさん
24/03/12 20:00:13.63 uVbV4a/I.net
RustのDefaultHasherは安全かつパフォーマンスのいいSipHashを使っているので普通は気にする必要ない
もちろんPythonやJavaScript(v8)やSwiftなど多くの言語がこのSipHashを使っている
そのうえでRustは必要とするHashMap毎にFxHashなどさらに高速なものを簡単に指定できる

286:デフォルトの名無しさん
24/03/12 20:49:08.64 NxLZ8TT6.net
Pythonはハッシュ値計算したらオブジェクトに保存してるでしょ

287:デフォルトの名無しさん
24/03/12 20:49:29.65 +yrdVDIt.net
他の言語たちがRustを参考に同じように後追いしているのね

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

288:デフォルトの名無しさん
24/03/12 20:56:37.07 Bo/PtDeL.net
>>286
常にそれをされたら困るが
Rustでもハッシュ値をオブジェクトに持つstring_cacheなどが用途に応じて使われている

289:デフォルトの名無しさん
24/03/12 22:08:56.94 qGjx1B49.net
>>274
人にキチガイと言う前に自分の脳を使って考えたら？
どちらになっても叩くことはないだろ
他の言語はデフォルトで速いハッシュを使ってるよ

290:デフォルトの名無しさん
24/03/12 22:13:42.86 qGjx1B49.net
Python　Ruby　スクリプト系言語

291:デフォルトの名無しさん
24/03/12 22:30:53.75 QLhbtBPI.net
他の言語もRustと同じハッシュ関数を用いていることが判明したのにRust叩きを続ける一匹

292:デフォルトの名無しさん
24/03/13 01:06:52.67 l12NsVZP.net
他の言語の例としてPythonやRubyのような遅いこと前提でとにかく初心者が書いても動けば良いという思想の言語を持ち出してくるのはおかしいでしょう

293:デフォルトの名無しさん
24/03/13 01:36:16.81 yq4Sx3eg.net
Swiftも同じSipHash13だよ

294:デフォルトの名無しさん
24/03/13 06:48:44.81 vtWyM3VT.net
>>292
じゃあRustの思想は？

295:デフォルトの名無しさん
24/03/13 07:26:54.50 W15vpPlq.net
>>283
判断できない人まで言語側で救う必要性が分からない。
それなら、unsafeもカジュアルに使えないように仕掛けを用意した方が良いんじゃないかと。

296:デフォルトの名無しさん
24/03/13 08:05:27.17 7ftIQ2tM.net
必要なことしかやりませんって言語は他にあるからそちら使えばいいのでは？

297:デフォルトの名無しさん
24/03/13 11:53:59.71 k71lJTPU.net
安全と速度は両立するかそれともトレードオフか
トレードしかしない人にとって、コストは支払うと決めたら絶対にキャンセルできない印象があるよね
有償かと思ったけどよく考えたらやっぱゼロコストだったという現象は許せない

298:デフォルトの名無しさん
24/03/13 13:08:21.45 zcdQDtji.net
Rustなんかに手を出すのはC++まともに書けない馬鹿なんだから、「充分賢ければ速く書ける」は実質「速く書けない」なんだよな
賢いならRustなんかやらない

299:デフォルトの名無しさん
24/03/13 13:52:10.04 k71lJTPU.net
自由があればデフォルト設定を強制されないのは自明な事実
ただし、賢い人間が自由を所有しているのか、道具自体が自由度を持っているのか
そもそも「所有している」というのはただの感想なのか客観的事実なのか

300:デフォルトの名無しさん
24/03/13 15:08:41.44 EtYMYlMl.net
アホ vs バカの不毛な争いが続くのは隔離スレにﾜｯﾁｮｲつけたやつの責任だからな

301:デフォルトの名無しさん
24/03/13 17:12:52.60 2jYqKDsd.net
本スレにワッチョイつけず隔離スレと称して余計なスレ立ててそっちにワッチョイつけるバカども。
5chでRust使ってるって言ってるやつらはそんなもの

302:デフォルトの名無しさん
24/03/13 17:32:48.34 k71lJTPU.net
不毛の判断が早いなあ
後世の歴史家が判断するという定型文に縛られないから早いんだな

303:デフォルトの名無しさん
24/03/13 17:40:34.76 EfEhvhMh.net
安全と速度を両立させたのが
RustやPythonなどが採用しているSipHash13

304:デフォルトの名無しさん
24/03/13 18:38:09.42 9N462qty.net
>>295
いや、unsafeは判断できる人が使うものだろ。

305:デフォルトの名無しさん
24/03/13 21:22:31.53 cNV/vVTe.net
>>300
分かってるんならﾜｯﾁｮｲ付きRustスレの盛り上げに協力してくれんかえ

306:デフォルトの名無しさん
24/03/13 21:54:19.69 Ay/UTMuM.net
ワッチョイなんか盛り上がる訳ねえ
そんな話題あったらこのスレに投下してつまらない議論を流した方が余程生産的

307:デフォルトの名無しさん
24/03/13 22:31:42.96 /twoPXVD.net
高齢化でコーディングできなくなったおじいさんを叩くのは良くないと言う話

308:デフォルトの名無しさん
24/03/13 22:39:35.15 vtWyM3VT.net
30後半でコーディングしてるやつなんて9割コミュ障で出世できなかったやつだろ

309:デフォルトの名無しさん
24/03/13 22:42:16.17 6IE1D2aF.net
出世出来ましたか？

310:デフォルトの名無しさん
24/03/13 22:52:25.45 /twoPXVD.net
能力が低下してコーディングできないのとしないのでは大違い

311:デフォルトの名無しさん
24/03/14 00:41:25.89 2hurvpo9.net
結局スクリプト言語で書かれた原作が必要か
他のジャンルでも原作なしのオリジナルは難しそうだろう

312:デフォルトの名無しさん
24/03/14 12:30:54.13 HuCxvvOv.net
Rustで書き直してパフォーマンスが上がったので注目浴びる！みたいなプロダクトはなんか白けるよな。
JSとかPythonの基盤ツールをRustで書き換えて激速！みたいなのはもう汎用言語としてのアイデンティティ捨てられててオワットル。

313:デフォルトの名無しさん
24/03/14 12:34:38.63 GaNa4vYx.net
日本みたいに、何とかするには人投入しよう！スキルどうでもいいからとにかく人集めて！なところじゃね～。

314:デフォルトの名無しさん
24/03/14 13:45:31.80 zTrHTca+.net
おそらく植山類が新しいリンカを作ったあたりが開発ツール高速化の機運の始まりだと思う。
歴史的事情でごちゃごちゃしてて遅いのが仕方がないと思われていたものについて
速度を意識して書いてみたら数百倍単位で速くなってわひゃーーというのが強烈なインパクトだった。
(それは C++ で書かれてるんだけどね。)
商売で開発ツールを提供している会社にとっては少なくともそれと同程度のものを出さないと面子が立たない。
リンカを作ってるところはこぞって高速化に努めた。
リンカ以外にもその機運が波及しているのが今。
で、高速化のキモはデータ構造であるというのが明瞭になったんだけど
メモリ管理の部分を処理系 (ランタイムサポート) の側でやるようなものだとそこんところのチューニングが出来ない。
Rust である必然性が強いわけではないけど C++ とかよりは今なら Rust のほうがいいかなってのはまあ自然な判断ではある。

315:デフォルトの名無しさん
24/03/15 00:47:31.57 eu7fnAy5.net
コードを書けない
プログラムできなくなるとこういうことしか書けなくなると言う見本

316:デフォルトの名無しさん
24/03/15 10:43:30.71 5CgUbd5q.net
だが読むより書くほうが優れているという前提から
原作を正しく読解するよりも正しくない二次創作のほうが優れているという結論が出てくる

317:デフォルトの名無しさん
24/03/15 11:53:24.75 94MXVgRN.net
春だなぁw

318:デフォルトの名無しさん
24/03/15 18:26:51.96 5N0PtL1J.net
ai bot

319:デフォルトの名無しさん
24/03/15 20:40:42.93 W8LQpOAr.net
>>315
辛辣で草
そういう似非技術者系おじいちゃんおちょくると
怒って自分が唯一知ってる知識振り回してくるから面白いぞ

320:デフォルトの名無しさん
24/03/15 21:07:06.30 8+Y0uCh5.net
Rustコードを書けない似非技術者系おじいちゃんたちは他のスレでやりとりしなさい
ここはRust専用スレ

321:デフォルトの名無しさん
24/03/15 21:26:31.60 PnOJWcC7.net
コーディングが出来なくなると人生はつらいと思うけどな…

322:デフォルトの名無しさん
24/03/15 21:36:49.30 3GkeGGWK.net
できなくなるんじゃなくて
元々できてないんよね>>314みたいな人は
というより単に職業マじゃないのかもな
趣味でプログラム触ったことあるパソコン少年的な

323:デフォルトの名無しさん
24/03/16 00:23:32.44 /iia2JvS.net
人はいつか何もできなくなって死んでいくんだよな
つまらないね

324:デフォルトの名無しさん
24/03/16 08:54:22.01 aeWu0EgX.net
肉屋がレッドオーシャンになれば豚はブルーだからこれでいい

325:デフォルトの名無しさん
24/03/17 19:33:58.02 1VtyMVPz.net
Rust書けるやつ集めるの大変すぎ

326:デフォルトの名無しさん
24/03/17 22:06:35.75 BMZldfUE.net
Rustで書けば速くてリソースコスト下げられるうえに保守性も良くていいことずくめだからだな
ただしまともなプログラマーしか使い　　こなせない

327:デフォルトの名無しさん
24/03/18 09:59:50.17 ySp1yGcK.net
むしろ変なやつしか使ってない感じだけど…

328:デフォルトの名無しさん
24/03/18 10:20:48.83 JObkxwF0.net
しょーもないこだわり持ってるやつしか使ってない

329:デフォルトの名無しさん
24/03/18 13:49:12.09 lCCxn1Q7.net
今後の仕事考えたらRustだね

330:デフォルトの名無しさん
24/03/18 14:26:36.03 1+ObkRXf.net
メモリ安全性ってなんなの？

331:デフォルトの名無しさん
24/03/18 14:49:59.91 RRSB5dTk.net
無効なアドレスを参照しない
運が良ければSegmentation Fault、運が悪ければ変な値が使われて何か起こる
無効なアドレスを更新しない
運が良ければSegmentation Fault、運が悪ければそこの値が壊れて何か起こる
メモリリークは割とどうでもいい

332:デフォルトの名無しさん
24/03/18 15:00:45.39 ZJ4hMg34.net
>>330
メモリ安全性のうち特に重要な一つがメモリ競合の安全性
まだ使っている値を意図せずに書き換えてしまい矛盾してしまう
プログラミングで起こるバグの代表的な一つ
Rustではこれを防ぐことができる

333:デフォルトの名無しさん
24/03/18 15:02:35.53 1+ObkRXf.net
>>331
ありがとう
「運が悪ければ変な値が使われて何か起こる」
そういえばメモリの概念理解せずにC言語使って、動かすたびに結果がかわるバグプログラム生み出してビビリ倒したことを思い出しました……

334:デフォルトの名無しさん
24/03/18 15:07:28.37 1+ObkRXf.net
>>332
ありがとう
「運が悪ければ変な値が使われて何か起こる」
そういえばC言語の現在時刻取得関数がポインタ返し&参照先書き換えるタイプの関数だったので大ハマリしたことありますね…

335:デフォルトの名無しさん
24/03/18 18:35:36.34 utey1W8X.net
セルフコントならもう少し面白いやつを頼む

336:デフォルトの名無しさん
24/03/20 01:19:02.24 6E76csi8.net
WebAssemblyバイナリの実行環境を提供する「Rust」で作成されたランタイム「Wasmi」に脆弱性が明らかになった。
URLﾘﾝｸ(www.security-next.com)

337:デフォルトの名無しさん
24/03/20 05:37:59.51 wTR4SIFK.net
デフォルトで制限よりも多くのパラメーターを指定すると域外に書き込みを行うおそれがある「CVE-2024-28123」が明らかとなった。

2023年12月にリリースされた「同0.31.1」にて脆弱性は修正された。
パラメーターが128個以下であることを確認する回避策についてもアナウンスしている。

338:デフォルトの名無しさん
24/03/20 12:50:32.15 /slJg93x.net
>>336
そういうのRust関係ないからわざわざここに書かなくてもいいよ

339:デフォルトの名無しさん
24/03/20 13:00:27.22 3fTCja3E.net
関係無いわけないでしょｗ
rustで書かれてたら安全なんじゃなかったん？ｗ

340:デフォルトの名無しさん
24/03/20 13:48:07.28 i9d3tzeg.net
ガベージコレクションのあるスクリプト言語であるPythonですら脆弱性でCVE出まくってるよ

341:デフォルトの名無しさん
24/03/20 14:22:40.25 HLjoI2yW.net
これは「メモリ安全」の外の話？中の話？

342:デフォルトの名無しさん
24/03/20 16:11:18.74 sC/F3tDJ.net
unsafe使用箇所だからメモリ安全の外だろうな
インタプリタのスタックフレーム参照で毎回境界チェックする実装も微妙だししゃーない

次ページ