Rust part23 - 暇つぶし2ch

Rust part23 ..

2:デフォルトの名無しさん
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 7HXLfctb.net
Rust Reference Book
URLﾘﾝｸ(doc.rust-lang.org)
Rust Standard Library
URLﾘﾝｸ(doc.rust-lang.org)
Rust rustc Book
URLﾘﾝｸ(doc.rust-lang.org)
Rust rustdoc Book
URLﾘﾝｸ(doc.rust-lang.org)
Rust rustup Book
URLﾘﾝｸ(rust-lang.github.io)
Rust Cargo Book
URLﾘﾝｸ(doc.rust-lang.org)
Rust unstable Book
URLﾘﾝｸ(doc.rust-lang.org)
Rust macro Book
URLﾘﾝｸ(danielkeep.github.io)
Rust CLI (Command Line Interface) apps Book
URLﾘﾝｸ(rust-cli.github.io)
Rust Future Book
URLﾘﾝｸ(cfsamson.github.io)
Rust async-std Book
URLﾘﾝｸ(book.async.rs)
Rust tokio Book
URLﾘﾝｸ(tokio.rs)
Rust serde Book
URLﾘﾝｸ(serde.rs)

4:デフォルトの名無しさん
24/02/24 14:37:44.58 TvelBLvi.net
前スレ終盤がRust特有の型🔵ナニー症候群の典型(この用語は出典参照)
ｽﾚﾘﾝｸ(tech板:977番)-
Netflixは2年かけて気が付いたけど凡人程のめり込む沼
出典
URLﾘﾝｸ(www.youtube.com)
Haskellの時と同様、概念だけ触れたら他の言語に活かすのが良い
長居していると症候群認定される危険性があるから

5:デフォルトの名無しさん
24/02/24 14:48:37.96 cR8FpHrN.net
>>4
それ何の情報もなく見ても無駄
具体的な説得力ある話がない
TypeScriptが嫌いでGoが好きらしい

6:デフォルトの名無しさん
24/02/24 16:14:50.39 yK1YDROT.net
Rustから前スレ終盤の型オナニーをなくしたような言語があれば使いたいけど、ないから仕方なくRustを使っている

7:デフォルトの名無しさん
24/02/24 16:23:38.76 GLkrdyDg.net
静的型チェックレベルを高めつつジェネリクス等による汎化を活用しようとすれば大なり小なり型オナニーは避けられない
RustやTypeScriptだけでなくC++のtemplateやPythonの型ヒントでも同じこと

単独のTraitだけの話で型オナニーとか言ってるやつはオナニーレベルが低過ぎ
静的型チェックへの適性がないのでRustも辞めた方がいい

8:デフォルトの名無しさん
24/02/24 16:34:30.38 vVxC7GCC.net
型オナニーより所有権やライフタイム管理の方が面倒だけどな
それが型と絡むからさらにややこしくなる

9:デフォルトの名無しさん
24/02/24 17:03:48.32 4NvD6VS8.net
動的型付け言語しか慣れてない初心者が静的型付け言語に慣れるまで時間がかかるのは当たり前
GC前提言語しか慣れてない初心者がそうでない言語に慣れるまで時間がかかるのは当たり前
プログラミングに向いてる人ならどちらもすぐに慣れる
そんなことで文句を言っているようではプログラミングに向いていない

10:デフォルトの名無しさん
24/02/24 17:13:41.82 V+W4sktV.net
Rustの型オナニーは「本当は1つにまとめても良いんだけど歴史的経緯で2種類あります」みたいなのが稀にあって気持ち良くない

11:デフォルトの名無しさん
24/02/24 17:33:53.05 rpcvr5yl.net
>>10
妄想楽しいですか？

12:デフォルトの名無しさん
24/02/24 18:25:50.38 +fQ0JdTj.net
>>8 それRust特有だよね時間がどんどん溶ける

13:デフォルトの名無しさん
24/02/24 18:33:24.91 Sbx59RJL.net
asはそろそろFrom/TryFromに統一してほしいんだけど

14:デフォルトの名無しさん
24/02/24 20:45:24.03 Mj/QkYpd.net
型オナニーって全部習得するまでにいったいどれだけ時間かかるんだ

15:デフォルトの名無しさん
24/02/24 20:47:39.26 fAQkBdOO.net
型オナニー四十八手

16:デフォルトの名無しさん
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となる

17:デフォルトの名無しさん
24/02/24 22:13:12.85 SuzjS9X3.net
打ち間違い
252でなく253ね

18:デフォルトの名無しさん
24/02/24 22:51:22.10 Sbx59RJL.net
>>16
それだけならstdにimpl From<i32> for Wrapping<u8>でも入ってくれれば事足りると思うが……

asって手軽なだけで変換元と変換先の型ごとに意味が複数あるのが複雑で嫌いなんじゃ
C++のC形式キャストみたいな印象

19:デフォルトの名無しさん
24/02/24 22:53:55.08 Sbx59RJL.net
え、てかそもそも演算オーバーフローはpanicするのにキャストはpanicしないのか
だるっ
そういうとこやぞ

20:デフォルトの名無しさん
24/02/24 23:26:44.50 1jp0hNdJ.net
生演算子はオーバーフローせずラッピングされる
panicはデバッグ時のみ
明示的にラッピングしたいときはwrapping_add
オーバーフローを処理したいときはchecked_addやoverflowing_addまたはsaturating_add

21:デフォルトの名無しさん
24/02/25 01:04:03.14 /M3V/hwr.net
型オナニーって複雑な型パズルを解いて悦に入ることを言ってるのかと思いきや
標準ライブラリの基本的な使い方を覚えることなのかよ
オナニー要素ゼロじゃん
そんなマインドではRustに限らず言語習得は無理だぞ

22:デフォルトの名無しさん
24/02/25 01:05:34.01 PHCSkV3G.net
そんなマインドでもGo言語なら習得出来るんだよなあ

23:デフォルトの名無しさん
24/02/25 01:14:51.15 Y4TucXFt.net
バカはGoへ行くしかないよ
Rustなどは一般的なプログラミング能力がある人向け

24:デフォルトの名無しさん
24/02/25 01:52:59.15 5QMstwYR.net
>>22
それはたまたま動いてるようなもんだぞ。

25:デフォルトの名無しさん
24/02/25 09:14:13.54 F2CUOiYD.net
Rustの開発って時間掛かりそうなイメージある
とりあえず作ってみて後でリファクタリングって作り方ができない感じ？

26:デフォルトの名無しさん
24/02/25 09:49:58.55 JC//7tos.net
termuxよりscreen派なんだよなぁ。ライセンスはgplよりbsdのが好きなんだけど。

27:デフォルトの名無しさん
24/02/25 10:13:55.36 CWUdGBuB.net
>>21
リアルの会話でこうやってRustのマイナス面を他と同じと言う奴は
内心信用してない
>>23
言い方があれだけどこっちの方が信用できる

28:デフォルトの名無しさん
24/02/25 10:16:51.38 m/LZ7YZH.net
>>25
リファクタリングってのは外部から見た時の挙動を変えないのが原則なので
少なくとも型やライフタイムについては辻褄が合っていることを保証できる仕組みは
リファクタリングでも便利なんだぞ。

内部的な処理でもあまり柔軟には変えづらいということはあるけど
変えづらいところは (外部に対する保証に関わってくるので) 変えてはならない箇所だってことがわかる。

29:デフォルトの名無しさん
24/02/25 10:21:38.07 UdSUU0Ni.net
>>9
✕プログラミングに向いていない
○rustに向いていない
皆さん、これがrust信者です

30:デフォルトの名無しさん
24/02/25 11:59:50.84 sgD3xFEl.net
>>6
せめてtraitに外延性があって集合的操作ができればいいんだけど、さすがにビルドに時間掛かりそうだしな。

ただでさえビルド時間が重たいから、設計の「早すぎる最適化」は仕方ないのかね。

31:デフォルトの名無しさん
24/02/25 12:12:53.79 swktBlsa.net
>>26
screenってまだメンテされてんの？

32:デフォルトの名無しさん
24/02/25 12:43:55.95 JQupN8F5.net
>>28
例えばpythonとかだと型とかプログラム構造気にせずにパパッと書いて
ある程度動くスクラッチでレビューして内容詰めて
スクラッチから流用できそうなら作り込んでリファクタリングみたいにできるけど
Rustだとそういう風にできなさそう

33:デフォルトの名無しさん
24/02/25 12:48:37.70 AFiN8NTf.net
>>23
こういうのに限ってgoでもろくなもの書けない

34:デフォルトの名無しさん
24/02/25 12:50:53.73 lnNUwEQk.net
>>32
Pythonだとそのリファクタリング前後で挙動が変わってしまわないように気を遣うのがしんどいな
そういうとりあえず試しに作るケースだとユニットテストなんかも当然ない状況なんで
Rustに限らず静的型ならその辺をだいたいコンパイルエラーで拾えるのが楽

35:デフォルトの名無しさん
24/02/25 13:03:20.25 WCq5qF7l.net
>>27
「僕は基本Traitがよくわからない => それはRustのマイナス面」
この発想が幼稚さがわからないのかな？
他の言語と比べたときのRustのマイナス面はたくさんあるがそういう話のレベルじゃないだろ

36:デフォルトの名無しさん
24/02/25 13:05:42.89 Y4TucXFt.net
>>32
動的型付け言語しか使ったことがない初心者が
静的型付け言語の圧倒的なメリットを理解できないのはよくあるあるある
脱初心者の壁を乗り越えよう

37:デフォルトの名無しさん
24/02/25 13:18:05.49 Y4TucXFt.net
どんな言語にもマイナス面がありRustにもある
しかしマイナス面を上回る莫大なメリットがRustにはいくつもあるからIT業界をあげてRustを支援＆採用している
揚げ足取りでRustを叩きたいだけの人はアンチスレへ行け

38:デフォルトの名無しさん
24/02/25 13:23:45.23 /3HpHAOM.net
>>36
知らないのかもしれないけど今のPythonはどちらもできる

39:デフォルトの名無しさん
24/02/25 13:29:34.11 cAT3nYdz.net
>>35
どんな理由であれ複雑なのはマイナスだろ
複雑なのがプラスだってんならC++かbrainfuckやれよ

40:デフォルトの名無しさん
24/02/25 13:33:19.74 m/LZ7YZH.net
漸進的型付けは静的片付けと動的型付けのどちらも出来るわけではなくて漸進的型付けという別物だと解釈すべきだと思うよ。

41:デフォルトの名無しさん
24/02/25 13:35:59.16 m/LZ7YZH.net
>>39
能力が同じなら複雑さはマイナスだが複雑にしてでもそれを上回るメリットが得られることがあるという話だということも理解できないの？
トレードオフ

42:デフォルトの名無しさん
24/02/25 13:47:25.26 cAT3nYdz.net
>>41
>>35はそんなこと書いてないぞ
> 「僕は基本Traitがよくわからない => それはRustのマイナス面」
> この発想が幼稚さがわからないのかな？
だぞ。勝手に自分の文脈を他の人のレスに上乗せして書いてない解釈を押し付けるなよガイジ

43:デフォルトの名無しさん
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)

44:デフォルトの名無しさん
24/02/25 13:53:04.35 Y4TucXFt.net
ここはRustユーザが集うRustスレ
叩きたいだけのキチガイはアンチスレへ行け

45:デフォルトの名無しさん
24/02/25 13:56:41.04 Y4TucXFt.net
>>43
なるほど
URLﾘﾝｸ(news.mynavi.jp)

46:デフォルトの名無しさん
24/02/25 14:00:42.93 qsle6rXj.net
C++の後継目指すプログラミング言語「Carbon Language」、Googleの技術者が実験的公開。C++は技術的負債で改良が困難と
URLﾘﾝｸ(www.publickey1.jp)

47:デフォルトの名無しさん
24/02/25 14:05:55.86 gx/ep+tD.net
>>37
嘘はいかんよ
Rustにはメリットなし、がIT業界の総意
Adaの方が上

最新版IEEE調査Jobs
URLﾘﾝｸ(i.imgur.com)

48:デフォルトの名無しさん
24/02/25 14:10:17.03 cAT3nYdz.net
Jobで判断するのはちょっとなあ
Jobの要件にするのってその言語さえ出来れば良い人を探す時じゃん
Rustってまだそのフェーズではないんだよな

49:デフォルトの名無しさん
24/02/25 14:19:17.62 2NfnhAyO.net
>>48
言うてメインはOSS用だよね
大手はちょっとばかり資金援助してレバレッジ効かせようと宣伝して
2021-2022がRustハイプのピークだったんだけど真水のJobは稀

50:デフォルトの名無しさん
24/02/25 14:25:08.84 zbRFIfV6.net
>>46
Carbonはその公式FAQに明記してるように
Rustを使える状況ならRustを使ったほうがいいという立ち位置
Carbonは既存のC++遺産メンテ用

51:デフォルトの名無しさん
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」を開発し利用していることを明らかにしました。

52:デフォルトの名無しさん
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)

53:デフォルトの名無しさん
24/02/25 14:45:16.11 8UflVtOh.net
>>52
情報古いな
AmazonはLLRTでしょ
cloudflareのRustは放置だ

54:デフォルトの名無しさん
24/02/25 14:48:00.26 3ePlkypT.net
誰も問題視していないどうでもいいことでしかRustを叩けない状況
アンチが追い込まれている

55:デフォルトの名無しさん
24/02/25 14:53:16.67 8UflVtOh.net
>>53は >>51向けな
 >>52のは違うIssue/PRのcommitで場当たり的fixしただけで知れっと本質を隠蔽した
 >>54
問題視したから取り繕いfixしたんだよ

56:デフォルトの名無しさん
24/02/25 14:56:15.69 8UflVtOh.net
>>37,47
上位は納得だから結局のところ「IT業界をあげて」なんて言いたかったら
Jobで判断するのが客観的で中立フェアな基準なんだな

57:デフォルトの名無しさん
24/02/25 14:59:17.67 GfahaNNz.net
>>53
LLRTはAWS LambdaでJavaScriptを使いたい人向けのJSランタイムの一つ
Rustが使えるならRustを使ったほうが有利
さらにAWS自体も >>51にソースがあるようにRustで書かれている

58:デフォルトの名無しさん
24/02/25 15:03:11.52 h80FlwFJ.net
>>57後半
部分的にな
あとそのソースとやらのLiam Tungはいなくなったね
飛ばし過ぎた？

59:デフォルトの名無しさん
24/02/25 15:09:15.42 h80FlwFJ.net
>>57
>Rustが使えるなら
時々見るこの枕詞は実際の現場では使えない事の証拠なんだよなぁ

60:デフォルトの名無しさん
24/02/25 15:10:35.35 h80FlwFJ.net
>>57
>JavaScriptを使いたい人
これが圧倒的だからAmazonが独自魔改造したから凄い

61:デフォルトの名無しさん
24/02/25 15:27:26.81 GfahaNNz.net
>>59
そのAWS Lambdaでも当然Rustを使えます
Rustを使えないのは環境ではなく低層プログラマー

62:デフォルトの名無しさん
24/02/25 15:30:50.61 na8ub8Oh.net
>>55
この恣意的な例以外で同様の脆弱性が生まれる例があれば教えて欲しい
煽りとかではなく

63:デフォルトの名無しさん
24/02/25 15:48:37.00 3ZfnE9eN.net
>>62
俺も煽りじゃなく警鐘で言うけど
 >>55の根本原因究明がならなかったから、今後も散発的に発見しては穴ふさぎをするのでは
(CVE報告しないで悪用されたら最悪だけど)
Rustのメモリ安全性目標チェックは他の言語と比べて
相対的にメリットがあったりデメリットがあったりするだけのことだから

64:デフォルトの名無しさん
24/02/25 16:02:53.19 4fScDWQR.net
>>62
恣意的ってそういう意味じゃないですよ

65:デフォルトの名無しさん
24/02/25 16:07:08.08 na8ub8Oh.net
例出せないならお前が偉そうに言うことではないぞ
どの立場からもの言ってるんだ？

66:デフォルトの名無しさん
24/02/25 16:10:58.09 37W0dlDW.net
>>65
化けの皮が剥がれるの早すぎて草

67:デフォルトの名無しさん
24/02/25 16:11:46.86 na8ub8Oh.net
俺の質問に答えずに訳のわからないことを言うしかできないんですね
くだらないクズが

68:デフォルトの名無しさん
24/02/25 16:14:14.27 wVCQJTWx.net
>>52
実際の開発では出てこない極端に作り上げた例のみだから
Rustを採用しているIT大手を含めて問題視していない

69:デフォルトの名無しさん
24/02/25 16:19:05.44 5Lw05PSN.net
>>66
ちなみに急に煽り始める>>65,67はあのコテハン

>>68
>実際の開発では出てこない極端に作り上げた例
自分で踏んだ事ないから想像だけど、失敗を犯すのはその考え方の人間

70:デフォルトの名無しさん
24/02/25 16:21:52.97 na8ub8Oh.net
いや煽ってきたのはお前だろw
何を勘違いしてるんだ

71:デフォルトの名無しさん
24/02/25 16:23:31.57 na8ub8Oh.net
自分が攻撃するのは良くて攻撃されるのは嫌か？
そういうやつには徹底的にやるから覚悟しろよ
俺に攻撃するってことはそういうことだ

72:デフォルトの名無しさん
24/02/25 16:24:39.64 4fScDWQR.net
誰やねん

73:デフォルトの名無しさん
24/02/25 16:27:11.46 LjVpirDf.net
自分以外が全部同一人物だと思い込んでるアタオカの着火点は意味不明だよな

74:デフォルトの名無しさん
24/02/25 16:31:47.21 wVCQJTWx.net
>>69
実際にコードを見てごらん
ありえない無意味なコード
識者たちも問題視していない

75:デフォルトの名無しさん
24/02/25 16:36:11.19 sIg5Fob3.net
>>71 誰も攻撃してないのにこの人怖い、やめてくれませんか
心理的安全性を通り越して身の危険を感じる((((；ﾟДﾟ))))ｶﾞｸｶﾞｸﾌﾞﾙﾌﾞﾙ

76:デフォルトの名無しさん
24/02/25 16:37:37.04 4fScDWQR.net
例の#25860、ジェネリクスとかマクロ生成の裏で意図しないでこのパターン踏んだりしない？
絶対ない？

77:デフォルトの名無しさん
24/02/25 16:37:39.99 muM7k3Ml.net
rustでリファクタリングしながらの開発ってなると多分unsafeを途中経過で入れたりとか
そういうテクニックが必要になると思う。
その辺の整備が進めば割と広まるかもね。

78:デフォルトの名無しさん
24/02/25 16:45:35.35 wVCQJTWx.net
>>76
絶対にないから安心していい
その「&'static &'a ()」が出てくることはない

79:デフォルトの名無しさん
24/02/25 16:50:17.61 4fScDWQR.net
>>78
理由は？

80:デフォルトの名無しさん
24/02/25 16:51:49.35 zhB6NxSY.net
>>32
サクッとプロトタイピングする目的ならそりゃRustよりPythonのほうが向いてる
Rustは多少手間がかかったとしても速度・安全性・堅牢性を高い水準で求める場合に使う言語

>>39
AsRefやTryFromが複雑とか言われても困ります

81:デフォルトの名無しさん
24/02/25 16:52:52.76 hjrqLcFN.net
>>77
unsafeは基本的に不要
必要だと思ってもまず標準ライブラリにその機能がないか調べる
次にクレートにその機能がないか調べる
どこにも存在しない場合
unsafeを安全に閉じ込めて安全に使うことができる有用な機能を発見したのならばラッキー
それをクレートとして公開するとよい

82:デフォルトの名無しさん
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

83:デフォルトの名無しさん
24/02/25 17:26:51.68 O13egj5J.net
>>77
同じ構造体の一部を参照しながら別の一部を書き換える大きめのメソッドを
複数のメソッドに分割しようとするとborrow checkerに引っかかる的な話かな
他の言語のクラスと同じ感覚で構造体作るとたまに嵌る
Rustの構造体はRDBのテーブルを正規化する雰囲気で分割した方がいい

84:デフォルトの名無しさん
24/02/25 17:30:07.94 hjrqLcFN.net
>>82
Rustのvariance仕様だから発生させることはできるけど
現実に使うコードでは発生しない
意図的にその仕様の狭間をつく現実的でないコードでのみ発生する
そのためその2015年からそのまま放置で誰も困っていない

85:デフォルトの名無しさん
24/02/25 17:45:11.19 4fScDWQR.net
>>84
by accidentを辞書で引いてこい

86:デフォルトの名無しさん
24/02/25 17:51:15.22 hjrqLcFN.net
>>85
その2015年から9年間
その問題でトラブルが起きたことがない

87:デフォルトの名無しさん
24/02/25 17:55:53.01 bLJeGl/a.net
>>81
>unsafeは基本的に不要
>...ラッキー
嘘で始まって運頼みで締めるとはw

信者の心の支えの大手のあそこは
見境なくunsafeを使わざるを得なくなって
Rustでやった意味が無くなってるってよ

88:デフォルトの名無しさん
24/02/25 17:56:42.46 m/LZ7YZH.net
可能性を論じるならお前の頭に隕石が落ちてくる可能性だってあるが、そんなことを心配したことある？

89:デフォルトの名無しさん
24/02/25 18:03:36.71 c6Ww7brW.net
RustはVec等のCVE前科があるからなぁ
頭に隕石が落ちたんじゃね？

90:デフォルトの名無しさん
24/02/25 18:07:11.51 e56nXER6.net
開発プログラムでunsafeを直接使うことはほとんどない
unsafeが閉じ込められ安全なインターフェースが公開されている形で間接的にのみ用いる
どうしてもunsafeが必要になった場合でもそのように安全な形で分離して用いる

91:デフォルトの名無しさん
24/02/25 18:10:03.77 4fScDWQR.net
隕石であれ何であれそれがエンジニアリング可能な対象なら問題を特定して語る意味はあるだろう

92:デフォルトの名無しさん
24/02/25 18:19:05.40 e56nXER6.net
>>89
Dropで型がpanicする時にその要素をた用いたVec::from_iter()で二重解放のバグが発見された件か
もちろん他の言語と同様に全ての言語においてライブラリにバグが見つかることは当然ある
Rustはその点でも少ない方なので信頼して使える

93:デフォルトの名無しさん
24/02/25 18:30:56.08 F3hFw1lw.net
>>90,92
思い描く理想と現実の落差が激しいな
Rust不信の原因だぞ
とくに >>92の最後の行があるから信用されない

94:デフォルトの名無しさん
24/02/25 18:43:22.50 hlYoDW1g.net
Rustの2023年のCVEはCargoで名前をエスケープし忘れた1件のみ
Rustの2022年のCVEは0件
つまりRustコンパイラについて過去2年間でCVEなし
信頼度が高いと言える

95:デフォルトの名無しさん
24/02/25 18:49:05.16 cAT3nYdz.net
Rust以外のコンパイラってそんな言うほどバグないか？

96:デフォルトの名無しさん
24/02/25 19:34:08.90 O13egj5J.net
普通にあるけどみんなで使うから大部分はリリース前に潰される
コンパイラというよりライブラリのバグみたいだけど他の言語より未定義動作にシビアだから
バグ扱いされる事例が増えるのは仕方ない

97:デフォルトの名無しさん
24/02/25 19:46:15.91 pvICb5ke.net
>>91
お前のとこは無限のリソースがあるのかな？
いいなぁ優先順位考えなくていい環境。うらやましいよ。

98:デフォルトの名無しさん
24/02/25 19:49:21.58 +aJmKKn5.net
今となっては未定義動作の多い言語を使うのは悪行だ
Rustを使うべし

99:デフォルトの名無しさん
24/02/25 20:11:25.55 yYiD0TuW.net
>>82
ここの信者はテキトー過ぎるよな
コンパイラ開発チームはもとより、サーベイ回答者もコンパイラバグ潰しを最優先、が一番多い

100:デフォルトの名無しさん
24/02/25 20:15:02.43 yYiD0TuW.net
>>97
余裕があるからRustもやる、と言うのが普通だな
サーベイでも(余裕がなくなって)Rust採用予定なし、なぜなら他言語採用予定だから、が一番多い
(ただし採用にはインターンも含まれる)

101:デフォルトの名無しさん
24/02/25 20:24:50.38 0y8maAN+.net
>>99
対処の必要があるものはその通り
しかし実害がないと皆が判断して対処優先度低いまま9年間が経過したが実害がな起きていない
そんな状況のものを杞憂したり揚げ足取りでRustを叩いてる連中がゴミ

102:デフォルトの名無しさん
24/02/25 21:16:46.71 4fScDWQR.net
事実を書かれただけで批判だと思っちゃうようじゃ生きづらかろうな

103:デフォルトの名無しさん
24/02/25 21:34:47.98 E/2LoMBL.net
>>101
これが矮小化と言うやつか
7割がバグ潰しを「最優先」と回答している事実
直したくても直せないまま何年も経過、unsafe無しでメモリ安全ではない(事実)、Rustの不健全仕様(事実)
(unsound=不健全は数学用語、要は矛盾があるという事)
幸運にもRustが使われなさ過ぎで実害がないように見える(または報告がないだけ)
(良心的に考えてRustが広く使われてない内に)バグ潰しをしとけ、がユーザーの9割の意見(中優先含めて)
週明けのテック記事はどう書くのかな
良い所だけ抜き出してビューが取れるハイプ期間は弱まったと思う
それと飛ばし過ぎるといなくなるorz

104:デフォルトの名無しさん
24/02/25 21:37:20.20 PFD3HMoN.net
アンチもMozillaが変なことやってるだけで
firefoxに導入できるわけがない一般人が
使えるようになるのは妄想とか
言ってた頃に比べると細かい実装の穴を
ネチネチやるまでになって大変だなあ

105:デフォルトの名無しさん
24/02/25 22:03:27.18 cpTMj4Oj.net
>>103
根本的なことを理解できてないようなので一点だけ
unsafeがプログラム全体に散らばっている他の言語に対して
Rustはunsafeを局所的に閉じ込めて安全なインタフェイスを公開しそれを使ってプログラミングする言語
よく使われる基本機能は標準ライブラリとしてunsafeを閉じ込めてあるが
必要なら自作を含めてunsafeを閉じ込めたライブラリを使ってよい
他の言語と比べてunsafeを局所的に閉じ込めた部分のみ注視すればよいことがRustのメリット

106:デフォルトの名無しさん
24/02/25 22:16:32.90 uv4EdbLT.net
>>105
unsafeに閉じ込められなかった事実を提示されてるんだが何言ってるんだ？

107:デフォルトの名無しさん
24/02/25 22:32:50.41 cAT3nYdz.net
Rustコンパイラにバグがあるのはかなりキモくて嫌だけど、Rustの利用をやめるほど致命的かというとな

108:デフォルトの名無しさん
24/02/25 22:47:36.07 m/LZ7YZH.net
C++ の未定義を踏んでもおかまいなしってよりは原則として問題は検出する (けどちょっとはバグもある) Rust のほうがだいぶんマシな言語設計ではある。

109:デフォルトの名無しさん
24/02/25 23:03:18.85 AXW02Nd1.net
unsafeなライブラリがRust用の安全なインターフェースを公開することにより保証される安全性とは
もちろん呼び出される側の安全性ではない
呼び出す側だけが検査される
しかも検査が完璧かどうかは実装依存
じゃあ言語仕様により保証されるのは何か
言語仕様は、あとは検査が通るか通らないかを確かめればよいというところまで仕様を確定しなければならない

110:デフォルトの名無しさん
24/02/25 23:10:45.79 Wz/bOaUk.net
プログラム全体がunsafeなC/C++は使いたくない
未定義な動作も多すぎる

111:デフォルトの名無しさん
24/02/25 23:49:12.62 bSwN5N4x.net
>>109
Rust関係無しに基本的なことを理解できてないようだけど
掛ける情けも無し

112:デフォルトの名無しさん
24/02/26 00:02:36.23 cKYYV9zq.net
反論できないときは関連するワードを含むRustの宣伝文句をぶつける
いつもの流れです

113:デフォルトの名無しさん
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)

114:デフォルトの名無しさん
24/02/26 00:10:06.79 nyM0yI5t.net
>>105,109
詐欺師みたいな偽者だな、Rust不信の種まきするのやめろ
 >>112
分かっていれば支離滅裂文章なんだけど騙されるのは学生位だろうか

115:デフォルトの名無しさん
24/02/26 05:11:35.79 G5weOmRY.net
>>前スレ992
Derefは演算子
・そのためstd::ops::Derefにある　(変換std::convert::AsRefと対照的)
・演算子*によりderefされる
・&**へとcoerceされる

116:デフォルトの名無しさん
24/02/26 13:22:06.51 vLFZOOEE.net
Derefの名前の由来は*演算子（dereference：参照解決）だろうけど
機能は&**へのcoerceを前提にしてて結果的にrefのままだからややこしいな
現状だとInnerRefの方がしっくりくる

117:デフォルトの名無しさん
24/02/26 13:34:26.79 vLFZOOEE.net
意味的にはFollowRefの方が自然かな
まあ*演算子で使われるtraitだからDerefでいいんだけど

118:デフォルトの名無しさん
24/02/26 17:12:18.82 hotfpUjh.net
【AI】Stable Diffusion 3発表、Soraで話題の拡散トランスフォーマーを採用 [すらいむ★]
ｽﾚﾘﾝｸ(scienceplus板)
ボイス・トォ・スカるしている者も攻撃を受けるようになりました

119:デフォルトの名無しさん
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は演算子」という捉え方は良くないよ

120:デフォルトの名無しさん
24/02/26 19:05:39.95 CpQkWMmQ.net
Rustて、演算子と関数を(意味論的に)区別していたっけ？
中間記法によるややこしい結合順の違いがあるぐらいで、構文解析後は等価だから、あんまりこだわっても仕方が無い気が。
中間記法の演算子は人間の算数の記法に配慮しているだけの悪習でしか無いから、積極的に差異をつけないほうが良い気がするけど。

121:デフォルトの名無しさん
24/02/26 19:26:28.00 pFLZLcAJ.net
Deref に関しては * 演算子として機能する以外に型強制の規則があるという話の文脈。

122:デフォルトの名無しさん
24/02/26 19:44:24.36 vLFZOOEE.net
+に対するAdd, &=に対するBitAndAssignと同じ位置づけで
(*T)に対するDerefがstd::opsに入ってるイメージだけど
(*T）自体は
let x: Box<String> = Box::new(String::from("foo"));
let y: String = *x;
みたいに参照先の値を取り出す使い方ができてむしろそっちが本来の意味なのに
それができないtrait DerefがDerefを名乗ってるのが微妙だと思った

123:デフォルトの名無しさん
24/02/26 19:45:57.01 CpQkWMmQ.net
>>121
サンクス。
「演算子」じゃなくて「 * (参照外し演算)」ということね。

124:デフォルトの名無しさん
24/02/26 19:57:36.80 31wdHwrp.net
>>116
*を明示的に付けるとdereferenceされるからDeref
&**によるcoerceは何も付けずに適用される
そのため参照から参照へ型が変わるだけで参照のままとなる
 >>119
Derefはoperatorなのでstd::opsにある
Derefでも&T→Tと実装されている
Derefによるcoerceは&**となる

125:デフォルトの名無しさん
24/02/26 20:43:46.74 YO//rx0m.net
関数と同じでは困るものといえば && || が有名だけど = が一番やばい
初期化とか代入とかコピーとか移動とか

126:デフォルトの名無しさん
24/02/26 20:52:21.27 isya6kWo.net
>>125
=はパターンマッチング
マッチングした時にCopy実装があればコピーされる
以上で極めてシンプル

127:デフォルトの名無しさん
24/02/26 21:10:51.91 ucgwnOih.net
Rustにおける = は心の中でバインド演算子って呼んでるわ

128:デフォルトの名無しさん
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は&**となる
全然わからない
何か一つくらい根拠を提示してくださいな

129:デフォルトの名無しさん
24/02/27 01:17:48.86 keoFxKh8.net
Derefによるcoerceは&**となるのが全然わからないって本気なのかな？
「corece後の参照」= &**「corece前の参照」
となるのがDerefによるcoerceだよ

130:デフォルトの名無しさん
24/02/27 03:35:57.72 Q3TDZDiV.net
READ THE FUCKING MANUAL
URLﾘﾝｸ(doc.rust-lang.org)

131:デフォルトの名無しさん
24/02/27 05:16:27.87 2XUMNloz.net
>>129
＞「corece後の参照」= &**「corece前の参照」
実験コード書いて一通り確認してみたら
たしかにそうなった

132:デフォルトの名無しさん
24/02/27 08:57:02.46 +775Shg6.net
上の一連の流れ見てるだけでRustしんどそうに見える

133:デフォルトの名無しさん
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しないのでコンパイルエラー

134:デフォルトの名無しさん
24/02/27 10:44:06.64 HDl/V1Sy.net
こんな議論が発生する時点でかなりややこしくて面倒な言語がであることは認めざるを得ない

135:デフォルトの名無しさん
24/02/27 11:23:28.24 gx7SRESn.net
そんなことよりDerefの定義の中で参照外ししている↓が無限ループにならない理由でも調べてみたほうが面白いよ
URLﾘﾝｸ(doc.rust-lang.org)

136:デフォルトの名無しさん
24/02/27 11:27:25.60 90WdzyYj.net
>>135
それが&T→TはDerefの役割ではないという話

137:デフォルトの名無しさん
24/02/27 11:56:56.99 xI+UYr05.net
rustは使い勝手のために暗黙にokにした構文が逆にわかりづらさを生んでる。

138:デフォルトの名無しさん
24/02/27 12:07:27.17 NfALWDmT.net
>>137
まあそれは他の言語も歩んできた道だから……
良いとは言わんけどなくてもめんどいんだよな。

139:デフォルトの名無しさん
24/02/27 12:18:37.87 Q3TDZDiV.net
>>136
*selfはそれでいいけど、**selfはそれじゃ説明付かんぞ

140:デフォルトの名無しさん
24/02/27 17:59:37.59 KfBq61Mu.net
>>139
&T→Tと同じでBox<T>に対する*演算子もコンパイラビルトインだからDerefのimplは使われない

141:デフォルトの名無しさん
24/02/27 18:12:58.39 lr8nToMg.net
Rustってなんでzipを「簡単」に操作するクレートが一つもないんだ？
Tauriがこなれてきたからそろそろ.NETからアプリをRustにポーティングしようかなと思ったらエコシステムがまるで成長していない・・・

142:デフォルトの名無しさん
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されている

143:デフォルトの名無しさん
24/02/27 18:33:30.42 p5E54fv2.net
>>141
圧縮アーカイブならzipクレート
圧縮ならlibflateクレートなど

144:デフォルトの名無しさん
24/02/27 19:01:36.79 MCZ6xJKz.net
>>133
＞ coercion
横から素人がすまん、これ何て読めばいいの？

145:デフォルトの名無しさん
24/02/27 19:26:56.87 kSGISY6y.net
Rustもちょっと前の熱狂はなくなってしまった感じ
入込数が減ってると思う

146:デフォルトの名無しさん
24/02/27 19:39:57.60 ptyRkm62.net
まあ熱狂系の人は実用言語嫌いそうだし、熱狂系がいなくなったのは良いことでは

147:デフォルトの名無しさん
24/02/27 19:51:34.77 gLAGJv50.net
>>144
発音[US] kouə́ːrʒən ｜ [UK] kouə́ːʃən
カナ[US]コウアァジョン、[UK]コウアーション
参考：URLﾘﾝｸ(eow.alc.co.jp)
自分はコアジョン派

148:デフォルトの名無しさん
24/02/27 20:18:10.37 p5E54fv2.net
>>144
コアーション派

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

次ページ