24/02/23 18:14:46.11 7HXLfctb.net
Rust The Book (日本語版)
URLﾘﾝｸ(doc.rust-jp.rs)
Rust edition guide (日本語版)
URLﾘﾝｸ(doc.rust-jp.rs)
Rust by example (日本語版)
URLﾘﾝｸ(doc.rust-jp.rs)
Rust cookbook (日本語版)
URLﾘﾝｸ(uma0317.github.io)
Rust API guideline (日本語版)
URLﾘﾝｸ(sinkuu.github.io)
Rust nomicon book (日本語版)
URLﾘﾝｸ(doc.rust-jp.rs)
Rust async book (日本語版)
URLﾘﾝｸ(async-book-ja.netlify.app)
Rust WASM book (日本語版)
URLﾘﾝｸ(moshg.github.io)
Rust embeded book (日本語版)
URLﾘﾝｸ(tomoyuki-nakabayashi.github.io)
Rust enbeded discovery (日本語版)
URLﾘﾝｸ(tomoyuki-nakabayashi.github.io)
Rust Design Patterns (日本語版)
URLﾘﾝｸ(qiita.com)
URLﾘﾝｸ(qiita.com)
Rust API guideline (日本語版)
URLﾘﾝｸ(sinkuu.github.io)
3:デフォルトの名無しさん
24/02/23 18:15:20.65
4: ID:7HXLfctb.net
5:デフォルトの名無しさん
24/02/24 14:37:44.58 TvelBLvi.net
前スレ終盤がRust特有の型🔵ナニー症候群の典型(この用語は出典参照)
ｽﾚﾘﾝｸ(tech板:977番)-
Netflixは2年かけて気が付いたけど凡人程のめり込む沼
出典
URLﾘﾝｸ(www.youtube.com)
Haskellの時と同様、概念だけ触れたら他の言語に活かすのが良い
長居していると症候群認定される危険性があるから
6:デフォルトの名無しさん
24/02/24 14:48:37.96 cR8FpHrN.net
>>4
それ何の情報もなく見ても無駄
具体的な説得力ある話がない
TypeScriptが嫌いでGoが好きらしい
7:デフォルトの名無しさん
24/02/24 16:14:50.39 yK1YDROT.net
Rustから前スレ終盤の型オナニーをなくしたような言語があれば使いたいけど、ないから仕方なくRustを使っている
8:デフォルトの名無しさん
24/02/24 16:23:38.76 GLkrdyDg.net
静的型チェックレベルを高めつつジェネリクス等による汎化を活用しようとすれば大なり小なり型オナニーは避けられない
RustやTypeScriptだけでなくC++のtemplateやPythonの型ヒントでも同じこと
単独のTraitだけの話で型オナニーとか言ってるやつはオナニーレベルが低過ぎ
静的型チェックへの適性がないのでRustも辞めた方がいい
9:デフォルトの名無しさん
24/02/24 16:34:30.38 vVxC7GCC.net
型オナニーより所有権やライフタイム管理の方が面倒だけどな
それが型と絡むからさらにややこしくなる
10:デフォルトの名無しさん
24/02/24 17:03:48.32 4NvD6VS8.net
動的型付け言語しか慣れてない初心者が静的型付け言語に慣れるまで時間がかかるのは当たり前
GC前提言語しか慣れてない初心者がそうでない言語に慣れるまで時間がかかるのは当たり前
プログラミングに向いてる人ならどちらもすぐに慣れる
そんなことで文句を言っているようではプログラミングに向いていない
11:デフォルトの名無しさん
24/02/24 17:13:41.82 V+W4sktV.net
Rustの型オナニーは「本当は1つにまとめても良いんだけど歴史的経緯で2種類あります」みたいなのが稀にあって気持ち良くない
12:デフォルトの名無しさん
24/02/24 17:33:53.05 rpcvr5yl.net
>>10
妄想楽しいですか？
13:デフォルトの名無しさん
24/02/24 18:25:50.38 +fQ0JdTj.net
>>8 それRust特有だよね 時間がどんどん溶ける
14:デフォルトの名無しさん
24/02/24 18:33:24.91 Sbx59RJL.net
asはそろそろFrom/TryFromに統一してほしいんだけど
15:デフォルトの名無しさん
24/02/24 20:45:24.03 Mj/QkYpd.net
型オナニーって全部習得するまでにいったいどれだけ時間かかるんだ
16:デフォルトの名無しさん
24/02/24 20:47:39.26 fAQkBdOO.net
型オナニー四十八手
17:デフォルトの名無しさん
24/02/24 22:10:17.16 SuzjS9X3.net
>>13
機能が異なるので統一されない
asはcastなので変換From/TryFromとは異なる
例えばi32からu8の場合は変換できない値があるため
impl From<i32> for u8は実装がなく
impl TryFrom<i32> for u8の実装があり
u8::try_from(-3_i32)は変換できずErrとなる
一方でasはcastなので-3_i32 as u8は8bitに切り捨てられ252となる
18:デフォルトの名無しさん
24/02/24 22:13:12.85 SuzjS9X3.net
打ち間違い
252でなく253ね
19:デフォルトの名無しさん
24/02/24 22:51:22.10 Sbx59RJL.net
>>16
それだけならstdにimpl From<i32> for Wrapping<u8>でも入ってくれれば事足りると思うが……
asって手軽なだけで変換元と変換先の型ごとに意味が複数あるのが複雑で嫌いなんじゃ
C++のC形式キャストみたいな印象
20:デフォルトの名無しさん
24/02/24 22:53:55.08 Sbx59RJL.net
え、てかそもそも演算オーバーフローはpanicするのにキャストはpanicしないのか
だるっ
そういうとこやぞ
21:デフォルトの名無しさん
24/02/24 23:26:44.50 1jp0hNdJ.net
生演算子はオーバーフローせずラッピングされる
panicはデバッグ時のみ
明示的にラッピングしたいときはwrapping_add
オーバーフローを処理したいときはchecked_addやoverflowing_addまたはsaturating_add
22:デフォルトの名無しさん
24/02/25 01:04:03.14 /M3V/hwr.net
型オナニーって複雑な型パズルを解いて悦に入ることを言ってるのかと思いきや
標準ライブラリの基本的な使い方を覚えることなのかよ
オナニー要素ゼロじゃん
そんなマインドではRustに限らず言語習得は無理だぞ
23:デフォルトの名無しさん
24/02/25 01:05:34.01 PHCSkV3G.net
そんなマインドでもGo言語なら習得出来るんだよなあ
24:デフォルトの名無しさん
24/02/25 01:14:51.15 Y4TucXFt.net
バカはGoへ行くしかないよ
Rustなどは一般的なプログラミング能力がある人向け
25:デフォルトの名無しさん
24/02/25 01:52:59.15 5QMstwYR.net
>>22
それはたまたま動いてるようなもんだぞ。
26:デフォルトの名無しさん
24/02/25 09:14:13.54 F2CUOiYD.net
Rustの開発って時間掛かりそうなイメージある
とりあえず作ってみて後でリファクタリングって作り方ができない感じ？
27:デフォルトの名無しさん
24/02/25 09:49:58.55 JC//7tos.net
termuxよりscreen派なんだよなぁ。ライセンスはgplよりbsdのが好きなんだけど。
28:デフォルトの名無しさん
24/02/25 10:13:55.36 CWUdGBuB.net
>>21
リアルの会話でこうやってRustのマイナス面を他と同じと言う奴は
内心信用してない
>>23
言い方があれだけどこっちの方が信用できる
29:デフォルトの名無しさん
24/02/25 10:16:51.38 m/LZ7YZH.net
>>25
リファクタリングってのは外部から見た時の挙動を変えないのが原則なので
少なくとも型やライフタイムについては辻褄が合っていることを保証できる仕組みは
リファクタリングでも便利なんだぞ。
内部的な処理でもあまり柔軟には変えづらいということはあるけど
変えづらいところは (外部に対する保証に関わってくるので) 変えてはならない箇所だってことがわかる。
30:デフォルトの名無しさん
24/02/25 10:21:38.07 UdSUU0Ni.net
>>9
✕プログラミングに向いていない
○rustに向いていない
皆さん、これがrust信者です
31:デフォルトの名無しさん
24/02/25 11:59:50.84 sgD3xFEl.net
>>6
せめてtraitに外延性があって集合的操作ができればいいんだけど、さすがにビルドに時間掛かりそうだしな。
ただでさえビルド時間が重たいから、設計の「早すぎる最適化」は仕方ないのかね。
32:デフォルトの名無しさん
24/02/25 12:12:53.79 swktBlsa.net
>>26
screenってまだメンテされてんの？
33:デフォルトの名無しさん
24/02/25 12:43:55.95 JQupN8F5.net
>>28
例えばpythonとかだと型とかプログラム構造気にせずにパパッと書いて
ある程度動くスクラッチでレビューして内容詰めて
スクラッチから流用できそうなら作り込んでリファクタリングみたいにできるけど
Rustだとそういう風にできなさそう
34:デフォルトの名無しさん
24/02/25 12:48:37.70 AFiN8NTf.net
>>23
こういうのに限ってgoでもろくなもの書けない
35:デフォルトの名無しさん
24/02/25 12:50:53.73 lnNUwEQk.net
>>32
Pythonだとそのリファクタリング前後で挙動が変わってしまわないように気を遣うのがしんどいな
そういうとりあえず試しに作るケースだとユニットテストなんかも当然ない状況なんで
Rustに限らず静的型ならその辺をだいたいコンパイルエラーで拾えるのが楽
36:デフォルトの名無しさん
24/02/25 13:03:20.25 WCq5qF7l.net
>>27
「僕は基本Traitがよくわからない => それはRustのマイナス面」
この発想が幼稚さがわからないのかな？
他の言語と比べたときのRustのマイナス面はたくさんあるがそういう話のレベルじゃないだろ
37:デフォルトの名無しさん
24/02/25 13:05:42.89 Y4TucXFt.net
>>32
動的型付け言語しか使ったことがない初心者が
静的型付け言語の圧倒的なメリットを理解できないのはよくあるあるある
脱初心者の壁を乗り越えよう
38:デフォルトの名無しさん
24/02/25 13:18:05.49 Y4TucXFt.net
どんな言語にもマイナス面がありRustにもある
しかしマイナス面を上回る莫大なメリットがRustにはいくつもあるからIT業界をあげてRustを支援＆採用している
揚げ足取りでRustを叩きたいだけの人はアンチスレへ行け
39:デフォルトの名無しさん
24/02/25 13:23:45.23 /3HpHAOM.net
>>36
知らないのかもしれないけど今のPythonはどちらもできる
40:デフォルトの名無しさん
24/02/25 13:29:34.11 cAT3nYdz.net
>>35
どんな理由であれ複雑なのはマイナスだろ
複雑なのがプラスだってんならC++かbrainfuckやれよ
41:デフォルトの名無しさん
24/02/25 13:33:19.74 m/LZ7YZH.net
漸進的型付けは静的片付けと動的型付けのどちらも出来るわけではなくて漸進的型付けという別物だと解釈すべきだと思うよ。
42:デフォルトの名無しさん
24/02/25 13:35:59.16 m/LZ7YZH.net
>>39
能力が同じなら複雑さはマイナスだが複雑にしてでもそれを上回るメリットが得られることがあるという話だということも理解できないの？
トレードオフ
43:デフォルトの名無しさん
24/02/25 13:47:25.26 cAT3nYdz.net
>>41
>>35はそんなこと書いてないぞ
> 「僕は基本Traitがよくわからない => それはRustのマイナス面」
> この発想が幼稚さがわからないのかな？
だぞ。勝手に自分の文脈を他の人のレスに上乗せして書いてない解釈を押し付けるなよガイジ
44:デフォルトの名無しさん
24/02/25 13:51:18.30 qsle6rXj.net
Rustで有名アルゴリズムに挑戦 第16回 Rustで機械学習に挑戦 - k近傍法でアヤメの分類をしよう
URLﾘﾝｸ(news.mynavi.jp)
共同作戦で壊滅したマルウェア「Qakbot」復活、米国は犯行グループを逮捕できず
URLﾘﾝｸ(news.mynavi.jp)
悪意あるPythonパッケージを2つ発見、DLLサイドローディング技術悪用
URLﾘﾝｸ(news.mynavi.jp)
充電式バイブレータからマルウェア検出、USB充電デバイスに注意
URLﾘﾝｸ(news.mynavi.jp)
45:デフォルトの名無しさん
24/02/25 13:53:04.35 Y4TucXFt.net
ここはRustユーザが集うRustスレ
叩きたいだけのキチガイはアンチスレへ行け
46:デフォルトの名無しさん
24/02/25 13:56:41.04 Y4TucXFt.net
>>43
なるほど
URLﾘﾝｸ(news.mynavi.jp)
47:デフォルトの名無しさん
24/02/25 14:00:42.93 qsle6rXj.net
C++の後継目指すプログラミング言語「Carbon Language」、Googleの技術者が実験的公開。C++は技術的負債で改良が困難と
URLﾘﾝｸ(www.publickey1.jp)
48:デフォルトの名無しさん
24/02/25 14:05:55.86 gx/ep+tD.net
>>37
嘘はいかんよ
Rustにはメリットなし、がIT業界の総意
Adaの方が上
最新版IEEE調査Jobs
URLﾘﾝｸ(i.imgur.com)
49:デフォルトの名無しさん
24/02/25 14:10:17.03 cAT3nYdz.net
Jobで判断するのはちょっとなあ
Jobの要件にするのってその言語さえ出来れば良い人を探す時じゃん
Rustってまだそのフェーズではないんだよな
50:デフォルトの名無しさん
24/02/25 14:19:17.62 2NfnhAyO.net
>>48
言うてメインはOSS用だよね
大手はちょっとばかり資金援助してレバレッジ効かせようと宣伝して
2021-2022がRustハイプのピークだったんだけど真水のJobは稀
51:デフォルトの名無しさん
24/02/25 14:25:08.84 zbRFIfV6.net
>>46
Carbonはその公式FAQに明記してるように
Rustを使える状況ならRustを使ったほうがいいという立ち位置
Carbonは既存のC++遺産メンテ用
52:デフォルトの名無しさん
24/02/25 14:32:26.24 is3AzB4D.net
>>49
次々とRust製へ変わっていってる
リソース面すなわち経済的にもエコ的にもRustが有利なので今後次々とRust製へ置き換わっていく
ソース
＞【クラウド世界トップシェアAWS】
＞URLﾘﾝｸ(japan.zdnet.com)
＞Rustで構築されたAWSサービスの例としては、
＞コンテナーアプリ用のサーバーレスプラットフォーム「Lamba」を支える「Firecracker」、
＞「Amazоn Simple Storage Service（S3）」、
＞「Аmazоn Elastic Compute Cloud（EC2）」、
＞コンテンツ配信ネットワーク「Аmazоn CloudFront」、
＞LinuxベースのコンテナーOS「Bottlerocket」などがある。
＞【CDN世界トップシェアClоudflare】
＞URLﾘﾝｸ(www.publickey1.jp)
＞CDNプロバイダのCloudflareは、同社のグローバルなCDNの基盤として長らく利用してきたNGINXに代えて、
＞同社自身がRust製のHTTPプロキシである「Pingora」を開発し利 用していることを明らかにしました。
53:デフォルトの名無しさん
24/02/25 14:38:19.37 +AfYZ5AE.net
Rustは知らず知らずのうちに技術的負債を量産しそうな気配だな
Rustは既に違法建築だから
前スレで言われる矮小化オンパレードで笑ったw
前スレ
ｽﾚﾘﾝｸ(tech板:9番)
>>ｽﾚﾘﾝｸ(tech板:990番)
一応知らない人のために書いておくけど
「Rustがunsafeコード一切なしでメモリアンセーフ」な事が判明してから半年近く経ってる
特定の機能導入のタイミングでコードが発見されたけど、
「Rustの仕様バグ」だと認識されていて直せない
>>4
そんな事並べて理解したつもりでも、分からないと言っている人の側の主張が正当なんだよ
最近はここでも保証って言われなくなっただろ、当たり前だよRustの仕様に健全性が無いのだから
たぶん知っていて話を逸らしているのか、過去スレでスルーしたかで、この指摘も無理やり矮小化してくるからな
(githubの議論でも矮小化して放置)
気を付けろよ
URLﾘﾝｸ(github.com)
54:デフォルトの名無しさん
24/02/25 14:45:16.11 8UflVtOh.net
>>52
情報古いな
AmazonはLLRTでしょ
cloudflareのRustは放置だ
55:デフォルトの名無しさん
24/02/25 14:48:00.26 3ePlkypT.net
誰も問題視していないどうでもいいことでしかRustを叩けない状況
アンチが追い込まれている
56:デフォルトの名無しさん
24/02/25 14:53:16.67 8UflVtOh.net
>>53は>>51向けな
>>52のは違うIssue/PRのcommitで場当たり的fixしただけで知れっと本質を隠蔽した
>>54
問題視したから取り繕いfixしたんだよ
57:デフォルトの名無しさん
24/02/25 14:56:15.69 8UflVtOh.net
>>37,47
上位は納得だから結局のところ「IT業界をあげて」なんて言いたかったら
Jobで判断するのが客観的で中立フェアな基準なんだな
58:デフォルトの名無しさん
24/02/25 14:59:17.67 GfahaNNz.net
>>53
LLRTはAWS LambdaでJavaScriptを使いたい人向けのJSランタイムの一つ
Rustが使えるならRustを使ったほうが有利
さらにAWS自体も>>51にソースがあるようにRustで書かれている
59:デフォルトの名無しさん
24/02/25 15:03:11.52 h80FlwFJ.net
>>57後半
部分的にな
あとそのソースとやらのLiam Tungはいなくなったね
飛ばし過ぎた？
60:デフォルトの名無しさん
24/02/25 15:09:15.42 h80FlwFJ.net
>>57
>Rustが使えるなら
時々見るこの枕詞は実際の現場では使えない事の証拠なんだよなぁ
61:デフォルトの名無しさん
24/02/25 15:10:35.35 h80FlwFJ.net
>>57
>JavaScriptを使いたい人
これが圧倒的だからAmazonが独自魔改造したから凄い
62:デフォルトの名無しさん
24/02/25 15:27:26.81 GfahaNNz.net
>>59
そのAWS Lambdaでも当然Rustを使えます
Rustを使えないのは環境ではなく低層プログラマー
63:デフォルトの名無しさん
24/02/25 15:30:50.61 na8ub8Oh.net
>>55
この恣意的な例以外で同様の脆弱性が生まれる例があれば教えて欲しい
煽りとかではなく
64:デフォルトの名無しさん
24/02/25 15:48:37.00 3ZfnE9eN.net
>>62
俺も煽りじゃなく警鐘で言うけど
>>55の根本原因究明がならなかったから、今後も散発的に発見しては穴ふさぎをするのでは
(CVE報告しないで悪用されたら最悪だけど)
Rustのメモリ安全性目標チェックは他の言語と比べて
相対的にメリットがあったりデメリットがあったりするだけのことだから
65:デフォルトの名無しさん
24/02/25 16:02:53.19 4fScDWQR.net
>>62
恣意的ってそういう意味じゃないですよ
66:デフォルトの名無しさん
24/02/25 16:07:08.08 na8ub8Oh.net
例出せないならお前が偉そうに言うことではないぞ
どの立場からもの言ってるんだ？
67:デフォルトの名無しさん
24/02/25 16:10:58.09 37W0dlDW.net
>>65
化けの皮が剥がれるの早すぎて草
68:デフォルトの名無しさん
24/02/25 16:11:46.86 na8ub8Oh.net
俺の質問に答えずに訳のわからないことを言うしかできないんですね
くだらないクズが
69:デフォルトの名無しさん
24/02/25 16:14:14.27 wVCQJTWx.net
>>52
実際の開発では出てこない極端に作り上げた例のみだから
Rustを採用しているIT大手を含めて問題視していない
70:デフォルトの名無しさん
24/02/25 16:19:05.44 5Lw05PSN.net
>>66
ちなみに急に煽り始める>>65,67はあのコテハン
>>68
>実際の開発では出てこない極端に作り上げた例
自分で踏んだ事ないから想像だけど、失敗を犯すのはその考え方の人間
71:デフォルトの名無しさん
24/02/25 16:21:52.97 na8ub8Oh.net
いや煽ってきたのはお前だろw
何を勘違いしてるんだ
72:デフォルトの名無しさん
24/02/25 16:23:31.57 na8ub8Oh.net
自分が攻撃するのは良くて攻撃されるのは嫌か？
そういうやつには徹底的にやるから覚悟しろよ
俺に攻撃するってことはそういうことだ
73:デフォルトの名無しさん
24/02/25 16:24:39.64 4fScDWQR.net
誰やねん
74:デフォルトの名無しさん
24/02/25 16:27:11.46 LjVpirDf.net
自分以外が全部同一人物だと思い込んでるアタオカの着火点は意味不明だよな
75:デフォルトの名無しさん
24/02/25 16:31:47.21 wVCQJTWx.net
>>69
実際にコードを見てごらん
ありえない無意味なコード
識者たちも問題視していない
76:デフォルトの名無しさん
24/02/25 16:36:11.19 sIg5Fob3.net
>>71 誰も攻撃してないのにこの人怖い、やめてくれませんか
心理的安全性を通り越して身の危険を感じる((((；ﾟДﾟ))))ｶﾞｸｶﾞｸﾌﾞﾙﾌﾞﾙ
77:デフォルトの名無しさん
24/02/25 16:37:37.04 4fScDWQR.net
例の#25860、ジェネリクスとかマクロ生成の裏で意図しないでこのパターン踏んだりしない？
絶対ない？
78:デフォルトの名無しさん
24/02/25 16:37:39.99 muM7k3Ml.net
rustでリファクタリングしながらの開発ってなると多分unsafeを途中経過で入れたりとか
そういうテクニックが必要になると思う。
その辺の整備が進めば割と広まるかもね。
79:デフォルトの名無しさん
24/02/25 16:45:35.35 wVCQJTWx.net
>>76
絶対にないから安心していい
その「&'static &'a ()」が出てくることはない
80:デフォルトの名無しさん
24/02/25 16:50:17.61 4fScDWQR.net
>>78
理由は？
81:デフォルトの名無しさん
24/02/25 16:51:49.35 zhB6NxSY.net
>>32
サクッとプロトタイピングする目的ならそりゃRustよりPythonのほうが向いてる
Rustは多少手間がかかったとしても速度・安全性・堅牢性を高い水準で求める場合に使う言語
>>39
AsRefやTryFromが複雑とか言われても困ります
82:デフォルトの名無しさん
24/02/25 16:52:52.76 hjrqLcFN.net
>>77
unsafeは基本的に不要
必要だと思ってもまず標準ライブラリにその機能がないか調べる
次にクレートにその機能がないか調べる
どこにも存在しない場合
unsafeを安全に閉じ込めて安全に使うことができる有用な機能を発見したのならばラッキー
それをクレートとして公開するとよい
83:デフォルトの名無しさん
24/02/25 17:06:44.48 4fScDWQR.net
Rustコンパイラチームは意図せず発生する可能性を否定していない様子
ここのヤツはやっぱりテキトー言ってるだけか
URLﾘﾝｸ(hackmd.io)
> URLﾘﾝｸ(github.com)
> root issue of most variance issues
> ⚠🚨⚠ can potentially just happen by accident
84:デフォルトの名無しさん
24/02/25 17:26:51.68 O13egj5J.net
>>77
同じ構造体の一部を参照しながら別の一部を書き換える大きめのメソッドを
複数のメソッドに分割しようとするとborrow checkerに引っかかる的な話かな
他の言語のクラスと同じ感覚で構造体作るとたまに嵌る
Rustの構造体はRDBのテーブルを正規化する雰囲気で分割した方がいい
85:デフォルトの名無しさん
24/02/25 17:30:07.94 hjrqLcFN.net
>>82
Rustのvariance仕様だから発生させることはできるけど
現実に使うコードでは発生しない
意図的にその仕様の狭間をつく現実的でないコードでのみ発生する
そのためその2015年からそのまま放置で誰も困っていない
86:デフォルトの名無しさん
24/02/25 17:45:11.19 4fScDWQR.net
>>84
by accidentを辞書で引いてこい
87:デフォルトの名無しさん
24/02/25 17:51:15.22 hjrqLcFN.net
>>85
その2015年から9年間
その問題でトラブルが起きたことがない
88:デフォルトの名無しさん
24/02/25 17:55:53.01 bLJeGl/a.net
>>81
>unsafeは基本的に不要
>...ラッキー
嘘で始まって運頼みで締めるとはw
信者の心の支えの大手のあそこは
見境なくunsafeを使わざるを得なくなって
Rustでやった意味が無くなってるってよ
89:デフォルトの名無しさん
24/02/25 17:56:42.46 m/LZ7YZH.net
可能性を論じるならお前の頭に隕石が落ちてくる可能性だってあるが、そんなことを心配したことある？
90:デフォルトの名無しさん
24/02/25 18:03:36.71 c6Ww7brW.net
RustはVec等のCVE前科があるからなぁ
頭に隕石が落ちたんじゃね？
91:デフォルトの名無しさん
24/02/25 18:07:11.51 e56nXER6.net
開発プログラムでunsafeを直接使うことはほとんどない
unsafeが閉じ込められ安全なインターフェースが公開されている形で間接的にのみ用いる
どうしてもunsafeが必要になった場合でもそのように安全な形で分離して用いる
92:デフォルトの名無しさん
24/02/25 18:10:03.77 4fScDWQR.net
隕石であれ何であれそれがエンジニアリング可能な対象なら問題を特定して語る意味はあるだろう
93:デフォルトの名無しさん
24/02/25 18:19:05.40 e56nXER6.net
>>89
Dropで型がpanicする時にその要素をた用いたVec::from_iter()で二重解放のバグが発見された件か
もちろん他の言語と同様に全ての言語においてライブラリにバグが見つかることは当然ある
Rustはその点でも少ない方なので信頼して使える
94:デフォルトの名無しさん
24/02/25 18:30:56.08 F3hFw1lw.net
>>90,92
思い描く理想と現実の落差が激しいな
Rust不信の原因だぞ
とくに>>92の最後の行があるから信用されない
95:デフォルトの名無しさん
24/02/25 18:43:22.50 hlYoDW1g.net
Rustの2023年のCVEはCargoで名前をエスケープし忘れた1件のみ
Rustの2022年のCVEは0件
つまりRustコンパイラについて過去2年間でCVEなし
信頼度が高いと言える
96:デフォルトの名無しさん
24/02/25 18:49:05.16 cAT3nYdz.net
Rust以外のコンパイラってそんな言うほどバグないか？
97:デフォルトの名無しさん
24/02/25 19:34:08.90 O13egj5J.net
普通にあるけどみんなで使うから大部分はリリース前に潰される
コンパイラというよりライブラリのバグみたいだけど他の言語より未定義動作にシビアだから
バグ扱いされる事例が増えるのは仕方ない
98:デフォルトの名無しさん
24/02/25 19:46:15.91 pvICb5ke.net
>>91
お前のとこは無限のリソースがあるのかな？
いいなぁ優先順位考えなくていい環境。うらやましいよ。
99:デフォルトの名無しさん
24/02/25 19:49:21.58 +aJmKKn5.net
今となっては未定義動作の多い言語を使うのは悪行だ
Rustを使うべし
100:デフォルトの名無しさん
24/02/25 20:11:25.55 yYiD0TuW.net
>>82
ここの信者はテキトー過ぎるよな
コンパイラ開発チームはもとより、サーベイ回答者もコンパイラバグ潰しを最優先、が一番多い
101:デフォルトの名無しさん
24/02/25 20:15:02.43 yYiD0TuW.net
>>97
余裕があるからRustもやる、と言うのが普通だな
サーベイでも(余裕がなくなって)Rust採用予定なし、なぜなら他言語採用予定だから、が一番多い
(ただし採用にはインターンも含まれる)
102:デフォルトの名無しさん
24/02/25 20:24:50.38 0y8maAN+.net
>>99
対処の必要があるものはその通り
しかし実害がないと皆が判断して対処優先度低いまま9年間が経過したが実害がな起きていない
そんな状況のものを杞憂したり揚げ足取りでRustを叩いてる連中がゴミ
103:デフォルトの名無しさん
24/02/25 21:16:46.71 4fScDWQR.net
事実を書かれただけで批判だと思っちゃうようじゃ生きづらかろうな
104:デフォルトの名無しさん
24/02/25 21:34:47.98 E/2LoMBL.net
>>101
これが矮小化と言うやつか
7割がバグ潰しを「最優先」と回答している事実
直したくても直せないまま何年も経過、unsafe無しでメモリ安全ではない(事実)、Rustの不健全仕様(事実)
(unsound=不健全は数学用語、要は矛盾があるという事)
幸運にもRustが使われなさ過ぎで実害がないように見える(または報告がないだけ)
(良心的に考えてRustが広く使われてない内に)バグ潰しをしとけ、がユーザーの9割の意見(中優先含めて)
週明けのテック記事はどう書くのかな
良い所だけ抜き出してビューが取れるハイプ期間は弱まったと思う
それと飛ばし過ぎるといなくなるorz
105:デフォルトの名無しさん
24/02/25 21:37:20.20 PFD3HMoN.net
アンチもMozillaが変なことやってるだけで
firefoxに導入できるわけがない一般人が
使えるようになるのは妄想とか
言ってた頃に比べると細かい実装の穴を
ネチネチやるまでになって大変だなあ
106:デフォルトの名無しさん
24/02/25 22:03:27.18 cpTMj4Oj.net
>>103
根本的なことを理解できてないようなので一点だけ
unsafeがプログラム全体に散らばっている他の言語に対して
Rustはunsafeを局所的に閉じ込めて安全なインタフェイスを公開しそれを使ってプログラミングする言語
よく使われる基本機能は標準ライブラリとしてunsafeを閉じ込めてあるが
必要なら自作を含めてunsafeを閉じ込めたライブラリを使ってよい
他の言語と比べてunsafeを局所的に閉じ込めた部分のみ注視すればよいことがRustのメリット
107:デフォルトの名無しさん
24/02/25 22:16:32.90 uv4EdbLT.net
>>105
unsafeに閉じ込められなかった事実を提示されてるんだが何言ってるんだ？
108:デフォルトの名無しさん
24/02/25 22:32:50.41 cAT3nYdz.net
Rustコンパイラにバグがあ
109:るのはかなりキモくて嫌だけど、Rustの利用をやめるほど致命的かというとな
110:デフォルトの名無しさん
24/02/25 22:47:36.07 m/LZ7YZH.net
C++ の未定義を踏んでもおかまいなしってよりは原則として問題は検出する (けどちょっとはバグもある) Rust のほうがだいぶんマシな言語設計ではある。
111:デフォルトの名無しさん
24/02/25 23:03:18.85 AXW02Nd1.net
unsafeなライブラリがRust用の安全なインターフェースを公開することにより保証される安全性とは
もちろん呼び出される側の安全性ではない
呼び出す側だけが検査される
しかも検査が完璧かどうかは実装依存
じゃあ言語仕様により保証されるのは何か
言語仕様は、あとは検査が通るか通らないかを確かめればよいというところまで仕様を確定しなければならない
112:デフォルトの名無しさん
24/02/25 23:10:45.79 Wz/bOaUk.net
プログラム全体がunsafeなC/C++は使いたくない
未定義な動作も多すぎる
113:デフォルトの名無しさん
24/02/25 23:49:12.62 bSwN5N4x.net
>>109
Rust関係無しに基本的なことを理解できてないようだけど
掛ける情けも無し
114:デフォルトの名無しさん
24/02/26 00:02:36.23 cKYYV9zq.net
反論できないときは関連するワードを含むRustの宣伝文句をぶつける
いつもの流れです
115:デフォルトの名無しさん
24/02/26 00:08:01.38 GUFKxV6c.net
難易度は高くとも増加するユーザー、Rustチーム2023年調査「State of Rust Survey」 難易度は高くとも増加するユーザー、Rustチーム2023年調査「State of Rust Survey」
URLﾘﾝｸ(news.mynavi.jp)
116:デフォルトの名無しさん
24/02/26 00:10:06.79 nyM0yI5t.net
>>105,109
詐欺師みたいな偽者だな、Rust不信の種まきするのやめろ
>>112
分かっていれば支離滅裂文章なんだけど騙されるのは学生位だろうか
117:デフォルトの名無しさん
24/02/26 05:11:35.79 G5weOmRY.net
>>前スレ992
Derefは演算子
・そのためstd::ops::Derefにある (変換std::convert::AsRefと対照的)
・演算子*によりderefされる
・&**へとcoerceされる
118:デフォルトの名無しさん
24/02/26 13:22:06.51 vLFZOOEE.net
Derefの名前の由来は*演算子（dereference：参照解決）だろうけど
機能は&**へのcoerceを前提にしてて結果的にrefのままだからややこしいな
現状だとInnerRefの方がしっくりくる
119:デフォルトの名無しさん
24/02/26 13:34:26.79 vLFZOOEE.net
意味的にはFollowRefの方が自然かな
まあ*演算子で使われるtraitだからDerefでいいんだけど
120:デフォルトの名無しさん
24/02/26 17:12:18.82 hotfpUjh.net
【AI】Stable Diffusion 3発表、Soraで話題の拡散トランスフォーマーを採用 [すらいむ★]
ｽﾚﾘﾝｸ(scienceplus板)
ボイス・トォ・スカるしている者も攻撃を受けるようになりました
121:デフォルトの名無しさん
24/02/26 18:21:55.22 K4z1iUSz.net
>>115
>・&**へとcoerceされる
これDeref Coercionのこと言ってる？ だとしたら&**に限定する意味がわからない
あと前スレ992で重要なのは&T→TはDerefの役割ではないというところね
>>116,117
スマートポインタのdereferenceのために存在するTraitだから
InnerRefやFollowRefよりDerefのほうがずっと自然だと思う
*演算子の振る舞いとは別にcoercionの振る舞いは理解しなければいけない
そういう点でも「Derefは演算子」という捉え方は良くないよ
122:デフォルトの名無しさん
24/02/26 19:05:39.95 CpQkWMmQ.net
Rustて、演算子と関数を(意味論的に)区別していたっけ？
中間記法によるややこしい結合順の違いがあるぐらいで、構文解析後は等価だから、あんまりこだわっても仕方が無い気が。
中間記法の演算子は人間の算数の記法に配慮しているだけの悪習でしか無いから、積極的に差異をつけないほうが良い気がするけど。
123:デフォルトの名無しさん
24/02/26 19:26:28.00 pFLZLcAJ.net
Deref に関しては * 演算子として機能する以外に型強制の規則があるという話の文脈。
124:デフォルトの名無しさん
24/02/26 19:44:24.36 vLFZOOEE.net
+に対するAdd, &=
125:に対するBitAndAssignと同じ位置づけで (*T)に対するDerefがstd::opsに入ってるイメージだけど (*T）自体は let x: Box<String> = Box::new(String::from("foo")); let y: String = *x; みたいに参照先の値を取り出す使い方ができてむしろそっちが本来の意味なのに それができないtrait DerefがDerefを名乗ってるのが微妙だと思った
126:デフォルトの名無しさん
24/02/26 19:45:57.01 CpQkWMmQ.net
>>121
サンクス。
「演算子」じゃなくて「 * (参照外し演算)」ということね。
127:デフォルトの名無しさん
24/02/26 19:57:36.80 31wdHwrp.net
>>116
*を明示的に付けるとdereferenceされるからDeref
&**によるcoerceは何も付けずに適用される
そのため参照から参照へ型が変わるだけで参照のままとなる
>>119
Derefはoperatorなのでstd::opsにある
Derefでも&T→Tと実装されている
Derefによるcoerceは&**となる
128:デフォルトの名無しさん
24/02/26 20:43:46.74 YO//rx0m.net
関数と同じでは困るものといえば && || が有名だけど = が一番やばい
初期化とか代入とかコピーとか移動とか
129:デフォルトの名無しさん
24/02/26 20:52:21.27 isya6kWo.net
>>125
=はパターンマッチング
マッチングした時にCopy実装があればコピーされる
以上で極めてシンプル
130:デフォルトの名無しさん
24/02/26 21:10:51.91 ucgwnOih.net
Rustにおける = は心の中でバインド演算子って呼んでるわ
131:デフォルトの名無しさん
24/02/27 01:03:26.56 38wv4xDP.net
>>124
>Derefはoperatorなのでstd::opsにある
URLﾘﾝｸ(doc.rust-lang.org)
ここ見ればわかると思うけど各Traitの説明に”The ~ operator”と書いてるものがoperator
Derefは”Used for immutable dereferencing operations, like *v.”とあるようにDerefそのものはoperatorではない
>Derefでも&T→Tと実装されている
Deref<Target=T> for &Tの実装が提供されてるのは別の役割のため
その実装が実行されて&T→Tになっているのではない
Box<T>→Tなんかも正確に言えば&Box<T>→&T
>Derefによるcoerceは&**となる
全然わからない
何か一つくらい根拠を提示してくださいな
132:デフォルトの名無しさん
24/02/27 01:17:48.86 keoFxKh8.net
Derefによるcoerceは&**となるのが全然わからないって本気なのかな？
「corece後の参照」= &**「corece前の参照」
となるのがDerefによるcoerceだよ
133:デフォルトの名無しさん
24/02/27 03:35:57.72 Q3TDZDiV.net
READ THE FUCKING MANUAL
URLﾘﾝｸ(doc.rust-lang.org)
134:デフォルトの名無しさん
24/02/27 05:16:27.87 2XUMNloz.net
>>129
＞「corece後の参照」= &**「corece前の参照」
実験コード書いて一通り確認してみたら
たしかにそうなった
135:デフォルトの名無しさん
24/02/27 08:57:02.46 +775Shg6.net
上の一連の流れ見てるだけでRustしんどそうに見える
136:デフォルトの名無しさん
24/02/27 10:40:40.53 90WdzyYj.net
>>129
なるほどそういう風に捉えてるのか
ちょっと独特だね
それはcoercionの動きというよりderefのシグニチャを
内部的にderefを使ってる*演算子で再定義しようとしてるので
循環が気持ち悪いけど一つの見方として頭の隅にしまっておく
ちなみにThe Bookにある一つの例ではderef coercionがなければ*が余計に必要と説明されてる
URLﾘﾝｸ(doc.rust-lang.org)
それに&**とは必ずしも等価じゃないからDeref Coercionを説明するのにはあまり勧められないかな
let x = "Hello".to_string();
let y = Box::new(x);
let z = &**y; //zは&strになる
let z:&str = y; //これはcoerceしないのでコンパイルエラー
137:デフォルトの名無しさん
24/02/27 10:44:06.64 HDl/V1Sy.net
こんな議論が発生する時点でかなりややこしくて面倒な言語がであることは認めざるを得ない
138:デフォルトの名無しさん
24/02/27 11:23:28.24 gx7SRESn.net
そんなことよりDerefの定義の中で参照外ししている↓が無限ループにならない理由でも調べてみたほうが面白いよ
URLﾘﾝｸ(doc.rust-lang.org)
139:デフォルトの名無しさん
24/02/27 11:27:25.60 90WdzyYj.net
>>135
それが&T→TはDerefの役割ではないという話
140:デフォルトの名無しさん
24/02/27 11:56:56.99 xI+UYr05.net
rustは使い勝手のために暗黙にokにした構文が逆にわかりづらさを生んでる。
141:デフォルトの名無しさん
24/02/27 12:07:27.17 NfALWDmT.net
>>137
まあそれは他の言語も歩んできた道だから……
良いとは言わんけどなくてもめんどいんだよな。
142:デフォルトの名無しさん
24/02/27 12:18:37.87 Q3TDZDiV.net
>>136
*selfはそれでいいけど、**selfはそれじゃ説明付かんぞ
143:デフォルトの名無しさん
24/02/27 17:59:37.59 KfBq61Mu.net
>>139
&T→Tと同じでBox<T>に対する*演算子もコンパイラビルトインだからDerefのimplは使われない
144:デフォルトの名無しさん
24/02/27 18:12:58.39 lr8nToMg.net
Rustってなんでzipを「簡単」に操作するクレートが一つもないんだ？
Tauriがこなれてきたからそろそろ.NETからアプリをRustにポーティングしようかなと思ったらエコシステムがまるで成長していない・・・
145:デフォルトの名無しさん
24/02/27 18:13:56.86 7nYMkiDR.net
>>133
まず基本を理解しよう
deref coreceは必ず参照から参照へのみ起きる
Box自体は当然deref coreceされない
その例だと
let b = Box::new("Hello".to_string());
まずc0は単なるBox参照
let c0: &Box<String> = &b;
このc1とc2がderef corece
let c1: &String = &b;
let c2: &str = &b;
そのc1とc2を明示的に書くとこうなる
let c1: &String = &**(&b);
let c2: &str = &**(&**(&b));
この暗黙に適用される&**がderef corece
この自動適用のおかげでstrのメソッドが使える
assert!(b.starts_with("He"));
フルに書くとこうでもちろん対象はbではなく&b
assert!(str::starts_with(&b, "He"));
この&bが前述の通り自動的に&**(&**(&b))となり&str型へcoreceされている
146:デフォルトの名無しさん
24/02/27 18:33:30.42 p5E54fv2.net
>>141
圧縮アーカイブならzipクレート
圧縮ならlibflateクレートなど
147:デフォルトの名無しさん
24/02/27 19:01:36.79 MCZ6xJKz.net
>>133
＞ coercion
横から素人がすまん、これ何て読めばいいの？
148:デフォルトの名無しさん
24/02/27 19:26:56.87 kSGISY6y.net
Rustもちょっと前の熱狂はなくなってしまった感じ
入込数が減ってると思う
149:デフォルトの名無しさん
24/02/27 19:39:57.60 ptyRkm62.net
まあ熱狂系の人は実用言語嫌いそうだし、熱狂系がいなくなったのは良いことでは
150:デフォルトの名無しさん
24/02/27 19:51:34.77 gLAGJv50.net
>>144
発音[US] kouə́ːrʒən ｜ [UK] kouə́ːʃən
カナ[US]コウアァジョン、[UK]コウアーション
参考：URLﾘﾝｸ(eow.alc.co.jp)
自分はコアジョン派
151:デフォルトの名無しさん
24/02/27 20:18:10.37 p5E54fv2.net
>>144
コアーション派
152:デフォルトの名無しさん
24/02/27 20:23:00.40 20aYglde.net
>>147
サンクス。愛してる
153:デフォルトの名無しさん
24/02/27 21:54:58.65 Tx+RemT0.net
Tのスマートポインタの参照 -> Tの参照
文字の配列
154:の参照 -> 文字のスライス 一連の流れを見るとみんなポインタに熱狂している
155:デフォルトの名無しさん
24/02/27 22:22:03.42 TDjpaGuA.net
>>150
そこはポインタと参照の根本的な違いを理解しできるかどうかかな
「Boxというスマートポインタ」の参照を扱うから意外に感じているのかもしれないが
「Boxというスマートポインタ」はヒープ領域の解放責任つまり所有権を持つ
したがってBox自体を他の関数などへ渡してしまってはmoveしてしまい継続して使えなくなる
だからスマートポインタの参照を渡すことになる
一見するとこれはポインタのポインタで無駄な間接参照に感じるかもしれない
しかし参照＝ポインタではなく参照は抽象的なものなのだ
156:デフォルトの名無しさん
24/02/27 22:43:38.35 NfALWDmT.net
Rust の参照は借用規則に関わることを除けばポインタとそんなに差はないし普通にオブジェクトの一種なんだよな。
C++ の参照はオブジェクトではなく参照の参照もとれないし参照のポインタもないし、
参照のサイズも取得できないというのに比べたら Rust の参照は実体のあるものとして感じられてしまう。
157:デフォルトの名無しさん
24/02/27 22:57:53.18 FQe9Y4YD.net
その橋渡し役がDeref coercion
&Box<T>はそのままだとTのポインタを持つBoxへのポインタとなってしまうが
Box<T>→TのDerefがあるため
&Box<T>→&TとDeref coercionが適用できる
静的にコンパイル時点で行われるため実行時コストはかからない
158:デフォルトの名無しさん
24/02/27 23:09:15.00 xLBlGeUv.net
>>142
この辺り最初理解するまで訳分からんかったな
理解すると大したことはないのだが
159:デフォルトの名無しさん
24/02/27 23:37:04.57 IkmURqSK.net
>>142
>deref coreceは必ず参照から参照へのみ起きる
&**との違いを認識してもらうための例を出したんだけど伝わらなかったみたいだね
それは別にいいんだけど書いてる内容を見る限り
Deref Coercionの動きを単に擬似的に再定義しようとして&**になると言ってるだけじゃなく
実際に&**が適用されると思ってるみたいに感じるね
だとしたらそれは完全な間違い
derefの実装の中で*演算子が使われることはあってもDeref Coercion自体は*演算子とは関係ないんだよ
Boxのderef実装だって*演算子を使わずself.ptr.as_ref()的な実装で実現してもいいわけだし
160:デフォルトの名無しさん
24/02/27 23:45:58.16 Tx+RemT0.net
とにかく、間接参照から直接参照を得る演算の名前はderefでいいんだよね
161:デフォルトの名無しさん
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結果)
162:デフォルトの名無しさん
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は&の向こう側でしか*を適用できない
163:デフォルトの名無しさん
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結果)
164:デフォルトの名無しさん
24/02/28 00:49:10.38 ZZ90UZAT.net
なんかゲシュタルト崩壊してきたんだがｗ
関係ないけど微積のdxとかdyを思い出してしまった
165:デフォルトの名無しさん
24/02/28 01:22:37.90 0HAFGBLs
166:.net
167:デフォルトの名無しさん
24/02/28 01:32:01.63 upo0sX/6.net
Deref coercion &**のうち
右側の*は参照に対する参照外しで
左側の*はDerefで定義(実装)されてるものなのね
168:デフォルトの名無しさん
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』も適用されていると思うぞ
169:デフォルトの名無しさん
24/02/28 11:30:56.58 eNJqE6SH.net
>>163
&&T→&Tのことを&T→Tとは書かないわな
前者の用途にDeref for &Tは存在してる
170:デフォルトの名無しさん
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メソッドを
演算子で擬似的に再定義しようとすれば&**になるというの話はかろうじて理解できるが
前述のように定義が循環してるだけでなく再定義する価値を見いだせない
171:デフォルトの名無しさん
24/02/28 18:08:21.49 8fminEVJ.net
なるほどね。勉強になるわ。
172:デフォルトの名無しさん
24/02/28 18:17:32.89 8gSKFNHr.net
>>164
&&T→&Tの場合もreference用のビルトインderefが先に動いてDeref for &Tの実装コードは動いてない可能性ない？
173:デフォルトの名無しさん
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
174:デフォルトの名無しさん
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とは&**の自動適用のこと
175:デフォルトの名無しさん
24/02/28 18:49:11.26 T3/1RdIi.net
*xが左辺値なら代入、*xが右辺値なら複製とかいう演算に
ビルトインderefみたいな名前をつけるのが間違っている
176:デフォルトの名無しさん
24/02/28 19:13:20.58 fjfA+uEG.net
>>170
mutabilityを除けば左右どちらも同じ型だから形が同じであることは問題ない
左はmutabiltyが必要だからderefではなくderef_mutと区別されていてその点でも問題ない
177:デフォルトの名無しさん
24/02/28 20:06:21.19 ZLPgyFVM.net
判りにくい仕組みだけどこれから開発が進むと
文法変えたりするのかな？
178:デフォルトの名無しさん
24/02/28 20:12:51.73 eWXh2LH7.net
これほど分かりやすくて便利な明確な仕組みはない
他の言語と比較すれば明らか
179:デフォルトの名無しさん
24/02/28 21:00:40.37 ZLPgyFVM.net
これが分かりやすいと思ってる人間には聞いてないよ
180:デフォルトの名無しさん
24/02/28 21:10:22.04 RYfxXFlC.net
他の言語でこれより良いものが存在しないね
RustのDeref
・自動適用されプログラマーの負担を軽減し利便性も良い
・魔法ではなくtrait Derefの実装に基づき動作して分かりやすく自作の型にも適用可能
・コンパイル時に静的に解決され実行時の付加コストゼロで高速動作
181:デフォルトの名無しさん
24/02/28 23:39:05.31 T3/1RdIi.net
>>172
Pythonが分かりやすいのは知ってるけど
RustとPythonは両極端だから文法を微調整してもしょうがない
文法を変える必要があるのは両極端を否定する言語だけだ
182:デフォルトの名無しさん
24/02/28 23:49:09.85 ZZ90UZAT.net
Derefなのに&が消えてない（小並感）
背景を理解しないと引っかかりやすいRustの七不思議候補
183:デフォルトの名無しさん
24/02/29 01:04:43.74 rccXx8PF.net
この仕組みがベストであるという主張は3種類ある
一つは馬鹿な信者が言ってるだけという可能性
一つは本当にこの仕組みがベストである可能性
最後は信者ではないけど素直な馬鹿だからもっと良い仕組みを知らない可能性
このどれであるかは賢い人間がもっと良い仕組みを教えてあげると判別できる
馬鹿な反論が返ってきたら馬鹿な信者
合理的な反論が返ってきたら本当にこの仕組みがベストかもしれない
意見を翻されたら素直な馬鹿
184:デフォルトの名無しさん
24/02/29 01:16:58.91 s7mEAt1S.net
この仕組みがない方が良いということ？
下手で全部書くべきと？
185:デフォルトの名無しさん
24/02/29 01:51:37.80 zTVrVDmh.net
RustのDerefとそのcoercion枠組みの利点
・プログラマーの負担が減る
・コードが見やすくなる
・枠組みはDerefトレイト利用で明白かつ汎用的になっている
・自分で作った型にも実装して作動させることができる
・静的に解決しているためミスしてもコンパイル時にわかる
・実行時に付加的な動作がなく高速に実行される
これらの利点を上回る方法があるならば知りたい
既存の言語でも新規の方法でも
186:デフォルトの名無しさん
24/02/29 03:43:48.10 JSOAwYd/.net
URLﾘﾝｸ(manishearth.github.io)
Boxのまほう
187:デフォルトの名無しさん
24/02/29 10:19:46.23 IetxPnTw.net
>>179
>下手で全部書くべきと？
どこかの方言？
188:デフォルトの名無しさん
24/02/29 12:07:39.99 /e0OxROz.net
>>178
いずれにせよRust信者は自分の信仰を他人に押し付けるために検証可能性を潰すから、科学とはほど遠い姿勢かと。
189:デフォルトの名無しさん
24/02/29 12:33:18.56 sM99e4qp.net
Rustの方式の利点は>>180に挙げられているから
もしRustより良い言語が存在するならば
その方式およびRustの利点を上回る利点を挙げればいいんじゃね？
190:デフォルトの名無しさん
24/02/29 12:41:20.92 JSOAwYd/.net
そんなに比較したいならﾜｯﾁｮｲスレ行けばいいんじゃね？
URLﾘﾝｸ(mevius.2ch.sc)
191:デフォルトの名無しさん
24/02/29 13:11:40.55 WGw1+Mi1.net
検証可能とはコンパイラが無謬であることではない
ここが難しい
コンパイラが未完成の状況でも人間が正解の一部をなぜか知っていること
これが検証可能
192:デフォルトの名無しさん
24/02/29 14:11:14.15 s7mEAt1S.net
>>182
この仕組みがない方が良いということ？
193:デフォルトの名無しさん
24/02/29 14:14:12.31 s7mEAt1S.net
単に理解できないから難癖つけてるだけだよねこの人
自分の主張も一切ないし
194:デフォルトの名無しさん
24/02/29 14:15:14.41 s7mEAt1S.net
誰かの難癖を自分が思い付いたかのように言ってるだけで
何一つまともな批判はない
195:デフォルトの名無しさん
24/02/29 14:15:53.86 s7mEAt1S.net
全く相手にすべき人間ではないと判断する
よって今後無視する
196:デフォルトの名無しさん
24/02/29 14:45:30.61 NVSKcdtL.net
>>184
それは「批判するなら代案出せ」と同じ議論を潰すだけの態度なのでやめよう
技術者なら自分が使っている道具の限界や弱点とは真摯に向き合うべき
その際他の道具との比較も必須ではない
197:デフォルトの名無しさん
24/02/29 14:51:42.06 bXdMb/7T.net
技術的選択は突き詰めれば必ずトレードオフが生じるもの
利点だけを見て欠点に目をつぶったまま良し悪しを論じるのは愚の骨頂
198:デフォルトの名無しさん
24/02/29 14:52:32.46 sM99e4qp.net
Rustの方式の利点は>>180に挙げられているから
もし仮にRustより良い言語が存在するならその言語の方式の利点を挙げればいいんじゃね？
199:デフォルトの名無しさん
24/02/29 15:05:04.64 Sa1lr1bM.net
>>191
>それは「批判するなら代案出せ」と同じ議論を潰すだけの態度なのでやめよう
議論を潰すというよりも批判から逃げたいだけだろう
200:デフォルトの名無しさん
24/02/29 17:17:49.66 WGw1+Mi1.net
物的な代案や物的証拠により人の心を折ることが検証だと思っているんじゃないか
201:デフォルトの名無しさん
24/02/29 17:44:22.90 JSOAwYd/.net
や、そもそも「人の心」の認識が無いのだろう
202:デフォルトの名無しさん
24/02/29 18:01:07.55 OWFCi11w.net
わざわざRustスレにまでやって来てRust叩きやってる人だから心の病気なのかもな
203:デフォルトの名無しさん
24/02/29 18:25:15.72 uwbVoB9N.net
>>167
>&&T→&Tの場合
これ調べてみたんだけどビルトインderefが優先的に動いて
Deref for &Tの実装は使われてなかった
204:デフォルトの名無しさん
24/02/29 18:37:38.45 OsB1rmqt.net
ビルトインは*を明示指定しないといけなくない？
coercionは何も指定しなくてもDeref実装があれば自動的に多段に適用してくれるけど
205:デフォルトの名無しさん
24/02/29 20:49:33.50 NE3ms/ho.net
impl Deref for &T
はtrait境界を満たすためだけに定義されてるんだろうな
標準だとDeref境界はPinくらいしか使ってないけど
206:デフォルトの名無しさん
24/02/29 23:55:24.58 uwbVoB9N.net
>>199
*演算子のときもDeref CoercionのときもビルトインderefがDeref::derefよりも優先して使われるよ
207:デフォルトの名無しさん
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();
208:デフォルトの名無しさん
24/03/01 09:18:59.78 LWQ/+31h.net
uv、めちゃ速いな
今までの処理時間はなんだったのか
これはRustの印象を良くするツールになるわ
209:デフォルトの名無しさん
24/03/01 10:14:36.96 gvn/awFT.net
uvというとCで書かれた非同期マルチプラットフォームライブラリ(Rustにはmioがある！)が有名だが
そのuvはRust製のPythonパッケージマネージャーなのか
210:デフォルトの名無しさん
24/03/01 11:06:37.60 C9bgbnyF.net
速さの定義はわかりやすさの定義よりもわかりやすい
211:デフォルトの名無しさん
24/03/01 16:15:12.75 lzR4RBgp.net
JavaScriptでも遅いBabelを速いSWC(Rust製)に換えると爆速
212:デフォルトの名無しさん
24/03/01 19:02:46.24 I+/u+ffT.net
Pythonの管理ツールまたなんか出たの！？という気分
213:デフォルトの名無しさん
24/03/02 00:14:54.94 F+x2UUkM.net
uvはPython版のcargoを目指しているらしい
214:デフォルトの名無しさん
24/03/02 16:13:07.16 bMlzFBHT.net
nvidiaのど汚なさを理解してなさげで不安しかないわ
215:デフォルトの名無しさん
24/03/05 04:09:58.03 n3bQlkHC.net
RustでDB使う時の定番ライブラリって何ですか？
216:デフォルトの名無しさん
24/03/05 04:14:48.62 nMHII26b.net
ORMが好きならdiesel
ORMが嫌いならsqlx
217:デフォルトの名無しさん
24/03/05 06:15:07.43 Uplx2IYd.net
>>211
それRDBじゃん
218:デフォルトの名無しさん
24/03/05 11:41:51.93 6drsihdZ.net
RDBじゃないDBの定番とか聞かんだろJK
219:デフォルトの名無しさん
24/03/05 12:54:04.64 iKkb/Eo4.net
RDBMSが定番だからね。
220:デフォルトの名無しさん
24/03/05 23:56:12.66 blmx074I.net
最近RDB以外のDBの存在を知った人にありがちな反応だよな
221:デフォルトの名無しさん
24/03/07 15:14:21.16 /no0RfP4.net
Rustで一通り文法や機能紹介した入門書の次に読むような定石本ってどのようなのがありますか？C++でいうEffective C++みたいな
222:デフォルトの名無しさん
24/03/07 15:28:53.82 5c4tHUTp.net
しゃぶれよ
223:デフォルトの名無しさん
24/03/07 17:13:51.21 NLgNYFMG.net
>>216
Rust for Rustaceans
224:デフォルトの名無しさん
24/03/10 13:14:05.30 XsimGsv7.net
Rustはデフォルトのhashが遅いという罠
225:デフォルトの名無しさん
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();
226:デフォルトの名無しさん
24/03/10 20:38:28.49 8NU5B5F+.net
こうね
HashMap::<Key, Value, Hasher>
227:デフォルトの名無しさん
24/03/10 21:21:36.22 yMMzzxd+.net
解決案としてはそうなのだが、デフォルト挙動が罠すぎる
デフォルトいらなかったのでは
228:デフォルトの名無しさん
24/03/10 21:26:04.39 hwVh1yHa.net
Rustは利用者はアホだと思ってる
だから徹底的に厳しくしてくる
229:デフォルトの名無しさん
24/03/10 21:33:53.98 hwVh1yHa.net
雨が降ってなくても傘を持つように言って来て外出すらさせてくれない
230:デフォルトの名無しさん
24/03/11 00:11:06.91 H3LWtGm6.net
デフォルトのハッシュ関数が遅くて困るってことはよく知らずに使ってたってことでしょ？
そう考えると初心者向けにデフォルト厳しくしておくのは正解な気がするわ、セキュリティに関わるし
まあ言語側はそんな事考えずにとにかく一番スタンダードなものデフォルトにしろって考え方もわかるが
231:デフォルトの名無しさん
24/03/11 00:47:18.65 2r+51Qz1.net
Rustはimpl std::hash::Hasherで必要なら自由に独自のハッシュ計算器をすぐ作れるし
逆にそれと独立にimpl std::hash::Hashで自分の各型に対してハッシュ計算法を指示できるし
この2種類のトレイトを標準で用意してくれているRustは非常に好環境
232:デフォルトの名無しさん
24/03/11 00:59:26.53 lga6QF6v.net
「最悪の場合でもほどほど」なやつをデフォルトにするのは妥当だと俺も思う。
状況に合わせて選択できたり自分で作れたりする人はそうするんだから、
デフォルトではそうでない人を想定するだろ。
233:デフォルトの名無しさん
24/03/11 02:43:53.87 aDyedTxf.net
いやそもそもデフォルトいらんくね？
なんでデフォルト欲しいんだ？
234:デフォルトの名無しさん
24/03/11 11:06:00.19 WfvY/WS3.net
掃除機はAI搭載して吸ってはいけないものを吸ったら止まってくれよ
235:デフォルトの名無しさん
24/03/11 11:06:34.84 WfvY/WS3.net
誤爆した！
236:デフォルトの名無しさん
24/03/11 14:30:36.32 emAmKvKR.net
デフォルトを用意するかしないかは言語思想によるから正解不正解では語れないよな
rustの場合は何事も「安全」に基づいて設計されてると認識してる
237:デフォルトの名無しさん
24/03/11 15:25:18.07 WOvDUzj/.net
適切なハッシュ関数を選択するのってそんな簡単なことじゃないからな
ハッシュ関数の特性だけじゃなくhashbrownの特性も知らないといけないしその両方を組み合わせた際のハッシュDoS耐性の程度も評価できないといけない
HashMapのように基本的なデータ構造を使うのにどんな場合でもいちいちユーザーがその選択しなきゃいけないようだと辛すぎるわな
238:デフォルトの名無しさん
24/03/11 19:01:47.22 srElBTmD.net
HashMapで使われるHashに重いものを使う必要がある局面は限られてる
でも他人のライブラリの外から必要な時にハッシュアルゴリズムを変えることなんかできないので悩ましい人もいるだろう
239:デフォルトの名無しさん
24/03/11 20:05:38.98 3y0FGSJo.net
僕が美少女とセックスするためのプログラムはRustで作れますか
240:デフォルトの名無しさん
24/03/11 21:13:52.07 2r+51Qz1.net
>>233
ライブラリを作成する時にその用途に応じた適切なハッシュを用いればよい
用途により異なるならば安全側に倒すか指定する方法を提供すればよい
241:デフォルトの名無しさん
24/03/11 21:28:56.93 vmVry2mm.net
とりあえずデフォルトを使って、必要になったら差し替えればいいんじゃないの？
Rustだとなんか問題あるんだっけ？
242:デフォルトの名無しさん
24/03/11 21:31:16.84 aDyedTxf.net
>>236
ライブラリのハッシュを差し替えられない
デフォルトハッシュを使うような人間がどんどん参戦してきてcratesの名前空間を埋め尽くしていく
243:デフォルトの名無しさん
24/03/11 21:41:07.80 6xtSsnXH.net
ハッシュ衝突強度安全性が必要かどうかの判断ができない者がRustデフォルトの安全なものを用いることになるのは正しい
そこまで必要としない用途であると判断できた者だけがFxHashなどを用いればいい
RustコンパイラもFxHashを用いている
URLﾘﾝｸ(github.com)
244:デフォルトの名無しさん
24/03/11 21:44:11.78 uBu+z/S9.net
安全で高速を名乗ってるくせにライブラリがおっせえ言語だなあ
これ治すにはいちいち依存ライブラリ全てをcloneしてきてチマチマ変更していかないといけないってマジかよ
245:デフォルトの名無しさん
24/03/11 22:02:54.43 2hCRIQro.net
言語とは関係ない
外部からのデータを扱うなど攻撃耐性など必要となる部分には攻撃耐性のあるハッシュが必須
そうでない部分には攻撃耐性は必要ない
各プログラムの中にこれら両者はは共存しうる
この使い分けができているかどうかは各言語の問題ではない
246:デフォルトの名無しさん
24/03/11 22:17:15.26 1Ss4PFRT.net
ライブラリやその管理が言語と関係がないとする主張は可能だが、その主張をするとcargoやcratesの存在が言語と関係ないことになり、Rustの良さを支えている理由の大きな割合を失うことになる
やはりエコシステムやそこにある資産も含めての言語の評価だろう
それにユーザーの問題を言語が引き取らないのであればコードを書く人が充分賢いことを仮定することになり、C++で良いということになる
247:デフォルトの名無しさん
24/03/11 22:22:30.50 2hCRIQro.net
>>241
C++だけでなくスクリプト言語であろうがすべて同じ
攻撃耐性が必要となるところで強度の高いものが使われてなければ欠陥プログラム
248:デフォルトの名無しさん
24/03/11 22:24:26.89 1Ss4PFRT.net
>>242
だからデフォルトなんかいらないんだよ
ハッシュごとき使うのにデフォルトがないと使えないような人間がcratesの名前空間を埋めていくのはヤバいよ
249:デフォルトの名無しさん
24/03/11 22:32:51.13 Zfy+Gd54.net
>>243
ほとんどの言語の連想配列(hashmap)のハッシュ関数はデフォルトがありますよ
指定しないと使えない言語がもしあるとしてもレアじゃないですか？
250:デフォルトの名無しさん
24/03/11 22:38:01.21 1Ss4PFRT.net
>>244
それはJavaScriptやPythonのような馬鹿がライブラリを書いて馬鹿が馬鹿の再生産をすることを推奨している言語の話でしょう？
もしくは仕様だけ緩く決めて実装には何の責任も取らない言語か
251:デフォルトの名無しさん
24/03/11 22:39:37.27 1Ss4PFRT.net
スクリプト言語だと速度は求められないという了解があるし
252:デフォルトの名無しさん
24/03/11 22:53:49.00 lga6QF6v.net
Rust や C++ の思想でいう速さはゼロコスト抽象のことだよ。
抽象化にはコストはない (または十分に小さい) が実行すれば実行内容に相応の実行コストが生じるのは当たり前のことだし、実行内容を最小限にすることを目指したって単に不便になるだけだ。
253:デフォルトの名無しさん
24/03/11 23:24:30.57 pnxYU4a7.net
あらゆる言語のあらゆるプログラムについて以下が成り立つ
【必須】信頼できない外部入力データに対しては攻撃に強いハッシュ関数を用いなければならない
【自由】そうでないデータに対してはどのハッシュ関数を用いてもよい
この状況で安全な言語はデフォルトとして攻撃に強いハッシュ関数が適切
そして後者と判断できるプログラマーのためにハッシュ関数を指定できる仕様が適切
Rustはこの適切な仕様となっている
254:デフォルトの名無しさん
24/03/11 23:26:28.61 srElBTmD.net
雨の降らない日に傘をさしてるのがRust
255:デフォルトの名無しさん
24/03/11 23:31:49.34 srElBTmD.net
外に出るときはヘルメットを被って110をすでに入力したスマホを持ちながらおむつをしてコンドームつけてるのがRust
256:デフォルトの名無しさん
24/03/11 23:39:22.87 H3LWtGm6.net
雨が降る日のためにいつでも傘をさしてるだけだろ…
257:デフォルトの名無しさん
24/03/11 23:47:29.47 1gRl0SR3.net
デフォルトとFxHasherで比較してみたけどHashMapへのinsertのみで実行時間1.7倍
現実のプログラムだとそれ以外の部分が大量にあるためそれ次第で誤差だね
これはデフォルトが安全側に倒す形を取っていて正解と思う
258:デフォルトの名無しさん
24/03/11 23:47:55.83 eCeLdHKW.net
>>248
>【自由】そうでないデータに対してはどのハッシュ関数を用いてもよい
いやーそれはどうだろう？
ハッシュDoS耐性は不要でも例えばFxHashを使うべきじゃないユースケースも普通にあるよね？
stdに1つしかHasherが用意されておらずサードパーティ頼みな現状は言語的には結構不親切
259:デフォルトの名無しさん
24/03/11 23:55:39.88 srElBTmD.net
hash自体は基本的にアホでも作れる
それが適切なのかどうかは不明
260:デフォルトの名無しさん
24/03/11 23:59:34.73 o1bdd8gz.net
Rustはデフォルトハッシュ関数が用意されていておかしいと言うけど
すべての言語で用意されてるでしょ？
Rustは様々なハッシュ関数が標準ライブラリにないと言うけど
それが普通でしょ？
さらにRustの標準ライブラリはなるべく小さくする方針ね
261:デフォルトの名無しさん
24/03/12 00:02:16.02 YqCvYydB.net
>>255
ここまで読んでそういう解釈になってるなら理解する力が足りてない
重いハッシュ関数がデフォルトになってるのがどうなのかと言う話
262:デフォルトの名無しさん
24/03/12 00:06:26.32 hhdv8qp2.net
普通に考えて攻撃に強いハッシュ関数がデフォルトとなってるのがベストだよね
攻撃の可能性のない部分のみを後でチューンアップつまり弱いハッシュ関数で置き換えるだけだから
これより良い策があるの？
263:デフォルトの名無しさん
24/03/12 00:07:45.67 YqCvYydB.net
攻撃の可能性のある部分をチューンナップ
264:デフォルトの名無しさん
24/03/12 00:10:05.78 hhdv8qp2.net
>>258
バカなの？
それだとチューンアップする前が攻撃耐性ないじゃん
265:デフォルトの名無しさん
24/03/12 00:10:10.84 YqCvYydB.net
江戸時代士農工商の身分制度があって
雨の日だけ農民も下駄を履いてよかった
266:デフォルトの名無しさん
24/03/12 00:11:17.84 YqCvYydB.net
>>259
攻撃されないのに攻撃態勢をつける馬鹿
267:デフォルトの名無しさん
24/03/12 00:13:45.61 c71xUORt.net
みんなの言語思想発表会をするのはいいけどRustをそれに巻き込むなよ
268:デフォルトの名無しさん
24/03/12 00:15:25.47 YqCvYydB.net
IDコロコロ全肯定君
攻撃されるかもしれないのに攻撃の耐性をつけてない人に
対するフールプルーフのために一律全てのコードを遅くする
そもそもその人が設計ミスってるんだろう
269:デフォルトの名無しさん
24/03/12 00:15:58.38 ltF5NefG.net
SafeSlowHashMapみたいな名前にすれば良いのに
270:デフォルトの名無しさん
24/03/12 00:16:19.18 YqCvYydB.net
>>264
少なくともこれかな
271:デフォルトの名無しさん
24/03/12 00:27:26.16 hEPMmb8p.net
>>264 >>265
Rustを使ったことすらない人が文句を言ってるのか
RustのHashMapはHasherに対しても多相であり型パラメータでHasherを指定する
272:デフォルトの名無しさん
24/03/12 00:32:47.44 YqCvYydB.net
>>266
HashMap::new()すらしたことないのかな？
273:デフォルトの名無しさん
24/03/12 00:33:47.12 P8rBcnCc.net
>>266
誰もそんな話してないやろ
これだから複クンは
274:デフォルトの名無しさん
24/03/12 00:35:30.45 YqCvYydB.net
こいつは結論が先にあってRustのすべてが正しいから後で理屈をつけているだけ
いつもおかしなことを言ってる
275:デフォルトの名無しさん
24/03/12 00:36:58.41 4FnCuSr/.net
ripgrepとかuvとかの既に実用が始まってるRust製アプリでは
デフォルトのハッシュ関数使ってるの？
276:デフォルトの名無しさん
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()のように使う
277:デフォルトの名無しさん
24/03/12 01:04:13.79 YqCvYydB.net
ほらこんな壊れたレスしかできないんだよ
脳が死んでる
278:デフォルトの名無しさん
24/03/12 01:05:51.45 YqCvYydB.net
常に論点ずらし
何の生産性もない
279:デフォルトの名無しさん
24/03/12 01:42:25.91 O5aTP+Ks.net
いつもRustを叩いてRustスレを荒らしてるアンチの言動はいつもワンパターン
今回のHashMapの件で例えると
もしデフォルトのハッシュ関数が安全でなく速いものだと「Rustはデフォルトが安全でない！」と叩く
もしデフォルトのハッシュ関数が安全で遅いものだと「Rustはデフォルトが遅い！」と叩く
どちらになっていても叩くことが目的のキチガイ
280:デフォルトの名無しさん
24/03/12 09:25:30.86 2ftxmqwc.net
「俺が高速なプログラムを作れるのは言語のおかげ」は合ってるが
「俺が低速なプログラムしか作れないのは言語のせい」は間違ってる
281:デフォルトの名無しさん
24/03/12 15:42:43.44 qP6Ph9LT.net
『「俺が低速なプログラムしか作れないのは言語のせい」は間違っている』という立場、ユーザーが充分賢いことを仮定しているのでそれならPythonとC++で良い
282:デフォルトの名無しさん
24/03/12 16:02:50.20 O51IPiXd.net
ほんとどうでもいいな
自転車置き場というより豚小屋の議論
283:デフォルトの名無しさん
24/03/12 16:28:46.76 6k71yQCv.net
プログラムしかしない人はこういうことしか考えることがないんよ
284:デフォルトの名無しさん
24/03/12 17:33:47.15 +dm3OZRm.net
知識があれば高速化が可能な場合があるのは、言語や項目に関わらず一般的な話。
安全方針のRustとしては、ハッシュ衝突強度を知らなくてもデフォルトで安全がベター。
285:デフォルトの名無しさん
24/03/12 18:00:43.49 ZUpYWJV7.net
デフォルトいらんが
ハッシュも自分で選べんガイジがハッシュマップ使うな
286:デフォルトの名無しさん
24/03/12 18:49:06.95 hIsWcrJS.net
>>279
わかってなさそうなので再度書くけど
ハッシュ衝突強度が高いからと言ってハッシュDoS耐性が高いとも限らないしHashMapに適してるとも限らないからね
287:デフォルトの名無しさん
24/03/12 18:51:51.27 wv71s4mp.net
弱いハッシュでも困るようなプログラム書く人は、自分で判断できるんじゃないの？デフォルトはパフォーマンス優先で良いと思うけどな。
288:デフォルトの名無しさん
24/03/12 19:50:55.41 WtXn1sYk.net
攻撃で困るかどうか攻撃されるまで初心者は判断できないと思う。
そして攻撃されてから対処するのでは遅いかもしれない。
パフォーマンスチューニングは遅いことが問題になってからやるので深刻ではなかろう。
289:デフォルトの名無しさん
24/03/12 19:59:05.75 1eKk9IjK.net
>>283
同意
290:デフォルトの名無しさん
24/03/12 20:00:13.63 uVbV4a/I.net
RustのDefaultHasherは安全かつパフォーマンスのいいSipHashを使っているので普通は気にする必要ない
もちろんPythonやJavaScript(v8)やSwiftなど多くの言語がこのSipHashを使っている
そのうえでRustは必要とするHashMap毎にFxHashなどさらに高速なものを簡単に指定できる
291:デフォルトの名無しさん
24/03/12 20:49:08.64 NxLZ8TT6.net
Pythonはハッシュ値計算したらオブジェクトに保存してるでしょ
292:デフォルトの名無しさん
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に切り替わりました。
293:デフォルトの名無しさん
24/03/12 20:56:37.07 Bo/PtDeL.net
>>286
常にそれをされたら困るが
Rustでもハッシュ値をオブジェクトに持つstring_cacheなどが用途に応じて使われている
294:デフォルトの名無しさん
24/03/12 22:08:56.94 qGjx1B49.net
>>274
人にキチガイと言う前に自分の脳を使って考えたら？
どちらになっても叩くことはないだろ
他の言語はデフォルトで速いハッシュを使ってるよ
295:デフォルトの名無しさん
24/03/12 22:13:42.86 qGjx1B49.net
Python Ruby スクリプト系言語
296:デフォルトの名無しさん
24/03/12 22:30:53.75 QLhbtBPI.net
他の言語もRustと同じハッシュ関数を用いていることが判明したのにRust叩きを続ける一匹
297:デフォルトの名無しさん
24/03/13 01:06:52.67 l12NsVZP.net
他の言語の例としてPythonやRubyのような遅いこと前提でとにかく初心者が書いても動けば良いという思想の言語を持ち出してく�
298:驍ﾌはおかしいでしょう
299:デフォルトの名無しさん
24/03/13 01:36:16.81 yq4Sx3eg.net
Swiftも同じSipHash13だよ
300:デフォルトの名無しさん
24/03/13 06:48:44.81 vtWyM3VT.net
>>292
じゃあRustの思想は？
301:デフォルトの名無しさん
24/03/13 07:26:54.50 W15vpPlq.net
>>283
判断できない人まで言語側で救う必要性が分からない。
それなら、unsafeもカジュアルに使えないように仕掛けを用意した方が良いんじゃないかと。
302:デフォルトの名無しさん
24/03/13 08:05:27.17 7ftIQ2tM.net
必要なことしかやりませんって言語は他にあるからそちら使えばいいのでは？
303:デフォルトの名無しさん
24/03/13 11:53:59.71 k71lJTPU.net
安全と速度は両立するかそれともトレードオフか
トレードしかしない人にとって、コストは支払うと決めたら絶対にキャンセルできない印象があるよね
有償かと思ったけどよく考えたらやっぱゼロコストだったという現象は許せない
304:デフォルトの名無しさん
24/03/13 13:08:21.45 zcdQDtji.net
Rustなんかに手を出すのはC++まともに書けない馬鹿なんだから、「充分賢ければ速く書ける」は実質「速く書けない」なんだよな
賢いならRustなんかやらない
305:デフォルトの名無しさん
24/03/13 13:52:10.04 k71lJTPU.net
自由があればデフォルト設定を強制されないのは自明な事実
ただし、賢い人間が自由を所有しているのか、道具自体が自由度を持っているのか
そもそも「所有している」というのはただの感想なのか客観的事実なのか
306:デフォルトの名無しさん
24/03/13 15:08:41.44 EtYMYlMl.net
アホ vs バカの不毛な争いが続くのは隔離スレにﾜｯﾁｮｲつけたやつの責任だからな
307:デフォルトの名無しさん
24/03/13 17:12:52.60 2jYqKDsd.net
本スレにワッチョイつけず隔離スレと称して余計なスレ立ててそっちにワッチョイつけるバカども。
5chでRust使ってるって言ってるやつらはそんなもの
308:デフォルトの名無しさん
24/03/13 17:32:48.34 k71lJTPU.net
不毛の判断が早いなあ
後世の歴史家が判断するという定型文に縛られないから早いんだな
309:デフォルトの名無しさん
24/03/13 17:40:34.76 EfEhvhMh.net
安全と速度を両立させたのが
RustやPythonなどが採用しているSipHash13
310:デフォルトの名無しさん
24/03/13 18:38:09.42 9N462qty.net
>>295
いや、unsafeは判断できる人が使うものだろ。
311:デフォルトの名無しさん
24/03/13 21:22:31.53 cNV/vVTe.net
>>300
分かってるんならﾜｯﾁｮｲ付きRustスレの盛り上げに協力してくれんかえ
312:デフォルトの名無しさん
24/03/13 21:54:19.69 Ay/UTMuM.net
ワッチョイなんか盛り上がる訳ねえ
そんな話題あったらこのスレに投下してつまらない議論を流した方が余程生産的
313:デフォルトの名無しさん
24/03/13 22:31:42.96 /twoPXVD.net
高齢化でコーディングできなくなったおじいさんを叩くのは良くないと言う話
314:デフォルトの名無しさん
24/03/13 22:39:35.15 vtWyM3VT.net
30後半でコーディングしてるやつなんて9割コミュ障で出世できなかったやつだろ
315:デフォルトの名無しさん
24/03/13 22:42:16.17 6IE1D2aF.net
出世出来ましたか？
316:デフォルトの名無しさん
24/03/13 22:52:25.45 /twoPXVD.net
能力が低下してコーディングできないのとしないのでは大違い
317:デフォルトの名無しさん
24/03/14 00:41:25.89 2hurvpo9.net
結局スクリプト言語で書かれた原作が必要か
他のジャンルでも原作なしのオリジナルは難しそうだろう
318:デフォルトの名無しさん
24/03/14 12:30:54.13 HuCxvvOv.net
Rustで書き直してパフォーマンスが上がったので注目浴びる！みたいなプロダクトはなんか白けるよな。
JSとかPythonの基盤ツールをRustで書き換えて激速！みたいなのはもう汎用言語としてのアイデンティティ捨てられててオワットル。
319:デフォルトの名無しさん
24/03/14 12:34:38.63 GaNa4vYx.net
日本みたいに、何とかするには人投入しよう！スキルどうでもいいからとにかく人集めて！なところじゃね～。
320:デフォルトの名無しさん
24/03/14 13:45:31.80 zTrHTca+.net
おそらく植山類が新しいリンカを作ったあたりが開発ツール高速化の機運の始まりだと思う。
歴史的事情でごちゃごちゃしてて遅いのが仕方がないと思われていたものについて
速度を意識して書いてみたら数百倍単位で速くなってわひゃーーというのが強烈なインパクトだった。
(それは C++ で書かれてるんだけどね。)
商売で開発ツールを提供している会社にとっては少なくともそれと同程度のものを出さないと面子が立たない。
リンカを作ってるところはこぞって高速化に努めた。
リンカ以外にもその機運が波及しているのが今。
で、高速化のキモはデータ構造であるというのが明瞭になったんだけど
メモリ管理の部分を処理系 (ランタイムサポート) の側でやるようなものだとそこんところのチューニングが出来ない。
Rust である必然性が強いわけではないけど C++ とかよりは今なら Rust のほうがいいかなってのはまあ自然な判断ではある。
321:デフォルトの名無しさん
24/03/15 00:47:31.57 eu7fnAy5.net
コードを書けない
プログラムできなくなるとこういうことしか書けなくなると言う見本
322:デフォルトの名無しさん
24/03/15 10:43:30.71 5CgUbd5q.net
だが読むより書くほうが優れているという前提から
原作を正しく読解するよりも正しくない二次創作のほうが優れているという結論が出てくる
323:デフォルトの名無しさん
24/03/15 11:53:24.75 94MXVgRN.net
春だなぁw
324:デフォルトの名無しさん
24/03/15 18:26:51.96 5N0PtL1J.net
ai bot
325:デフォルトの名無しさん
24/03/15 20:40:42.93 W8LQpOAr.net
>>315
辛辣で草
そういう似非技術者系おじいちゃんおちょくると
怒って自分が唯一知ってる知識振り回してくるから面白いぞ
326:デフォルトの名無しさん
24/03/15 21:07:06.30 8+Y0uCh5.net
Rustコードを書けない似非技術者系おじいちゃんたちは他のスレでやりとりしなさい
ここはRust専用スレ
327:デフォルトの名無しさん
24/03/15 21:26:31.60 PnOJWcC7.net
コーディングが出来なくなると人生はつらいと思うけどな…
328:デフォルトの名無しさん
24/03/15 21:36:49.30 3GkeGGWK.net
できなくなるんじゃなくて
元々できてないんよね>>314みたいな人は
というより単に職業マじゃないのかもな
趣味でプログラム触ったことあるパソコン少年的な
329:デフォルトの名無しさん
24/03/16 00:23:32.44 /iia2JvS.net
人はいつか何もできなくなって死んでいくんだよな
つまらないね
330:デフォルトの名無しさん
24/03/16 08:54:22.01 aeWu0EgX.net
肉屋がレッドオーシャンになれば豚はブルーだからこれでいい
331:デフォルトの名無しさん
24/03/17 19:33:58.02 1VtyMVPz.net
Rust書けるやつ集めるの大変すぎ
332:デフォルトの名無しさん
24/03/17 22:06:35.75 BMZldfUE.net
Rustで書けば速くてリソースコスト下げられるうえに保守性も良くていいことずくめだからだな
ただしまともなプログラマーしか使い こなせない
333:デフォルトの名無しさん
24/03/18 09:59:50.17 ySp1yGcK.net
むしろ変なやつしか使ってない感じだけど…
334:デフォルトの名無しさん
24/03/18 10:20:48.83 JObkxwF0.net
しょーもないこだわり持ってるやつしか使ってない
335:デフォルトの名無しさん
24/03/18 13:49:12.09 lCCxn1Q7.net
今後の仕事考えたらRustだね
336:デフォルトの名無しさん
24/03/18 14:26:36.03 1+ObkRXf.net
メモリ安全性ってなんなの？
337:デフォルトの名無しさん
24/03/18 14:49:59.91 RRSB5dTk.net
無効なアドレスを参照しない
運が良ければSegmentation Fault、運が悪ければ変な値が使われて何か起こる
無効なアドレスを更新しない
運が良ければSegmentation Fault、運が悪ければそこの値が壊れて何か起こる
メモリリークは割とどうでもいい
338:デフォルトの名無しさん
24/03/18 15:00:45.39 ZJ4hMg34.net
>>330
メモリ安全性のうち特に重要な一つがメモリ競合の安全性
まだ使っている値を意図せずに書き換えてしまい矛盾してしまう
プログラミングで起こるバグの代表的な一つ
Rustではこれを防ぐことができる
339:デフォルトの名無しさん
24/03/18 15:02:35.53 1+ObkRXf.net
>>331
ありがとう
「運が悪ければ変な値が使われて何か起こる」
そういえばメモリの概念理解せずにC言語使って、動かすたびに結果がかわるバグプログラム生み出してビビリ倒したことを思い出しました……
340:デフォルトの名無しさん
24/03/18 15:07:28.37 1+ObkRXf.net
>>332
ありがとう
「運が悪ければ変な値が使われて何か起こる」
そういえばC言語の現在時刻取得関数がポインタ返し&参照先書き換えるタイプの関数だったので大ハマリしたことありますね…
341:デフォルトの名無しさん
24/03/18 18:35:36.34 utey1W8X.net
セルフコントならもう少し面白いやつを頼む
342:デフォルトの名無しさん
24/03/20 01:19:02.24 6E76csi8.net
WebAssemblyバイナリの実行環境を提供する「Rust」で作成されたランタイム「Wasmi」に脆弱性が明らかになった。
URLﾘﾝｸ(www.security-next.com)
343:デフォルトの名無しさん
24/03/20 05:37:59.51 wTR4SIFK.net
デフォルトで制限よりも多くのパラメーターを指定すると域外に書き込みを行うおそれがある「CVE-2024-28123」が明らかとなった。
2023年12月にリリースされた「同0.31.1」にて脆弱性は修正された。
パラメーターが128個以下であることを確認する回避策についてもアナウンスしている。
344:デフォルトの名無しさん
24/03/20 12:50:32.15 /slJg93x.net
>>336
そういうのRust関係ないからわざわざここに書かなくてもいいよ
345:デフォルトの名無しさん
24/03/20 13:00:27.22 3fTCja3E.net
関係無いわけないでしょｗ
rustで書かれてたら安全なんじゃなかったん？ｗ
346:デフォルトの名無しさん
24/03/20 13:48:07.28 i9d3tzeg.net
ガベージコレクションのあるスクリプト言語であるPythonですら脆弱性でCVE出まくってるよ
347:デフォルトの名無しさん
24/03/20 14:22:40.25 HLjoI2yW.net
これは「メモリ安全」の外の話？中の話？
348:デフォルトの名無しさん
24/03/20 16:11:18.74 sC/F3tDJ.net
unsafe使用箇所だからメモリ安全の外だろうな
インタプリタのスタックフレーム参照で毎回境界チェックする実装も微妙だししゃーない
349:デフォルトの名無しさん
24/03/20 16:33:56.60 pz7pPV/0.net
jsonの方も？
350:デフォルトの名無しさん
24/03/20 17:50:49.65 w9jt/Hdz.net
コード見てみたが言語関係なくダメな書き方の見本ってだけだな
URLﾘﾝｸ(github.com)
URLﾘﾝｸ(github.com)
修正コードは毎回境界チェックしてるのと同じ
extendする前に必ずreserve呼ばなければいけないとか反省の色が見られない
351:デフォルトの名無しさん
24/03/20 18:13:46.74 ASk8Mk2n.net
extendという名前も実体と違ってバクの素
352:デフォルトの名無しさん
24/03/20 18:19:15.64 sC/F3tDJ.net
修正コードはhotfixでしょ
masterブランチの方は結構手が入ってると思う
353:デフォルトの名無しさん
24/03/20 18:27:22.61 ihbrcjwp.net
その知識やスキルを活かして出世して欲しい
354:デフォルトの名無しさん
24/03/20 20:04:41.25 TrbgWl+Z.net
ダメな書き方でもコンパイルが通れば安全なはずなのではｗ
355:デフォルトの名無しさん
24/03/20 20:32:22.01 sC/F3tDJ.net
んなこたない
ダメなunsafeの使い方すれば安全じゃなくてもコンパイルは通せる
356:デフォルトの名無しさん
24/03/21 01:05:26.83 CBfowBe/.net
直接の原因はunsafeなメソッドをsafeメソッドにしたこと
unsafeのsafe wrapperの質は大事
今のコードもunsafeの使い方が怪しくて信頼できない
fn get_release_unchecked_mut(&mut self, index: usize) -> &mut UntypedValue {
debug_assert!(index < self.capacity());
// Safety: This is safe since all wasmi bytecode has been validated
// during translation and therefore cannot result in out of
// bounds accesses.
unsafe { self.entries.get_unchecked_mut(index) }
}