Rust part23
1 :デフォルトの名無しさん :2024/02/23(金) 17:37:52.13 ID:CheDQupm.net 公式 https://www.rust-lang.org/ https://blog.rust-lang.org/ https://github.com/rust-lang/rust 公式ドキュメント https://www.rust-lang.org/learn Web上の実行環境 https://play.rust-lang.org ※Rustを学びたい人はまず最初に公式のThe Bookを読むこと https://doc.rust-lang.org/book/ ※Rustを学ぶ際に犯しがちな12の過ち https://dystroy.org/blog/how-not-to-learn-rust ※Rustのasyncについて知りたければ「async-book」は必読 https://rust-lang.github.io/async-book/ ※次スレは原則>>980 が立てること 前スレ Rust part22 https://mevius.5ch.net/test/read.cgi/tech/1705760500/ ワッチョイスレ プログラミング言語 Rust 4【ワッチョイ】 https://mevius.2ch.net/test/read.cgi/tech/1514107621/
2 :デフォルトの名無しさん :2024/02/23(金) 18:14:46.11 ID:7HXLfctb.net Rust The Book (日本語版) https://doc.rust-jp.rs/book-ja/ Rust edition guide (日本語版) https://doc.rust-jp.rs/edition-guide/ Rust by example (日本語版) https://doc.rust-jp.rs/rust-by-example-ja/ Rust cookbook (日本語版) https://uma0317.github.io/rust-cookbook-ja/ Rust API guideline (日本語版) https://sinkuu.github.io/api-guidelines/ Rust nomicon book (日本語版) https://doc.rust-jp.rs/rust-nomicon-ja/ Rust async book (日本語版) https://async-book-ja.netlify.app/ Rust WASM book (日本語版) https://moshg.github.io/rustwasm-book-ja/ Rust embeded book (日本語版) https://tomoyuki-nakabayashi.github.io/book/ Rust enbeded discovery (日本語版) https://tomoyuki-nakabayashi.github.io/discovery/ Rust Design Patterns (日本語版) https://qiita.com/Yappii_111/items/4ccc3a8461cdd4035651 https://qiita.com/Yappii_111/items/654717e6a6a980722189 Rust API guideline (日本語版) https://sinkuu.github.io/api-guidelines/
3 :デフォルトの名無しさん :2024/02/23(金) 18:15:20.65 ID:7HXLfctb.net Rust Reference Book https://doc.rust-lang.org/reference/ Rust Standard Library https://doc.rust-lang.org/std/ Rust rustc Book https://doc.rust-lang.org/rustc/ Rust rustdoc Book https://doc.rust-lang.org/rustdoc/ Rust rustup Book https://rust-lang.github.io/rustup/ Rust Cargo Book https://doc.rust-lang.org/cargo/ Rust unstable Book https://doc.rust-lang.org/nightly/unstable-book/ Rust macro Book https://danielkeep.github.io/tlborm/book/ Rust CLI (Command Line Interface) apps Book https://rust-cli.github.io/book/ Rust Future Book https://cfsamson.github.io/books-futures-explained/ Rust async-std Book https://book.async.rs/ Rust tokio Book https://tokio.rs/tokio/tutorial Rust serde Book https://serde.rs/
4 :デフォルトの名無しさん :2024/02/24(土) 14:37:44.58 ID:TvelBLvi.net 前スレ終盤がRust特有の型🔵ナニー症候群の典型(この用語は出典参照) https://mevius.5ch.net/test/read.cgi/tech/1705760500/977- Netflixは2年かけて気が付いたけど凡人程のめり込む沼 出典 https://www.youtube.com/watch?v=6gwF8mG3UUY Haskellの時と同様、概念だけ触れたら他の言語に活かすのが良い 長居していると症候群認定される危険性があるから
5 :デフォルトの名無しさん :2024/02/24(土) 14:48:37.96 ID:cR8FpHrN.net >>4 それ何の情報もなく見ても無駄 具体的な説得力ある話がない TypeScriptが嫌いでGoが好きらしい
6 :デフォルトの名無しさん :2024/02/24(土) 16:14:50.39 ID:yK1YDROT.net Rustから前スレ終盤の型オナニーをなくしたような言語があれば使いたいけど、ないから仕方なくRustを使っている
7 :デフォルトの名無しさん :2024/02/24(土) 16:23:38.76 ID:GLkrdyDg.net 静的型チェックレベルを高めつつジェネリクス等による汎化を活用しようとすれば大なり小なり型オナニーは避けられない RustやTypeScriptだけでなくC++のtemplateやPythonの型ヒントでも同じこと 単独のTraitだけの話で型オナニーとか言ってるやつはオナニーレベルが低過ぎ 静的型チェックへの適性がないのでRustも辞めた方がいい
8 :デフォルトの名無しさん :2024/02/24(土) 16:34:30.38 ID:vVxC7GCC.net 型オナニーより所有権やライフタイム管理の方が面倒だけどな それが型と絡むからさらにややこしくなる
9 :デフォルトの名無しさん :2024/02/24(土) 17:03:48.32 ID:4NvD6VS8.net 動的型付け言語しか慣れてない初心者が静的型付け言語に慣れるまで時間がかかるのは当たり前 GC前提言語しか慣れてない初心者がそうでない言語に慣れるまで時間がかかるのは当たり前 プログラミングに向いてる人ならどちらもすぐに慣れる そんなことで文句を言っているようではプログラミングに向いていない
10 :デフォルトの名無しさん :2024/02/24(土) 17:13:41.82 ID:V+W4sktV.net Rustの型オナニーは「本当は1つにまとめても良いんだけど歴史的経緯で2種類あります」みたいなのが稀にあって気持ち良くない
11 :デフォルトの名無しさん :2024/02/24(土) 17:33:53.05 ID:rpcvr5yl.net >>10 妄想楽しいですか?
12 :デフォルトの名無しさん :2024/02/24(土) 18:25:50.38 ID:+fQ0JdTj.net >>8 それRust特有だよね 時間がどんどん溶ける
13 :デフォルトの名無しさん :2024/02/24(土) 18:33:24.91 ID:Sbx59RJL.net asはそろそろFrom/TryFromに統一してほしいんだけど
14 :デフォルトの名無しさん :2024/02/24(土) 20:45:24.03 ID:Mj/QkYpd.net 型オナニーって全部習得するまでにいったいどれだけ時間かかるんだ
15 :デフォルトの名無しさん :2024/02/24(土) 20:47:39.26 ID:fAQkBdOO.net 型オナニー四十八手
16 :デフォルトの名無しさん :2024/02/24(土) 22:10:17.16 ID: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 :デフォルトの名無しさん :2024/02/24(土) 22:13:12.85 ID:SuzjS9X3.net 打ち間違い 252でなく253ね
18 :デフォルトの名無しさん :2024/02/24(土) 22:51:22.10 ID:Sbx59RJL.net >>16 それだけならstdにimpl From<i32> for Wrapping<u8>でも入ってくれれば事足りると思うが…… asって手軽なだけで変換元と変換先の型ごとに意味が複数あるのが複雑で嫌いなんじゃ C++のC形式キャストみたいな印象
19 :デフォルトの名無しさん :2024/02/24(土) 22:53:55.08 ID:Sbx59RJL.net え、てかそもそも演算オーバーフローはpanicするのにキャストはpanicしないのか だるっ そういうとこやぞ
20 :デフォルトの名無しさん :2024/02/24(土) 23:26:44.50 ID:1jp0hNdJ.net 生演算子はオーバーフローせずラッピングされる panicはデバッグ時のみ 明示的にラッピングしたいときはwrapping_add オーバーフローを処理したいときはchecked_addやoverflowing_addまたはsaturating_add
21 :デフォルトの名無しさん :2024/02/25(日) 01:04:03.14 ID:/M3V/hwr.net 型オナニーって複雑な型パズルを解いて悦に入ることを言ってるのかと思いきや 標準ライブラリの基本的な使い方を覚えることなのかよ オナニー要素ゼロじゃん そんなマインドではRustに限らず言語習得は無理だぞ
22 :デフォルトの名無しさん :2024/02/25(日) 01:05:34.01 ID:PHCSkV3G.net そんなマインドでもGo言語なら習得出来るんだよなあ
23 :デフォルトの名無しさん :2024/02/25(日) 01:14:51.15 ID:Y4TucXFt.net バカはGoへ行くしかないよ Rustなどは一般的なプログラミング能力がある人向け
24 :デフォルトの名無しさん :2024/02/25(日) 01:52:59.15 ID:5QMstwYR.net >>22 それはたまたま動いてるようなもんだぞ。
25 :デフォルトの名無しさん :2024/02/25(日) 09:14:13.54 ID:F2CUOiYD.net Rustの開発って時間掛かりそうなイメージある とりあえず作ってみて後でリファクタリングって作り方ができない感じ?
26 :デフォルトの名無しさん :2024/02/25(日) 09:49:58.55 ID:JC//7tos.net termuxよりscreen派なんだよなぁ。ライセンスはgplよりbsdのが好きなんだけど。
27 :デフォルトの名無しさん :2024/02/25(日) 10:13:55.36 ID:CWUdGBuB.net >>21 リアルの会話でこうやってRustのマイナス面を他と同じと言う奴は 内心信用してない >>23 言い方があれだけどこっちの方が信用できる
28 :デフォルトの名無しさん :2024/02/25(日) 10:16:51.38 ID:m/LZ7YZH.net >>25 リファクタリングってのは外部から見た時の挙動を変えないのが原則なので 少なくとも型やライフタイムについては辻褄が合っていることを保証できる仕組みは リファクタリングでも便利なんだぞ。 内部的な処理でもあまり柔軟には変えづらいということはあるけど 変えづらいところは (外部に対する保証に関わってくるので) 変えてはならない箇所だってことがわかる。
29 :デフォルトの名無しさん :2024/02/25(日) 10:21:38.07 ID:UdSUU0Ni.net >>9 ✕プログラミングに向いていない ○rustに向いていない 皆さん、これがrust信者です
30 :デフォルトの名無しさん :2024/02/25(日) 11:59:50.84 ID:sgD3xFEl.net >>6 せめてtraitに外延性があって集合的操作ができればいいんだけど、さすがにビルドに時間掛かりそうだしな。 ただでさえビルド時間が重たいから、設計の「早すぎる最適化」は仕方ないのかね。
31 :デフォルトの名無しさん :2024/02/25(日) 12:12:53.79 ID:swktBlsa.net >>26 screenってまだメンテされてんの?
32 :デフォルトの名無しさん :2024/02/25(日) 12:43:55.95 ID:JQupN8F5.net >>28 例えばpythonとかだと型とかプログラム構造気にせずにパパッと書いて ある程度動くスクラッチでレビューして内容詰めて スクラッチから流用できそうなら作り込んでリファクタリングみたいにできるけど Rustだとそういう風にできなさそう
33 :デフォルトの名無しさん :2024/02/25(日) 12:48:37.70 ID:AFiN8NTf.net >>23 こういうのに限ってgoでもろくなもの書けない
34 :デフォルトの名無しさん :2024/02/25(日) 12:50:53.73 ID:lnNUwEQk.net >>32 Pythonだとそのリファクタリング前後で挙動が変わってしまわないように気を遣うのがしんどいな そういうとりあえず試しに作るケースだとユニットテストなんかも当然ない状況なんで Rustに限らず静的型ならその辺をだいたいコンパイルエラーで拾えるのが楽
35 :デフォルトの名無しさん :2024/02/25(日) 13:03:20.25 ID:WCq5qF7l.net >>27 「僕は基本Traitがよくわからない => それはRustのマイナス面」 この発想が幼稚さがわからないのかな? 他の言語と比べたときのRustのマイナス面はたくさんあるがそういう話のレベルじゃないだろ
36 :デフォルトの名無しさん :2024/02/25(日) 13:05:42.89 ID:Y4TucXFt.net >>32 動的型付け言語しか使ったことがない初心者が 静的型付け言語の圧倒的なメリットを理解できないのはよくあるあるある 脱初心者の壁を乗り越えよう
37 :デフォルトの名無しさん :2024/02/25(日) 13:18:05.49 ID:Y4TucXFt.net どんな言語にもマイナス面がありRustにもある しかしマイナス面を上回る莫大なメリットがRustにはいくつもあるからIT業界をあげてRustを支援&採用している 揚げ足取りでRustを叩きたいだけの人はアンチスレへ行け
38 :デフォルトの名無しさん :2024/02/25(日) 13:23:45.23 ID:/3HpHAOM.net >>36 知らないのかもしれないけど今のPythonはどちらもできる
39 :デフォルトの名無しさん :2024/02/25(日) 13:29:34.11 ID:cAT3nYdz.net >>35 どんな理由であれ複雑なのはマイナスだろ 複雑なのがプラスだってんならC++かbrainfuckやれよ
40 :デフォルトの名無しさん :2024/02/25(日) 13:33:19.74 ID:m/LZ7YZH.net 漸進的型付けは静的片付けと動的型付けのどちらも出来るわけではなくて漸進的型付けという別物だと解釈すべきだと思うよ。
41 :デフォルトの名無しさん :2024/02/25(日) 13:35:59.16 ID:m/LZ7YZH.net >>39 能力が同じなら複雑さはマイナスだが複雑にしてでもそれを上回るメリットが得られることがあるという話だということも理解できないの? トレードオフ
42 :デフォルトの名無しさん :2024/02/25(日) 13:47:25.26 ID:cAT3nYdz.net >>41 >>35 はそんなこと書いてないぞ > 「僕は基本Traitがよくわからない => それはRustのマイナス面」 > この発想が幼稚さがわからないのかな? だぞ。勝手に自分の文脈を他の人のレスに上乗せして書いてない解釈を押し付けるなよガイジ
43 :デフォルトの名無しさん :2024/02/25(日) 13:51:18.30 ID:qsle6rXj.net Rustで有名アルゴリズムに挑戦 第16回 Rustで機械学習に挑戦 - k近傍法でアヤメの分類をしよう https://news.mynavi.jp/techplus/article/rustalgorithm-16/ 共同作戦で壊滅したマルウェア「Qakbot」復活、米国は犯行グループを逮捕できず https://news.mynavi.jp/techplus/article/20240225-2885670/ 悪意あるPythonパッケージを2つ発見、DLLサイドローディング技術悪用 https://news.mynavi.jp/techplus/article/20240225-2889952/ 充電式バイブレータからマルウェア検出、USB充電デバイスに注意 https://news.mynavi.jp/techplus/article/20240224-2889949/
44 :デフォルトの名無しさん :2024/02/25(日) 13:53:04.35 ID:Y4TucXFt.net ここはRustユーザが集うRustスレ 叩きたいだけのキチガイはアンチスレへ行け
45 :デフォルトの名無しさん :2024/02/25(日) 13:56:41.04 ID:Y4TucXFt.net >>43 なるほど https://news.mynavi.jp/techplus/article/rustalgorithm-16/images/001.jpg
46 :デフォルトの名無しさん :2024/02/25(日) 14:00:42.93 ID:qsle6rXj.net C++の後継目指すプログラミング言語「Carbon Language」、Googleの技術者が実験的公開。C++は技術的負債で改良が困難と https://www.publickey1.jp/blog/22/ccarbon_languagegooglec.html
47 :デフォルトの名無しさん :2024/02/25(日) 14:05:55.86 ID:gx/ep+tD.net >>37 嘘はいかんよ Rustにはメリットなし、がIT業界の総意 Adaの方が上 最新版IEEE調査Jobs https://i.imgur.com/Z8hI9C6.png
48 :デフォルトの名無しさん :2024/02/25(日) 14:10:17.03 ID:cAT3nYdz.net Jobで判断するのはちょっとなあ Jobの要件にするのってその言語さえ出来れば良い人を探す時じゃん Rustってまだそのフェーズではないんだよな
49 :デフォルトの名無しさん :2024/02/25(日) 14:19:17.62 ID:2NfnhAyO.net >>48 言うてメインはOSS用だよね 大手はちょっとばかり資金援助してレバレッジ効かせようと宣伝して 2021-2022がRustハイプのピークだったんだけど真水のJobは稀
50 :デフォルトの名無しさん :2024/02/25(日) 14:25:08.84 ID:zbRFIfV6.net >>46 Carbonはその公式FAQに明記してるように Rustを使える状況ならRustを使ったほうがいいという立ち位置 Carbonは既存のC++遺産メンテ用
51 :デフォルトの名無しさん :2024/02/25(日) 14:32:26.24 ID:is3AzB4D.net >>49 次々とRust製へ変わっていってる リソース面すなわち経済的にもエコ的にもRustが有利なので今後次々とRust製へ置き換わっていく ソース >【クラウド世界トップシェアAWS】 >https://japan.zdnet.com/article/35183866/ >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】 >https://www.publickey1.jp/blog/22/cloudflarenginxrusthttppingoracdncpu31.html >CDNプロバイダのCloudflareは、同社のグローバルなCDNの基盤として長らく利用してきたNGINXに代えて、 >同社自身がRust製のHTTPプロキシである「Pingora」を開発し利 用していることを明らかにしました。
52 :デフォルトの名無しさん :2024/02/25(日) 14:38:19.37 ID:+AfYZ5AE.net Rustは知らず知らずのうちに技術的負債を量産しそうな気配だな Rustは既に違法建築だから 前スレで言われる矮小化オンパレードで笑ったw 前スレ https://mevius.5ch.net/test/read.cgi/tech/1705760500/9 >>https://mevius.5ch.net/test/read.cgi/tech/1692105879/990 一応知らない人のために書いておくけど 「Rustがunsafeコード一切なしでメモリアンセーフ」な事が判明してから半年近く経ってる 特定の機能導入のタイミングでコードが発見されたけど、 「Rustの仕様バグ」だと認識されていて直せない >>4 そんな事並べて理解したつもりでも、分からないと言っている人の側の主張が正当なんだよ 最近はここでも保証って言われなくなっただろ、当たり前だよRustの仕様に健全性が無いのだから たぶん知っていて話を逸らしているのか、過去スレでスルーしたかで、この指摘も無理やり矮小化してくるからな (githubの議論でも矮小化して放置) 気を付けろよ https://github.com/rust-lang/rust/issues/114936
53 :デフォルトの名無しさん :2024/02/25(日) 14:45:16.11 ID:8UflVtOh.net >>52 情報古いな AmazonはLLRTでしょ cloudflareのRustは放置だ
54 :デフォルトの名無しさん :2024/02/25(日) 14:48:00.26 ID:3ePlkypT.net 誰も問題視していないどうでもいいことでしかRustを叩けない状況 アンチが追い込まれている
55 :デフォルトの名無しさん :2024/02/25(日) 14:53:16.67 ID:8UflVtOh.net >>53 は>>51 向けな >>52 のは違うIssue/PRのcommitで場当たり的fixしただけで知れっと本質を隠蔽した >>54 問題視したから取り繕いfixしたんだよ
56 :デフォルトの名無しさん :2024/02/25(日) 14:56:15.69 ID:8UflVtOh.net >>37 ,47 上位は納得だから結局のところ「IT業界をあげて」なんて言いたかったら Jobで判断するのが客観的で中立フェアな基準なんだな
57 :デフォルトの名無しさん :2024/02/25(日) 14:59:17.67 ID:GfahaNNz.net >>53 LLRTはAWS LambdaでJavaScriptを使いたい人向けのJSランタイムの一つ Rustが使えるならRustを使ったほうが有利 さらにAWS自体も>>51 にソースがあるようにRustで書かれている
58 :デフォルトの名無しさん :2024/02/25(日) 15:03:11.52 ID:h80FlwFJ.net >>57 後半 部分的にな あとそのソースとやらのLiam Tungはいなくなったね 飛ばし過ぎた?
59 :デフォルトの名無しさん :2024/02/25(日) 15:09:15.42 ID:h80FlwFJ.net >>57 >Rustが使えるなら 時々見るこの枕詞は実際の現場では使えない事の証拠なんだよなぁ
60 :デフォルトの名無しさん :2024/02/25(日) 15:10:35.35 ID:h80FlwFJ.net >>57 >JavaScriptを使いたい人 これが圧倒的だからAmazonが独自魔改造したから凄い
61 :デフォルトの名無しさん :2024/02/25(日) 15:27:26.81 ID:GfahaNNz.net >>59 そのAWS Lambdaでも当然Rustを使えます Rustを使えないのは環境ではなく低層プログラマー
62 :デフォルトの名無しさん :2024/02/25(日) 15:30:50.61 ID:na8ub8Oh.net >>55 この恣意的な例以外で同様の脆弱性が生まれる例があれば教えて欲しい 煽りとかではなく
63 :デフォルトの名無しさん :2024/02/25(日) 15:48:37.00 ID:3ZfnE9eN.net >>62 俺も煽りじゃなく警鐘で言うけど >>55 の根本原因究明がならなかったから、今後も散発的に発見しては穴ふさぎをするのでは (CVE報告しないで悪用されたら最悪だけど) Rustのメモリ安全性目標チェックは他の言語と比べて 相対的にメリットがあったりデメリットがあったりするだけのことだから
64 :デフォルトの名無しさん :2024/02/25(日) 16:02:53.19 ID:4fScDWQR.net >>62 恣意的ってそういう意味じゃないですよ
65 :デフォルトの名無しさん :2024/02/25(日) 16:07:08.08 ID:na8ub8Oh.net 例出せないならお前が偉そうに言うことではないぞ どの立場からもの言ってるんだ?
66 :デフォルトの名無しさん :2024/02/25(日) 16:10:58.09 ID:37W0dlDW.net >>62 >>65 化けの皮が剥がれるの早すぎて草
67 :デフォルトの名無しさん :2024/02/25(日) 16:11:46.86 ID:na8ub8Oh.net 俺の質問に答えずに訳のわからないことを言うしかできないんですね くだらないクズが
68 :デフォルトの名無しさん :2024/02/25(日) 16:14:14.27 ID:wVCQJTWx.net >>52 実際の開発では出てこない極端に作り上げた例のみだから Rustを採用しているIT大手を含めて問題視していない
69 :デフォルトの名無しさん :2024/02/25(日) 16:19:05.44 ID:5Lw05PSN.net >>66 ちなみに急に煽り始める>>65 ,67はあのコテハン >>68 >実際の開発では出てこない極端に作り上げた例 自分で踏んだ事ないから想像だけど、失敗を犯すのはその考え方の人間
70 :デフォルトの名無しさん :2024/02/25(日) 16:21:52.97 ID:na8ub8Oh.net いや煽ってきたのはお前だろw 何を勘違いしてるんだ
71 :デフォルトの名無しさん :2024/02/25(日) 16:23:31.57 ID:na8ub8Oh.net 自分が攻撃するのは良くて攻撃されるのは嫌か? そういうやつには徹底的にやるから覚悟しろよ 俺に攻撃するってことはそういうことだ
72 :デフォルトの名無しさん :2024/02/25(日) 16:24:39.64 ID:4fScDWQR.net 誰やねん
73 :デフォルトの名無しさん :2024/02/25(日) 16:27:11.46 ID:LjVpirDf.net 自分以外が全部同一人物だと思い込んでるアタオカの着火点は意味不明だよな
74 :デフォルトの名無しさん :2024/02/25(日) 16:31:47.21 ID:wVCQJTWx.net >>69 実際にコードを見てごらん ありえない無意味なコード 識者たちも問題視していない
75 :デフォルトの名無しさん :2024/02/25(日) 16:36:11.19 ID:sIg5Fob3.net >>71 誰も攻撃してないのにこの人怖い、やめてくれませんか 心理的安全性を通り越して身の危険を感じる((((;゚Д゚))))ガクガクブルブル
76 :デフォルトの名無しさん :2024/02/25(日) 16:37:37.04 ID:4fScDWQR.net 例の#25860、ジェネリクスとかマクロ生成の裏で意図しないでこのパターン踏んだりしない? 絶対ない?
77 :デフォルトの名無しさん :2024/02/25(日) 16:37:39.99 ID:muM7k3Ml.net rustでリファクタリングしながらの開発ってなると多分unsafeを途中経過で入れたりとか そういうテクニックが必要になると思う。 その辺の整備が進めば割と広まるかもね。
78 :デフォルトの名無しさん :2024/02/25(日) 16:45:35.35 ID:wVCQJTWx.net >>76 絶対にないから安心していい その「&'static &'a ()」が出てくることはない
79 :デフォルトの名無しさん :2024/02/25(日) 16:50:17.61 ID:4fScDWQR.net >>78 理由は?
80 :デフォルトの名無しさん :2024/02/25(日) 16:51:49.35 ID:zhB6NxSY.net >>32 サクッとプロトタイピングする目的ならそりゃRustよりPythonのほうが向いてる Rustは多少手間がかかったとしても速度・安全性・堅牢性を高い水準で求める場合に使う言語 >>39 AsRefやTryFromが複雑とか言われても困ります
81 :デフォルトの名無しさん :2024/02/25(日) 16:52:52.76 ID:hjrqLcFN.net >>77 unsafeは基本的に不要 必要だと思ってもまず標準ライブラリにその機能がないか調べる 次にクレートにその機能がないか調べる どこにも存在しない場合 unsafeを安全に閉じ込めて安全に使うことができる有用な機能を発見したのならばラッキー それをクレートとして公開するとよい
82 :デフォルトの名無しさん :2024/02/25(日) 17:06:44.48 ID:4fScDWQR.net Rustコンパイラチームは意図せず発生する可能性を否定していない様子 ここのヤツはやっぱりテキトー言ってるだけか https://hackmd.io/@rust-compiler-team/SkkrA1DCK#Variance > https://github.com/rust-lang/rust/issues/25860 > root issue of most variance issues > ⚠🚨⚠ can potentially just happen by accident
83 :デフォルトの名無しさん :2024/02/25(日) 17:26:51.68 ID:O13egj5J.net >>77 同じ構造体の一部を参照しながら別の一部を書き換える大きめのメソッドを 複数のメソッドに分割しようとするとborrow checkerに引っかかる的な話かな 他の言語のクラスと同じ感覚で構造体作るとたまに嵌る Rustの構造体はRDBのテーブルを正規化する雰囲気で分割した方がいい
84 :デフォルトの名無しさん :2024/02/25(日) 17:30:07.94 ID:hjrqLcFN.net >>82 Rustのvariance仕様だから発生させることはできるけど 現実に使うコードでは発生しない 意図的にその仕様の狭間をつく現実的でないコードでのみ発生する そのためその2015年からそのまま放置で誰も困っていない
85 :デフォルトの名無しさん :2024/02/25(日) 17:45:11.19 ID:4fScDWQR.net >>84 by accidentを辞書で引いてこい
86 :デフォルトの名無しさん :2024/02/25(日) 17:51:15.22 ID:hjrqLcFN.net >>85 その2015年から9年間 その問題でトラブルが起きたことがない
87 :デフォルトの名無しさん :2024/02/25(日) 17:55:53.01 ID:bLJeGl/a.net >>81 >unsafeは基本的に不要 >...ラッキー 嘘で始まって運頼みで締めるとはw 信者の心の支えの大手のあそこは 見境なくunsafeを使わざるを得なくなって Rustでやった意味が無くなってるってよ
88 :デフォルトの名無しさん :2024/02/25(日) 17:56:42.46 ID:m/LZ7YZH.net 可能性を論じるならお前の頭に隕石が落ちてくる可能性だってあるが、そんなことを心配したことある?
89 :デフォルトの名無しさん :2024/02/25(日) 18:03:36.71 ID:c6Ww7brW.net RustはVec等のCVE前科があるからなぁ 頭に隕石が落ちたんじゃね?
90 :デフォルトの名無しさん :2024/02/25(日) 18:07:11.51 ID:e56nXER6.net 開発プログラムでunsafeを直接使うことはほとんどない unsafeが閉じ込められ安全なインターフェースが公開されている形で間接的にのみ用いる どうしてもunsafeが必要になった場合でもそのように安全な形で分離して用いる
91 :デフォルトの名無しさん :2024/02/25(日) 18:10:03.77 ID:4fScDWQR.net 隕石であれ何であれそれがエンジニアリング可能な対象なら問題を特定して語る意味はあるだろう
92 :デフォルトの名無しさん :2024/02/25(日) 18:19:05.40 ID:e56nXER6.net >>89 Dropで型がpanicする時にその要素をた用いたVec::from_iter()で二重解放のバグが発見された件か もちろん他の言語と同様に全ての言語においてライブラリにバグが見つかることは当然ある Rustはその点でも少ない方なので信頼して使える
93 :デフォルトの名無しさん :2024/02/25(日) 18:30:56.08 ID:F3hFw1lw.net >>90 ,92 思い描く理想と現実の落差が激しいな Rust不信の原因だぞ とくに>>92 の最後の行があるから信用されない
94 :デフォルトの名無しさん :2024/02/25(日) 18:43:22.50 ID:hlYoDW1g.net Rustの2023年のCVEはCargoで名前をエスケープし忘れた1件のみ Rustの2022年のCVEは0件 つまりRustコンパイラについて過去2年間でCVEなし 信頼度が高いと言える
95 :デフォルトの名無しさん :2024/02/25(日) 18:49:05.16 ID:cAT3nYdz.net Rust以外のコンパイラってそんな言うほどバグないか?
96 :デフォルトの名無しさん :2024/02/25(日) 19:34:08.90 ID:O13egj5J.net 普通にあるけどみんなで使うから大部分はリリース前に潰される コンパイラというよりライブラリのバグみたいだけど他の言語より未定義動作にシビアだから バグ扱いされる事例が増えるのは仕方ない
97 :デフォルトの名無しさん :2024/02/25(日) 19:46:15.91 ID:pvICb5ke.net >>91 お前のとこは無限のリソースがあるのかな? いいなぁ優先順位考えなくていい環境。うらやましいよ。
98 :デフォルトの名無しさん :2024/02/25(日) 19:49:21.58 ID:+aJmKKn5.net 今となっては未定義動作の多い言語を使うのは悪行だ Rustを使うべし
99 :デフォルトの名無しさん :2024/02/25(日) 20:11:25.55 ID:yYiD0TuW.net >>82 ここの信者はテキトー過ぎるよな コンパイラ開発チームはもとより、サーベイ回答者もコンパイラバグ潰しを最優先、が一番多い
100 :デフォルトの名無しさん :2024/02/25(日) 20:15:02.43 ID:yYiD0TuW.net >>97 余裕があるからRustもやる、と言うのが普通だな サーベイでも(余裕がなくなって)Rust採用予定なし、なぜなら他言語採用予定だから、が一番多い (ただし採用にはインターンも含まれる)
101 :デフォルトの名無しさん :2024/02/25(日) 20:24:50.38 ID:0y8maAN+.net >>99 対処の必要があるものはその通り しかし実害がないと皆が判断して対処優先度低いまま9年間が経過したが実害がな起きていない そんな状況のものを杞憂したり揚げ足取りでRustを叩いてる連中がゴミ
102 :デフォルトの名無しさん :2024/02/25(日) 21:16:46.71 ID:4fScDWQR.net 事実を書かれただけで批判だと思っちゃうようじゃ生きづらかろうな
103 :デフォルトの名無しさん :2024/02/25(日) 21:34:47.98 ID:E/2LoMBL.net >>101 これが矮小化と言うやつか 7割がバグ潰しを「最優先」と回答している事実 直したくても直せないまま何年も経過、unsafe無しでメモリ安全ではない(事実)、Rustの不健全仕様(事実) (unsound=不健全は数学用語、要は矛盾があるという事) 幸運にもRustが使われなさ過ぎで実害がないように見える(または報告がないだけ) (良心的に考えてRustが広く使われてない内に)バグ潰しをしとけ、がユーザーの9割の意見(中優先含めて) 週明けのテック記事はどう書くのかな 良い所だけ抜き出してビューが取れるハイプ期間は弱まったと思う それと飛ばし過ぎるといなくなるorz
104 :デフォルトの名無しさん :2024/02/25(日) 21:37:20.20 ID:PFD3HMoN.net アンチもMozillaが変なことやってるだけで firefoxに導入できるわけがない一般人が 使えるようになるのは妄想とか 言ってた頃に比べると細かい実装の穴を ネチネチやるまでになって大変だなあ
105 :デフォルトの名無しさん :2024/02/25(日) 22:03:27.18 ID:cpTMj4Oj.net >>103 根本的なことを理解できてないようなので一点だけ unsafeがプログラム全体に散らばっている他の言語に対して Rustはunsafeを局所的に閉じ込めて安全なインタフェイスを公開しそれを使ってプログラミングする言語 よく使われる基本機能は標準ライブラリとしてunsafeを閉じ込めてあるが 必要なら自作を含めてunsafeを閉じ込めたライブラリを使ってよい 他の言語と比べてunsafeを局所的に閉じ込めた部分のみ注視すればよいことがRustのメリット
106 :デフォルトの名無しさん :2024/02/25(日) 22:16:32.90 ID:uv4EdbLT.net >>105 unsafeに閉じ込められなかった事実を提示されてるんだが何言ってるんだ?
107 :デフォルトの名無しさん :2024/02/25(日) 22:32:50.41 ID:cAT3nYdz.net Rustコンパイラにバグがあるのはかなりキモくて嫌だけど、Rustの利用をやめるほど致命的かというとな
108 :デフォルトの名無しさん :2024/02/25(日) 22:47:36.07 ID:m/LZ7YZH.net C++ の未定義を踏んでもおかまいなしってよりは原則として問題は検出する (けどちょっとはバグもある) Rust のほうがだいぶんマシな言語設計ではある。
109 :デフォルトの名無しさん :2024/02/25(日) 23:03:18.85 ID:AXW02Nd1.net unsafeなライブラリがRust用の安全なインターフェースを公開することにより保証される安全性とは もちろん呼び出される側の安全性ではない 呼び出す側だけが検査される しかも検査が完璧かどうかは実装依存 じゃあ言語仕様により保証されるのは何か 言語仕様は、あとは検査が通るか通らないかを確かめればよいというところまで仕様を確定しなければならない
110 :デフォルトの名無しさん :2024/02/25(日) 23:10:45.79 ID:Wz/bOaUk.net プログラム全体がunsafeなC/C++は使いたくない 未定義な動作も多すぎる
111 :デフォルトの名無しさん :2024/02/25(日) 23:49:12.62 ID:bSwN5N4x.net >>109 Rust関係無しに基本的なことを理解できてないようだけど 掛ける情けも無し
112 :デフォルトの名無しさん :2024/02/26(月) 00:02:36.23 ID:cKYYV9zq.net 反論できないときは関連するワードを含むRustの宣伝文句をぶつける いつもの流れです
113 :デフォルトの名無しさん :2024/02/26(月) 00:08:01.38 ID:GUFKxV6c.net 難易度は高くとも増加するユーザー、Rustチーム2023年調査「State of Rust Survey」 難易度は高くとも増加するユーザー、Rustチーム2023年調査「State of Rust Survey」 https://news.mynavi.jp/techplus/article/20240222-2889545/
114 :デフォルトの名無しさん :2024/02/26(月) 00:10:06.79 ID:nyM0yI5t.net >>105 ,109 詐欺師みたいな偽者だな、Rust不信の種まきするのやめろ >>112 分かっていれば支離滅裂文章なんだけど騙されるのは学生位だろうか
115 :デフォルトの名無しさん :2024/02/26(月) 05:11:35.79 ID:G5weOmRY.net >>前スレ992 Derefは演算子 ・そのためstd::ops::Derefにある (変換std::convert::AsRefと対照的) ・演算子*によりderefされる ・&**へとcoerceされる
116 :デフォルトの名無しさん :2024/02/26(月) 13:22:06.51 ID:vLFZOOEE.net Derefの名前の由来は*演算子(dereference:参照解決)だろうけど 機能は&**へのcoerceを前提にしてて結果的にrefのままだからややこしいな 現状だとInnerRefの方がしっくりくる
117 :デフォルトの名無しさん :2024/02/26(月) 13:34:26.79 ID:vLFZOOEE.net 意味的にはFollowRefの方が自然かな まあ*演算子で使われるtraitだからDerefでいいんだけど
118 :デフォルトの名無しさん :2024/02/26(月) 17:12:18.82 ID:hotfpUjh.net 【AI】Stable Diffusion 3発表、Soraで話題の拡散トランスフォーマーを採用 [すらいむ★] http://egg.5ch.net/test/read.cgi/scienceplus/1708865670/l50 ボイス・トォ・スカるしている者も攻撃を受けるようになりました
119 :デフォルトの名無しさん :2024/02/26(月) 18:21:55.22 ID:K4z1iUSz.net >>115 >・&**へとcoerceされる これDeref Coercionのこと言ってる? だとしたら&**に限定する意味がわからない あと前スレ992で重要なのは&T→TはDerefの役割ではないというところね >>116 ,117 スマートポインタのdereferenceのために存在するTraitだから InnerRefやFollowRefよりDerefのほうがずっと自然だと思う *演算子の振る舞いとは別にcoercionの振る舞いは理解しなければいけない そういう点でも「Derefは演算子」という捉え方は良くないよ
120 :デフォルトの名無しさん :2024/02/26(月) 19:05:39.95 ID:CpQkWMmQ.net Rustて、演算子と関数を(意味論的に)区別していたっけ? 中間記法によるややこしい結合順の違いがあるぐらいで、構文解析後は等価だから、あんまりこだわっても仕方が無い気が。 中間記法の演算子は人間の算数の記法に配慮しているだけの悪習でしか無いから、積極的に差異をつけないほうが良い気がするけど。
121 :デフォルトの名無しさん :2024/02/26(月) 19:26:28.00 ID:pFLZLcAJ.net Deref に関しては * 演算子として機能する以外に型強制の規則があるという話の文脈。
122 :デフォルトの名無しさん :2024/02/26(月) 19:44:24.36 ID: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 :デフォルトの名無しさん :2024/02/26(月) 19:45:57.01 ID:CpQkWMmQ.net >>121 サンクス。 「演算子」じゃなくて「 * (参照外し演算)」ということね。
124 :デフォルトの名無しさん :2024/02/26(月) 19:57:36.80 ID:31wdHwrp.net >>116 *を明示的に付けるとdereferenceされるからDeref &**によるcoerceは何も付けずに適用される そのため参照から参照へ型が変わるだけで参照のままとなる >>119 Derefはoperatorなのでstd::opsにある Derefでも&T→Tと実装されている Derefによるcoerceは&**となる
125 :デフォルトの名無しさん :2024/02/26(月) 20:43:46.74 ID:YO//rx0m.net 関数と同じでは困るものといえば && || が有名だけど = が一番やばい 初期化とか代入とかコピーとか移動とか
126 :デフォルトの名無しさん :2024/02/26(月) 20:52:21.27 ID:isya6kWo.net >>125 =はパターンマッチング マッチングした時にCopy実装があればコピーされる 以上で極めてシンプル
127 :デフォルトの名無しさん :2024/02/26(月) 21:10:51.91 ID:ucgwnOih.net Rustにおける = は心の中でバインド演算子って呼んでるわ
128 :デフォルトの名無しさん :2024/02/27(火) 01:03:26.56 ID:38wv4xDP.net >>124 >Derefはoperatorなのでstd::opsにある https://doc.rust-lang.org/std/ops/index.html ここ見ればわかると思うけど各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 :デフォルトの名無しさん :2024/02/27(火) 01:17:48.86 ID:keoFxKh8.net Derefによるcoerceは&**となるのが全然わからないって本気なのかな? 「corece後の参照」= &**「corece前の参照」 となるのがDerefによるcoerceだよ
130 :デフォルトの名無しさん :2024/02/27(火) 03:35:57.72 ID:Q3TDZDiV.net READ THE FUCKING MANUAL https://doc.rust-lang.org/beta/reference/type-coercions.html#coercion-types
131 :デフォルトの名無しさん :2024/02/27(火) 05:16:27.87 ID:2XUMNloz.net >>129 >「corece後の参照」= &**「corece前の参照」 実験コード書いて一通り確認してみたら たしかにそうなった
132 :デフォルトの名無しさん :2024/02/27(火) 08:57:02.46 ID:+775Shg6.net 上の一連の流れ見てるだけでRustしんどそうに見える
133 :デフォルトの名無しさん :2024/02/27(火) 10:40:40.53 ID:90WdzyYj.net >>129 なるほどそういう風に捉えてるのか ちょっと独特だね それはcoercionの動きというよりderefのシグニチャを 内部的にderefを使ってる*演算子で再定義しようとしてるので 循環が気持ち悪いけど一つの見方として頭の隅にしまっておく ちなみにThe Bookにある一つの例ではderef coercionがなければ*が余計に必要と説明されてる https://doc.rust-lang.org/book/ch15-02-deref.html#implicit-deref-coercions-with-functions-and-methods それに&**とは必ずしも等価じゃないからDeref Coercionを説明するのにはあまり勧められないかな let x = "Hello".to_string(); let y = Box::new(x); let z = &**y; //zは&strになる let z:&str = y; //これはcoerceしないのでコンパイルエラー
134 :デフォルトの名無しさん :2024/02/27(火) 10:44:06.64 ID:HDl/V1Sy.net こんな議論が発生する時点でかなりややこしくて面倒な言語がであることは認めざるを得ない
135 :デフォルトの名無しさん :2024/02/27(火) 11:23:28.24 ID:gx7SRESn.net そんなことよりDerefの定義の中で参照外ししている↓が無限ループにならない理由でも調べてみたほうが面白いよ https://doc.rust-lang.org/src/alloc/boxed.rs.html#1927
136 :デフォルトの名無しさん :2024/02/27(火) 11:27:25.60 ID:90WdzyYj.net >>135 それが&T→TはDerefの役割ではないという話
137 :デフォルトの名無しさん :2024/02/27(火) 11:56:56.99 ID:xI+UYr05.net rustは使い勝手のために暗黙にokにした構文が逆にわかりづらさを生んでる。
138 :デフォルトの名無しさん :2024/02/27(火) 12:07:27.17 ID:NfALWDmT.net >>137 まあそれは他の言語も歩んできた道だから…… 良いとは言わんけどなくてもめんどいんだよな。
139 :デフォルトの名無しさん :2024/02/27(火) 12:18:37.87 ID:Q3TDZDiV.net >>136 *selfはそれでいいけど、**selfはそれじゃ説明付かんぞ
140 :デフォルトの名無しさん :2024/02/27(火) 17:59:37.59 ID:KfBq61Mu.net >>139 &T→Tと同じでBox<T>に対する*演算子もコンパイラビルトインだからDerefのimplは使われない
141 :デフォルトの名無しさん :2024/02/27(火) 18:12:58.39 ID:lr8nToMg.net Rustってなんでzipを「簡単」に操作するクレートが一つもないんだ? Tauriがこなれてきたからそろそろ.NETからアプリをRustにポーティングしようかなと思ったらエコシステムがまるで成長していない・・・
142 :デフォルトの名無しさん :2024/02/27(火) 18:13:56.86 ID: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 :デフォルトの名無しさん :2024/02/27(火) 18:33:30.42 ID:p5E54fv2.net >>141 圧縮アーカイブならzipクレート 圧縮ならlibflateクレートなど
144 :デフォルトの名無しさん :2024/02/27(火) 19:01:36.79 ID:MCZ6xJKz.net >>133 > coercion 横から素人がすまん、これ何て読めばいいの?
145 :デフォルトの名無しさん :2024/02/27(火) 19:26:56.87 ID:kSGISY6y.net Rustもちょっと前の熱狂はなくなってしまった感じ 入込数が減ってると思う
146 :デフォルトの名無しさん :2024/02/27(火) 19:39:57.60 ID:ptyRkm62.net まあ熱狂系の人は実用言語嫌いそうだし、熱狂系がいなくなったのは良いことでは
147 :デフォルトの名無しさん :2024/02/27(火) 19:51:34.77 ID:gLAGJv50.net >>144 発音[US] kouə́ːrʒən | [UK] kouə́ːʃən カナ[US]コウアァジョン、[UK]コウアーション 参考:https://eow.alc.co.jp/search?q=coercion 自分はコアジョン派
148 :デフォルトの名無しさん :2024/02/27(火) 20:18:10.37 ID:p5E54fv2.net >>144 コアーション派
149 :デフォルトの名無しさん :2024/02/27(火) 20:23:00.40 ID:20aYglde.net >>147 サンクス。愛してる
150 :デフォルトの名無しさん :2024/02/27(火) 21:54:58.65 ID:Tx+RemT0.net Tのスマートポインタの参照 -> Tの参照 文字の配列の参照 -> 文字のスライス 一連の流れを見るとみんなポインタに熱狂している
151 :デフォルトの名無しさん :2024/02/27(火) 22:22:03.42 ID:TDjpaGuA.net >>150 そこはポインタと参照の根本的な違いを理解しできるかどうかかな 「Boxというスマートポインタ」の参照を扱うから意外に感じているのかもしれないが 「Boxというスマートポインタ」はヒープ領域の解放責任つまり所有権を持つ したがってBox自体を他の関数などへ渡してしまってはmoveしてしまい継続して使えなくなる だからスマートポインタの参照を渡すことになる 一見するとこれはポインタのポインタで無駄な間接参照に感じるかもしれない しかし参照=ポインタではなく参照は抽象的なものなのだ
152 :デフォルトの名無しさん :2024/02/27(火) 22:43:38.35 ID:NfALWDmT.net Rust の参照は借用規則に関わることを除けばポインタとそんなに差はないし普通にオブジェクトの一種なんだよな。 C++ の参照はオブジェクトではなく参照の参照もとれないし参照のポインタもないし、 参照のサイズも取得できないというのに比べたら Rust の参照は実体のあるものとして感じられてしまう。
153 :デフォルトの名無しさん :2024/02/27(火) 22:57:53.18 ID:FQe9Y4YD.net その橋渡し役がDeref coercion &Box<T>はそのままだとTのポインタを持つBoxへのポインタとなってしまうが Box<T>→TのDerefがあるため &Box<T>→&TとDeref coercionが適用できる 静的にコンパイル時点で行われるため実行時コストはかからない
154 :デフォルトの名無しさん :2024/02/27(火) 23:09:15.00 ID:xLBlGeUv.net >>142 この辺り最初理解するまで訳分からんかったな 理解すると大したことはないのだが
155 :デフォルトの名無しさん :2024/02/27(火) 23:37:04.57 ID:IkmURqSK.net >>142 >deref coreceは必ず参照から参照へのみ起きる &**との違いを認識してもらうための例を出したんだけど伝わらなかったみたいだね それは別にいいんだけど書いてる内容を見る限り Deref Coercionの動きを単に擬似的に再定義しようとして&**になると言ってるだけじゃなく 実際に&**が適用されると思ってるみたいに感じるね だとしたらそれは完全な間違い derefの実装の中で*演算子が使われることはあってもDeref Coercion自体は*演算子とは関係ないんだよ Boxのderef実装だって*演算子を使わずself.ptr.as_ref()的な実装で実現してもいいわけだし
156 :デフォルトの名無しさん :2024/02/27(火) 23:45:58.16 ID:Tx+RemT0.net とにかく、間接参照から直接参照を得る演算の名前はderefでいいんだよね
157 :デフォルトの名無しさん :2024/02/27(火) 23:58:10.03 ID: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 :デフォルトの名無しさん :2024/02/28(水) 00:29:07.11 ID:ZZ90UZAT.net >>157 とりあえずDerefの定義が pub trait Deref { type Target: ?Sized; // Required method fn deref(&self) -> &Self::Target; } (https://doc.rust-lang.org/std/ops/trait.Deref.html ) でderef()の戻り値には自動的に&がつくから *x: Box<T> *x: Vec<T> *x: String はDeref traitと関係ないことを抑えておこう そこに(by Deref…)を書かれると話がおかしくなる *Tができることの一部をDeref traitではできない 正確な表現かは分からないけどDerefは&の向こう側でしか*を適用できない
159 :デフォルトの名無しさん :2024/02/28(水) 00:41:03.68 ID: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 :デフォルトの名無しさん :2024/02/28(水) 00:49:10.38 ID:ZZ90UZAT.net なんかゲシュタルト崩壊してきたんだがw 関係ないけど微積のdxとかdyを思い出してしまった
161 :デフォルトの名無しさん :2024/02/28(水) 01:22:37.90 ID:0HAFGBLs.net C/C++書いてる者からすると勝手に変換してくれて楽ちんだなあって感じ
162 :デフォルトの名無しさん :2024/02/28(水) 01:32:01.63 ID:upo0sX/6.net Deref coercion &**のうち 右側の*は参照に対する参照外しで 左側の*はDerefで定義(実装)されてるものなのね
163 :デフォルトの名無しさん :2024/02/28(水) 04:46:46.07 ID: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 :デフォルトの名無しさん :2024/02/28(水) 11:30:56.58 ID:eNJqE6SH.net >>163 &&T→&Tのことを&T→Tとは書かないわな 前者の用途にDeref for &Tは存在してる
165 :デフォルトの名無しさん :2024/02/28(水) 17:44:48.30 ID: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 :デフォルトの名無しさん :2024/02/28(水) 18:08:21.49 ID:8fminEVJ.net なるほどね。勉強になるわ。
167 :デフォルトの名無しさん :2024/02/28(水) 18:17:32.89 ID:8gSKFNHr.net >>164 &&T→&Tの場合もreference用のビルトインderefが先に動いてDeref for &Tの実装コードは動いてない可能性ない?
168 :デフォルトの名無しさん :2024/02/28(水) 18:20:50.27 ID: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 :デフォルトの名無しさん :2024/02/28(水) 18:22:38.09 ID:nghz9NTX.net >>165 Deref T→Uが実装されている時に (つまり*TがUとなる時に) &T→&UのDeref coercionが自動適用される U=*T ↓ &Tから出発すると U=**(&T) ↓ 両辺の参照をとると &U=&**(&T) つまり Deref coercionとは&**の自動適用のこと
170 :デフォルトの名無しさん :2024/02/28(水) 18:49:11.26 ID:T3/1RdIi.net *xが左辺値なら代入、*xが右辺値なら複製とかいう演算に ビルトインderefみたいな名前をつけるのが間違っている
171 :デフォルトの名無しさん :2024/02/28(水) 19:13:20.58 ID:fjfA+uEG.net >>170 mutabilityを除けば左右どちらも同じ型だから形が同じであることは問題ない 左はmutabiltyが必要だからderefではなくderef_mutと区別されていてその点でも問題ない
172 :デフォルトの名無しさん :2024/02/28(水) 20:06:21.19 ID:ZLPgyFVM.net 判りにくい仕組みだけどこれから開発が進むと 文法変えたりするのかな?
173 :デフォルトの名無しさん :2024/02/28(水) 20:12:51.73 ID:eWXh2LH7.net これほど分かりやすくて便利な明確な仕組みはない 他の言語と比較すれば明らか
174 :デフォルトの名無しさん :2024/02/28(水) 21:00:40.37 ID:ZLPgyFVM.net これが分かりやすいと思ってる人間には聞いてないよ
175 :デフォルトの名無しさん :2024/02/28(水) 21:10:22.04 ID:RYfxXFlC.net 他の言語でこれより良いものが存在しないね RustのDeref ・自動適用されプログラマーの負担を軽減し利便性も良い ・魔法ではなくtrait Derefの実装に基づき動作して分かりやすく自作の型にも適用可能 ・コンパイル時に静的に解決され実行時の付加コストゼロで高速動作
176 :デフォルトの名無しさん :2024/02/28(水) 23:39:05.31 ID:T3/1RdIi.net >>172 Pythonが分かりやすいのは知ってるけど RustとPythonは両極端だから文法を微調整してもしょうがない 文法を変える必要があるのは両極端を否定する言語だけだ
177 :デフォルトの名無しさん :2024/02/28(水) 23:49:09.85 ID:ZZ90UZAT.net Derefなのに&が消えてない(小並感) 背景を理解しないと引っかかりやすいRustの七不思議候補
178 :デフォルトの名無しさん :2024/02/29(木) 01:04:43.74 ID:rccXx8PF.net この仕組みがベストであるという主張は3種類ある 一つは馬鹿な信者が言ってるだけという可能性 一つは本当にこの仕組みがベストである可能性 最後は信者ではないけど素直な馬鹿だからもっと良い仕組みを知らない可能性 このどれであるかは賢い人間がもっと良い仕組みを教えてあげると判別できる 馬鹿な反論が返ってきたら馬鹿な信者 合理的な反論が返ってきたら本当にこの仕組みがベストかもしれない 意見を翻されたら素直な馬鹿
179 :デフォルトの名無しさん :2024/02/29(木) 01:16:58.91 ID:s7mEAt1S.net この仕組みがない方が良いということ? 下手で全部書くべきと?
180 :デフォルトの名無しさん :2024/02/29(木) 01:51:37.80 ID:zTVrVDmh.net RustのDerefとそのcoercion枠組みの利点 ・プログラマーの負担が減る ・コードが見やすくなる ・枠組みはDerefトレイト利用で明白かつ汎用的になっている ・自分で作った型にも実装して作動させることができる ・静的に解決しているためミスしてもコンパイル時にわかる ・実行時に付加的な動作がなく高速に実行される これらの利点を上回る方法があるならば知りたい 既存の言語でも新規の方法でも
181 :デフォルトの名無しさん :2024/02/29(木) 03:43:48.10 ID:JSOAwYd/.net https://manishearth.github.io/blog/2017/01/10/rust-tidbits-box-is-special/ Boxのまほう
182 :デフォルトの名無しさん :2024/02/29(木) 10:19:46.23 ID:IetxPnTw.net >>179 >下手で全部書くべきと? どこかの方言?
183 :デフォルトの名無しさん :2024/02/29(木) 12:07:39.99 ID:/e0OxROz.net >>178 いずれにせよRust信者は自分の信仰を他人に押し付けるために検証可能性を潰すから、科学とはほど遠い姿勢かと。
184 :デフォルトの名無しさん :2024/02/29(木) 12:33:18.56 ID:sM99e4qp.net Rustの方式の利点は>>180 に挙げられているから もしRustより良い言語が存在するならば その方式およびRustの利点を上回る利点を挙げればいいんじゃね?
185 :デフォルトの名無しさん :2024/02/29(木) 12:41:20.92 ID:JSOAwYd/.net そんなに比較したいならワッチョイスレ行けばいいんじゃね? https://mevius.5ch.net/test/read.cgi/tech/1701997063
186 :デフォルトの名無しさん :2024/02/29(木) 13:11:40.55 ID:WGw1+Mi1.net 検証可能とはコンパイラが無謬であることではない ここが難しい コンパイラが未完成の状況でも人間が正解の一部をなぜか知っていること これが検証可能
187 :デフォルトの名無しさん :2024/02/29(木) 14:11:14.15 ID:s7mEAt1S.net >>182 この仕組みがない方が良いということ?
188 :デフォルトの名無しさん :2024/02/29(木) 14:14:12.31 ID:s7mEAt1S.net 単に理解できないから難癖つけてるだけだよねこの人 自分の主張も一切ないし
189 :デフォルトの名無しさん :2024/02/29(木) 14:15:14.41 ID:s7mEAt1S.net 誰かの難癖を自分が思い付いたかのように言ってるだけで 何一つまともな批判はない
190 :デフォルトの名無しさん :2024/02/29(木) 14:15:53.86 ID:s7mEAt1S.net 全く相手にすべき人間ではないと判断する よって今後無視する
191 :デフォルトの名無しさん :2024/02/29(木) 14:45:30.61 ID:NVSKcdtL.net >>184 それは「批判するなら代案出せ」と同じ議論を潰すだけの態度なのでやめよう 技術者なら自分が使っている道具の限界や弱点とは真摯に向き合うべき その際他の道具との比較も必須ではない
192 :デフォルトの名無しさん :2024/02/29(木) 14:51:42.06 ID:bXdMb/7T.net 技術的選択は突き詰めれば必ずトレードオフが生じるもの 利点だけを見て欠点に目をつぶったまま良し悪しを論じるのは愚の骨頂
193 :デフォルトの名無しさん :2024/02/29(木) 14:52:32.46 ID:sM99e4qp.net Rustの方式の利点は>>180 に挙げられているから もし仮にRustより良い言語が存在するならその言語の方式の利点を挙げればいいんじゃね?
194 :デフォルトの名無しさん :2024/02/29(木) 15:05:04.64 ID:Sa1lr1bM.net >>191 >それは「批判するなら代案出せ」と同じ議論を潰すだけの態度なのでやめよう 議論を潰すというよりも批判から逃げたいだけだろう
195 :デフォルトの名無しさん :2024/02/29(木) 17:17:49.66 ID:WGw1+Mi1.net 物的な代案や物的証拠により人の心を折ることが検証だと思っているんじゃないか
196 :デフォルトの名無しさん :2024/02/29(木) 17:44:22.90 ID:JSOAwYd/.net や、そもそも「人の心」の認識が無いのだろう
197 :デフォルトの名無しさん :2024/02/29(木) 18:01:07.55 ID:OWFCi11w.net わざわざRustスレにまでやって来てRust叩きやってる人だから心の病気なのかもな
198 :デフォルトの名無しさん :2024/02/29(木) 18:25:15.72 ID:uwbVoB9N.net >>167 >&&T→&Tの場合 これ調べてみたんだけどビルトインderefが優先的に動いて Deref for &Tの実装は使われてなかった
199 :デフォルトの名無しさん :2024/02/29(木) 18:37:38.45 ID:OsB1rmqt.net ビルトインは*を明示指定しないといけなくない? coercionは何も指定しなくてもDeref実装があれば自動的に多段に適用してくれるけど
200 :デフォルトの名無しさん :2024/02/29(木) 20:49:33.50 ID:NE3ms/ho.net impl Deref for &T はtrait境界を満たすためだけに定義されてるんだろうな 標準だとDeref境界はPinくらいしか使ってないけど
201 :デフォルトの名無しさん :2024/02/29(木) 23:55:24.58 ID:uwbVoB9N.net >>199 *演算子のときもDeref CoercionのときもビルトインderefがDeref::derefよりも優先して使われるよ
202 :デフォルトの名無しさん :2024/03/01(金) 08:46:23.47 ID: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 :デフォルトの名無しさん :2024/03/01(金) 09:18:59.78 ID:LWQ/+31h.net uv、めちゃ速いな 今までの処理時間はなんだったのか これはRustの印象を良くするツールになるわ
204 :デフォルトの名無しさん :2024/03/01(金) 10:14:36.96 ID:gvn/awFT.net uvというとCで書かれた非同期マルチプラットフォームライブラリ(Rustにはmioがある!)が有名だが そのuvはRust製のPythonパッケージマネージャーなのか
205 :デフォルトの名無しさん :2024/03/01(金) 11:06:37.60 ID:C9bgbnyF.net 速さの定義はわかりやすさの定義よりもわかりやすい
206 :デフォルトの名無しさん :2024/03/01(金) 16:15:12.75 ID:lzR4RBgp.net JavaScriptでも遅いBabelを速いSWC(Rust製)に換えると爆速
207 :デフォルトの名無しさん :2024/03/01(金) 19:02:46.24 ID:I+/u+ffT.net Pythonの管理ツールまたなんか出たの!?という気分
208 :デフォルトの名無しさん :2024/03/02(土) 00:14:54.94 ID:F+x2UUkM.net uvはPython版のcargoを目指しているらしい
209 :デフォルトの名無しさん :2024/03/02(土) 16:13:07.16 ID:bMlzFBHT.net nvidiaのど汚なさを理解してなさげで不安しかないわ
210 :デフォルトの名無しさん :2024/03/05(火) 04:09:58.03 ID:n3bQlkHC.net RustでDB使う時の定番ライブラリって何ですか?
211 :デフォルトの名無しさん :2024/03/05(火) 04:14:48.62 ID:nMHII26b.net ORMが好きならdiesel ORMが嫌いならsqlx
212 :デフォルトの名無しさん :2024/03/05(火) 06:15:07.43 ID:Uplx2IYd.net >>211 それRDBじゃん
213 :デフォルトの名無しさん :2024/03/05(火) 11:41:51.93 ID:6drsihdZ.net RDBじゃないDBの定番とか聞かんだろJK
214 :デフォルトの名無しさん :2024/03/05(火) 12:54:04.64 ID:iKkb/Eo4.net RDBMSが定番だからね。
215 :デフォルトの名無しさん :2024/03/05(火) 23:56:12.66 ID:blmx074I.net 最近RDB以外のDBの存在を知った人にありがちな反応だよな
216 :デフォルトの名無しさん :2024/03/07(木) 15:14:21.16 ID:/no0RfP4.net Rustで一通り文法や機能紹介した入門書の次に読むような定石本ってどのようなのがありますか?C++でいうEffective C++みたいな
217 :デフォルトの名無しさん :2024/03/07(木) 15:28:53.82 ID:5c4tHUTp.net しゃぶれよ
218 :デフォルトの名無しさん :2024/03/07(木) 17:13:51.21 ID:NLgNYFMG.net >>216 Rust for Rustaceans
219 :デフォルトの名無しさん :2024/03/10(日) 13:14:05.30 ID:XsimGsv7.net Rustはデフォルトのhashが遅いという罠
220 :デフォルトの名無しさん :2024/03/10(日) 20:35:08.28 ID:8NU5B5F+.net >>219 Rustはデフォルトのハッシュ関数が最強最善の暗号学的ハッシュ関数であるSipHashを採用しているため衝突にも強くハッシュDOS攻撃に対しても安全 もし強い衝突耐性を必要としない用途ならばFxHasherなどの速さ重視のハッシュへと簡単に置き換えられる type Hasher = std::hash::BuildHasherDefault<FxHasher>; let mut map = HashMap::<Foo, Hasher>::default();
221 :デフォルトの名無しさん :2024/03/10(日) 20:38:28.49 ID:8NU5B5F+.net こうね HashMap::<Key, Value, Hasher>
222 :デフォルトの名無しさん :2024/03/10(日) 21:21:36.22 ID:yMMzzxd+.net 解決案としてはそうなのだが、デフォルト挙動が罠すぎる デフォルトいらなかったのでは
223 :デフォルトの名無しさん :2024/03/10(日) 21:26:04.39 ID:hwVh1yHa.net Rustは利用者はアホだと思ってる だから徹底的に厳しくしてくる
224 :デフォルトの名無しさん :2024/03/10(日) 21:33:53.98 ID:hwVh1yHa.net 雨が降ってなくても傘を持つように言って来て外出すらさせてくれない
225 :デフォルトの名無しさん :2024/03/11(月) 00:11:06.91 ID:H3LWtGm6.net デフォルトのハッシュ関数が遅くて困るってことはよく知らずに使ってたってことでしょ? そう考えると初心者向けにデフォルト厳しくしておくのは正解な気がするわ、セキュリティに関わるし まあ言語側はそんな事考えずにとにかく一番スタンダードなものデフォルトにしろって考え方もわかるが
226 :デフォルトの名無しさん :2024/03/11(月) 00:47:18.65 ID:2r+51Qz1.net Rustはimpl std::hash::Hasherで必要なら自由に独自のハッシュ計算器をすぐ作れるし 逆にそれと独立にimpl std::hash::Hashで自分の各型に対してハッシュ計算法を指示できるし この2種類のトレイトを標準で用意してくれているRustは非常に好環境
227 :デフォルトの名無しさん :2024/03/11(月) 00:59:26.53 ID:lga6QF6v.net 「最悪の場合でもほどほど」なやつをデフォルトにするのは妥当だと俺も思う。 状況に合わせて選択できたり自分で作れたりする人はそうするんだから、 デフォルトではそうでない人を想定するだろ。
228 :デフォルトの名無しさん :2024/03/11(月) 02:43:53.87 ID:aDyedTxf.net いやそもそもデフォルトいらんくね? なんでデフォルト欲しいんだ?
229 :デフォルトの名無しさん :2024/03/11(月) 11:06:00.19 ID:WfvY/WS3.net 掃除機はAI搭載して吸ってはいけないものを吸ったら止まってくれよ
230 :デフォルトの名無しさん :2024/03/11(月) 11:06:34.84 ID:WfvY/WS3.net 誤爆した!
231 :デフォルトの名無しさん :2024/03/11(月) 14:30:36.32 ID:emAmKvKR.net デフォルトを用意するかしないかは言語思想によるから正解不正解では語れないよな rustの場合は何事も「安全」に基づいて設計されてると認識してる
232 :デフォルトの名無しさん :2024/03/11(月) 15:25:18.07 ID:WOvDUzj/.net 適切なハッシュ関数を選択するのってそんな簡単なことじゃないからな ハッシュ関数の特性だけじゃなくhashbrownの特性も知らないといけないしその両方を組み合わせた際のハッシュDoS耐性の程度も評価できないといけない HashMapのように基本的なデータ構造を使うのにどんな場合でもいちいちユーザーがその選択しなきゃいけないようだと辛すぎるわな
233 :デフォルトの名無しさん :2024/03/11(月) 19:01:47.22 ID:srElBTmD.net HashMapで使われるHashに重いものを使う必要がある局面は限られてる でも他人のライブラリの外から必要な時にハッシュアルゴリズムを変えることなんかできないので悩ましい人もいるだろう
234 :デフォルトの名無しさん :2024/03/11(月) 20:05:38.98 ID:3y0FGSJo.net 僕が美少女とセックスするためのプログラムはRustで作れますか
235 :デフォルトの名無しさん :2024/03/11(月) 21:13:52.07 ID:2r+51Qz1.net >>233 ライブラリを作成する時にその用途に応じた適切なハッシュを用いればよい 用途により異なるならば安全側に倒すか指定する方法を提供すればよい
236 :デフォルトの名無しさん :2024/03/11(月) 21:28:56.93 ID:vmVry2mm.net とりあえずデフォルトを使って、必要になったら差し替えればいいんじゃないの? Rustだとなんか問題あるんだっけ?
237 :デフォルトの名無しさん :2024/03/11(月) 21:31:16.84 ID:aDyedTxf.net >>236 ライブラリのハッシュを差し替えられない デフォルトハッシュを使うような人間がどんどん参戦してきてcratesの名前空間を埋め尽くしていく
238 :デフォルトの名無しさん :2024/03/11(月) 21:41:07.80 ID:6xtSsnXH.net ハッシュ衝突強度安全性が必要かどうかの判断ができない者がRustデフォルトの安全なものを用いることになるのは正しい そこまで必要としない用途であると判断できた者だけがFxHashなどを用いればいい RustコンパイラもFxHashを用いている https://github.com/rust-lang/rustc-hash
239 :デフォルトの名無しさん :2024/03/11(月) 21:44:11.78 ID:uBu+z/S9.net 安全で高速を名乗ってるくせにライブラリがおっせえ言語だなあ これ治すにはいちいち依存ライブラリ全てをcloneしてきてチマチマ変更していかないといけないってマジかよ
240 :デフォルトの名無しさん :2024/03/11(月) 22:02:54.43 ID:2hCRIQro.net 言語とは関係ない 外部からのデータを扱うなど攻撃耐性など必要となる部分には攻撃耐性のあるハッシュが必須 そうでない部分には攻撃耐性は必要ない 各プログラムの中にこれら両者はは共存しうる この使い分けができているかどうかは各言語の問題ではない
241 :デフォルトの名無しさん :2024/03/11(月) 22:17:15.26 ID:1Ss4PFRT.net ライブラリやその管理が言語と関係がないとする主張は可能だが、その主張をするとcargoやcratesの存在が言語と関係ないことになり、Rustの良さを支えている理由の大きな割合を失うことになる やはりエコシステムやそこにある資産も含めての言語の評価だろう それにユーザーの問題を言語が引き取らないのであればコードを書く人が充分賢いことを仮定することになり、C++で良いということになる
242 :デフォルトの名無しさん :2024/03/11(月) 22:22:30.50 ID:2hCRIQro.net >>241 C++だけでなくスクリプト言語であろうがすべて同じ 攻撃耐性が必要となるところで強度の高いものが使われてなければ欠陥プログラム
243 :デフォルトの名無しさん :2024/03/11(月) 22:24:26.89 ID:1Ss4PFRT.net >>242 だからデフォルトなんかいらないんだよ ハッシュごとき使うのにデフォルトがないと使えないような人間がcratesの名前空間を埋めていくのはヤバいよ
244 :デフォルトの名無しさん :2024/03/11(月) 22:32:51.13 ID:Zfy+Gd54.net >>243 ほとんどの言語の連想配列(hashmap)のハッシュ関数はデフォルトがありますよ 指定しないと使えない言語がもしあるとしてもレアじゃないですか?
245 :デフォルトの名無しさん :2024/03/11(月) 22:38:01.21 ID:1Ss4PFRT.net >>244 それはJavaScriptやPythonのような馬鹿がライブラリを書いて馬鹿が馬鹿の再生産をすることを推奨している言語の話でしょう? もしくは仕様だけ緩く決めて実装には何の責任も取らない言語か
246 :デフォルトの名無しさん :2024/03/11(月) 22:39:37.27 ID:1Ss4PFRT.net スクリプト言語だと速度は求められないという了解があるし
247 :デフォルトの名無しさん :2024/03/11(月) 22:53:49.00 ID:lga6QF6v.net Rust や C++ の思想でいう速さはゼロコスト抽象のことだよ。 抽象化にはコストはない (または十分に小さい) が実行すれば実行内容に相応の実行コストが生じるのは当たり前のことだし、実行内容を最小限にすることを目指したって単に不便になるだけだ。
248 :デフォルトの名無しさん :2024/03/11(月) 23:24:30.57 ID:pnxYU4a7.net あらゆる言語のあらゆるプログラムについて以下が成り立つ 【必須】信頼できない外部入力データに対しては攻撃に強いハッシュ関数を用いなければならない 【自由】そうでないデータに対してはどのハッシュ関数を用いてもよい この状況で安全な言語はデフォルトとして攻撃に強いハッシュ関数が適切 そして後者と判断できるプログラマーのためにハッシュ関数を指定できる仕様が適切 Rustはこの適切な仕様となっている
249 :デフォルトの名無しさん :2024/03/11(月) 23:26:28.61 ID:srElBTmD.net 雨の降らない日に傘をさしてるのがRust
250 :デフォルトの名無しさん :2024/03/11(月) 23:31:49.34 ID:srElBTmD.net 外に出るときはヘルメットを被って110をすでに入力したスマホを持ちながらおむつをしてコンドームつけてるのがRust
251 :デフォルトの名無しさん :2024/03/11(月) 23:39:22.87 ID:H3LWtGm6.net 雨が降る日のためにいつでも傘をさしてるだけだろ…
252 :デフォルトの名無しさん :2024/03/11(月) 23:47:29.47 ID:1gRl0SR3.net デフォルトとFxHasherで比較してみたけどHashMapへのinsertのみで実行時間1.7倍 現実のプログラムだとそれ以外の部分が大量にあるためそれ次第で誤差だね これはデフォルトが安全側に倒す形を取っていて正解と思う
253 :デフォルトの名無しさん :2024/03/11(月) 23:47:55.83 ID:eCeLdHKW.net >>248 >【自由】そうでないデータに対してはどのハッシュ関数を用いてもよい いやーそれはどうだろう? ハッシュDoS耐性は不要でも例えばFxHashを使うべきじゃないユースケースも普通にあるよね? stdに1つしかHasherが用意されておらずサードパーティ頼みな現状は言語的には結構不親切
254 :デフォルトの名無しさん :2024/03/11(月) 23:55:39.88 ID:srElBTmD.net hash自体は基本的にアホでも作れる それが適切なのかどうかは不明
255 :デフォルトの名無しさん :2024/03/11(月) 23:59:34.73 ID:o1bdd8gz.net Rustはデフォルトハッシュ関数が用意されていておかしいと言うけど すべての言語で用意されてるでしょ? Rustは様々なハッシュ関数が標準ライブラリにないと言うけど それが普通でしょ? さらにRustの標準ライブラリはなるべく小さくする方針ね
256 :デフォルトの名無しさん :2024/03/12(火) 00:02:16.02 ID:YqCvYydB.net >>255 ここまで読んでそういう解釈になってるなら理解する力が足りてない 重いハッシュ関数がデフォルトになってるのがどうなのかと言う話
257 :デフォルトの名無しさん :2024/03/12(火) 00:06:26.32 ID:hhdv8qp2.net 普通に考えて攻撃に強いハッシュ関数がデフォルトとなってるのがベストだよね 攻撃の可能性のない部分のみを後でチューンアップつまり弱いハッシュ関数で置き換えるだけだから これより良い策があるの?
258 :デフォルトの名無しさん :2024/03/12(火) 00:07:45.67 ID:YqCvYydB.net 攻撃の可能性のある部分をチューンナップ
259 :デフォルトの名無しさん :2024/03/12(火) 00:10:05.78 ID:hhdv8qp2.net >>258 バカなの? それだとチューンアップする前が攻撃耐性ないじゃん
260 :デフォルトの名無しさん :2024/03/12(火) 00:10:10.84 ID:YqCvYydB.net 江戸時代士農工商の身分制度があって 雨の日だけ農民も下駄を履いてよかった
261 :デフォルトの名無しさん :2024/03/12(火) 00:11:17.84 ID:YqCvYydB.net >>259 攻撃されないのに攻撃態勢をつける馬鹿
262 :デフォルトの名無しさん :2024/03/12(火) 00:13:45.61 ID:c71xUORt.net みんなの言語思想発表会をするのはいいけどRustをそれに巻き込むなよ
263 :デフォルトの名無しさん :2024/03/12(火) 00:15:25.47 ID:YqCvYydB.net IDコロコロ全肯定君 攻撃されるかもしれないのに攻撃の耐性をつけてない人に 対するフールプルーフのために一律全てのコードを遅くする そもそもその人が設計ミスってるんだろう
264 :デフォルトの名無しさん :2024/03/12(火) 00:15:58.38 ID:ltF5NefG.net SafeSlowHashMapみたいな名前にすれば良いのに
265 :デフォルトの名無しさん :2024/03/12(火) 00:16:19.18 ID:YqCvYydB.net >>264 少なくともこれかな
266 :デフォルトの名無しさん :2024/03/12(火) 00:27:26.16 ID:hEPMmb8p.net >>264 >>265 Rustを使ったことすらない人が文句を言ってるのか RustのHashMapはHasherに対しても多相であり型パラメータでHasherを指定する
267 :デフォルトの名無しさん :2024/03/12(火) 00:32:47.44 ID:YqCvYydB.net >>266 HashMap::new()すらしたことないのかな?
268 :デフォルトの名無しさん :2024/03/12(火) 00:33:47.12 ID:P8rBcnCc.net >>266 誰もそんな話してないやろ これだから複クンは
269 :デフォルトの名無しさん :2024/03/12(火) 00:35:30.45 ID:YqCvYydB.net こいつは結論が先にあってRustのすべてが正しいから後で理屈をつけているだけ いつもおかしなことを言ってる
270 :デフォルトの名無しさん :2024/03/12(火) 00:36:58.41 ID:4FnCuSr/.net ripgrepとかuvとかの既に実用が始まってるRust製アプリでは デフォルトのハッシュ関数使ってるの?
271 :デフォルトの名無しさん :2024/03/12(火) 01:00:19.76 ID:hEPMmb8p.net >>267 やっぱりRustを使ったことないんだな impl<K, V, S> HashMap<K, V, S>にfn new()は存在しないため HashMap::<Key, Value, BuildHasherDefault<Hasher>>::default()のように使う
272 :デフォルトの名無しさん :2024/03/12(火) 01:04:13.79 ID:YqCvYydB.net ほらこんな壊れたレスしかできないんだよ 脳が死んでる
273 :デフォルトの名無しさん :2024/03/12(火) 01:05:51.45 ID:YqCvYydB.net 常に論点ずらし 何の生産性もない
274 :デフォルトの名無しさん :2024/03/12(火) 01:42:25.91 ID:O5aTP+Ks.net いつもRustを叩いてRustスレを荒らしてるアンチの言動はいつもワンパターン 今回のHashMapの件で例えると もしデフォルトのハッシュ関数が安全でなく速いものだと「Rustはデフォルトが安全でない!」と叩く もしデフォルトのハッシュ関数が安全で遅いものだと「Rustはデフォルトが遅い!」と叩く どちらになっていても叩くことが目的のキチガイ
275 :デフォルトの名無しさん :2024/03/12(火) 09:25:30.86 ID:2ftxmqwc.net 「俺が高速なプログラムを作れるのは言語のおかげ」は合ってるが 「俺が低速なプログラムしか作れないのは言語のせい」は間違ってる
276 :デフォルトの名無しさん :2024/03/12(火) 15:42:43.44 ID:qP6Ph9LT.net 『「俺が低速なプログラムしか作れないのは言語のせい」は間違っている』という立場、ユーザーが充分賢いことを仮定しているのでそれならPythonとC++で良い
277 :デフォルトの名無しさん :2024/03/12(火) 16:02:50.20 ID:O51IPiXd.net ほんとどうでもいいな 自転車置き場というより豚小屋の議論
278 :デフォルトの名無しさん :2024/03/12(火) 16:28:46.76 ID:6k71yQCv.net プログラムしかしない人はこういうことしか考えることがないんよ
279 :デフォルトの名無しさん :2024/03/12(火) 17:33:47.15 ID:+dm3OZRm.net 知識があれば高速化が可能な場合があるのは、言語や項目に関わらず一般的な話。 安全方針のRustとしては、ハッシュ衝突強度を知らなくてもデフォルトで安全がベター。
280 :デフォルトの名無しさん :2024/03/12(火) 18:00:43.49 ID:ZUpYWJV7.net デフォルトいらんが ハッシュも自分で選べんガイジがハッシュマップ使うな
281 :デフォルトの名無しさん :2024/03/12(火) 18:49:06.95 ID:hIsWcrJS.net >>279 わかってなさそうなので再度書くけど ハッシュ衝突強度が高いからと言ってハッシュDoS耐性が高いとも限らないしHashMapに適してるとも限らないからね
282 :デフォルトの名無しさん :2024/03/12(火) 18:51:51.27 ID:wv71s4mp.net 弱いハッシュでも困るようなプログラム書く人は、自分で判断できるんじゃないの?デフォルトはパフォーマンス優先で良いと思うけどな。
283 :デフォルトの名無しさん :2024/03/12(火) 19:50:55.41 ID:WtXn1sYk.net 攻撃で困るかどうか攻撃されるまで初心者は判断できないと思う。 そして攻撃されてから対処するのでは遅いかもしれない。 パフォーマンスチューニングは遅いことが問題になってからやるので深刻ではなかろう。
284 :デフォルトの名無しさん :2024/03/12(火) 19:59:05.75 ID:1eKk9IjK.net >>283 同意
285 :デフォルトの名無しさん :2024/03/12(火) 20:00:13.63 ID:uVbV4a/I.net RustのDefaultHasherは安全かつパフォーマンスのいいSipHashを使っているので普通は気にする必要ない もちろんPythonやJavaScript(v8)やSwiftなど多くの言語がこのSipHashを使っている そのうえでRustは必要とするHashMap毎にFxHashなどさらに高速なものを簡単に指定できる
286 :デフォルトの名無しさん :2024/03/12(火) 20:49:08.64 ID:NxLZ8TT6.net Pythonはハッシュ値計算したらオブジェクトに保存してるでしょ
287 :デフォルトの名無しさん :2024/03/12(火) 20:49:29.65 ID:+yrdVDIt.net 他の言語たちがRustを参考に同じように後追いしているのね >Pythonの文字列やバイト列に対するハッシュアルゴリズムは、HashDoS対策としてPython 3.4から SipHash24が使われていました。 >その後、ラウンド数を減らしたSipHash13でも十分に安全だとして2015年にRustが、2016年にRubyが、SipHash24からSipHash13への切り替えを行いました。 >Rust や Ruby からは数年遅れましたが、Pythonもデフォルトの文字列ハッシュアルゴリズムがSipHash13に切り替わりました。
288 :デフォルトの名無しさん :2024/03/12(火) 20:56:37.07 ID:Bo/PtDeL.net >>286 常にそれをされたら困るが Rustでもハッシュ値をオブジェクトに持つstring_cacheなどが用途に応じて使われている
289 :デフォルトの名無しさん :2024/03/12(火) 22:08:56.94 ID:qGjx1B49.net >>274 人にキチガイと言う前に自分の脳を使って考えたら? どちらになっても叩くことはないだろ 他の言語はデフォルトで速いハッシュを使ってるよ
290 :デフォルトの名無しさん :2024/03/12(火) 22:13:42.86 ID:qGjx1B49.net Python Ruby スクリプト系言語
291 :デフォルトの名無しさん :2024/03/12(火) 22:30:53.75 ID:QLhbtBPI.net 他の言語もRustと同じハッシュ関数を用いていることが判明したのにRust叩きを続ける一匹
292 :デフォルトの名無しさん :2024/03/13(水) 01:06:52.67 ID:l12NsVZP.net 他の言語の例としてPythonやRubyのような遅いこと前提でとにかく初心者が書いても動けば良いという思想の言語を持ち出してくるのはおかしいでしょう
293 :デフォルトの名無しさん :2024/03/13(水) 01:36:16.81 ID:yq4Sx3eg.net Swiftも同じSipHash13だよ
294 :デフォルトの名無しさん :2024/03/13(水) 06:48:44.81 ID:vtWyM3VT.net >>292 じゃあRustの思想は?
295 :デフォルトの名無しさん :2024/03/13(水) 07:26:54.50 ID:W15vpPlq.net >>283 判断できない人まで言語側で救う必要性が分からない。 それなら、unsafeもカジュアルに使えないように仕掛けを用意した方が良いんじゃないかと。
296 :デフォルトの名無しさん :2024/03/13(水) 08:05:27.17 ID:7ftIQ2tM.net 必要なことしかやりませんって言語は他にあるからそちら使えばいいのでは?
297 :デフォルトの名無しさん :2024/03/13(水) 11:53:59.71 ID:k71lJTPU.net 安全と速度は両立するかそれともトレードオフか トレードしかしない人にとって、コストは支払うと決めたら絶対にキャンセルできない印象があるよね 有償かと思ったけどよく考えたらやっぱゼロコストだったという現象は許せない
298 :デフォルトの名無しさん :2024/03/13(水) 13:08:21.45 ID:zcdQDtji.net Rustなんかに手を出すのはC++まともに書けない馬鹿なんだから、「充分賢ければ速く書ける」は実質「速く書けない」なんだよな 賢いならRustなんかやらない
299 :デフォルトの名無しさん :2024/03/13(水) 13:52:10.04 ID:k71lJTPU.net 自由があればデフォルト設定を強制されないのは自明な事実 ただし、賢い人間が自由を所有しているのか、道具自体が自由度を持っているのか そもそも「所有している」というのはただの感想なのか客観的事実なのか
300 :デフォルトの名無しさん :2024/03/13(水) 15:08:41.44 ID:EtYMYlMl.net アホ vs バカの不毛な争いが続くのは隔離スレにワッチョイつけたやつの責任だからな
301 :デフォルトの名無しさん :2024/03/13(水) 17:12:52.60 ID:2jYqKDsd.net 本スレにワッチョイつけず隔離スレと称して余計なスレ立ててそっちにワッチョイつけるバカども。 5chでRust使ってるって言ってるやつらはそんなもの
302 :デフォルトの名無しさん :2024/03/13(水) 17:32:48.34 ID:k71lJTPU.net 不毛の判断が早いなあ 後世の歴史家が判断するという定型文に縛られないから早いんだな
303 :デフォルトの名無しさん :2024/03/13(水) 17:40:34.76 ID:EfEhvhMh.net 安全と速度を両立させたのが RustやPythonなどが採用しているSipHash13
304 :デフォルトの名無しさん :2024/03/13(水) 18:38:09.42 ID:9N462qty.net >>295 いや、unsafeは判断できる人が使うものだろ。
305 :デフォルトの名無しさん :2024/03/13(水) 21:22:31.53 ID:cNV/vVTe.net >>300 分かってるんならワッチョイ付きRustスレの盛り上げに協力してくれんかえ
306 :デフォルトの名無しさん :2024/03/13(水) 21:54:19.69 ID:Ay/UTMuM.net ワッチョイなんか盛り上がる訳ねえ そんな話題あったらこのスレに投下してつまらない議論を流した方が余程生産的
307 :デフォルトの名無しさん :2024/03/13(水) 22:31:42.96 ID:/twoPXVD.net 高齢化でコーディングできなくなったおじいさんを叩くのは良くないと言う話
308 :デフォルトの名無しさん :2024/03/13(水) 22:39:35.15 ID:vtWyM3VT.net 30後半でコーディングしてるやつなんて9割コミュ障で出世できなかったやつだろ
309 :デフォルトの名無しさん :2024/03/13(水) 22:42:16.17 ID:6IE1D2aF.net 出世出来ましたか?
310 :デフォルトの名無しさん :2024/03/13(水) 22:52:25.45 ID:/twoPXVD.net 能力が低下してコーディングできないのとしないのでは大違い
311 :デフォルトの名無しさん :2024/03/14(木) 00:41:25.89 ID:2hurvpo9.net 結局スクリプト言語で書かれた原作が必要か 他のジャンルでも原作なしのオリジナルは難しそうだろう
312 :デフォルトの名無しさん :2024/03/14(木) 12:30:54.13 ID:HuCxvvOv.net Rustで書き直してパフォーマンスが上がったので注目浴びる!みたいなプロダクトはなんか白けるよな。 JSとかPythonの基盤ツールをRustで書き換えて激速!みたいなのはもう汎用言語としてのアイデンティティ捨てられててオワットル。
313 :デフォルトの名無しさん :2024/03/14(木) 12:34:38.63 ID:GaNa4vYx.net 日本みたいに、何とかするには人投入しよう!スキルどうでもいいからとにかく人集めて!なところじゃね~。
314 :デフォルトの名無しさん :2024/03/14(木) 13:45:31.80 ID:zTrHTca+.net おそらく植山類が新しいリンカを作ったあたりが開発ツール高速化の機運の始まりだと思う。 歴史的事情でごちゃごちゃしてて遅いのが仕方がないと思われていたものについて 速度を意識して書いてみたら数百倍単位で速くなってわひゃーーというのが強烈なインパクトだった。 (それは C++ で書かれてるんだけどね。) 商売で開発ツールを提供している会社にとっては少なくともそれと同程度のものを出さないと面子が立たない。 リンカを作ってるところはこぞって高速化に努めた。 リンカ以外にもその機運が波及しているのが今。 で、高速化のキモはデータ構造であるというのが明瞭になったんだけど メモリ管理の部分を処理系 (ランタイムサポート) の側でやるようなものだとそこんところのチューニングが出来ない。 Rust である必然性が強いわけではないけど C++ とかよりは今なら Rust のほうがいいかなってのはまあ自然な判断ではある。
315 :デフォルトの名無しさん :2024/03/15(金) 00:47:31.57 ID:eu7fnAy5.net コードを書けない プログラムできなくなるとこういうことしか書けなくなると言う見本
316 :デフォルトの名無しさん :2024/03/15(金) 10:43:30.71 ID:5CgUbd5q.net だが読むより書くほうが優れているという前提から 原作を正しく読解するよりも正しくない二次創作のほうが優れているという結論が出てくる
317 :デフォルトの名無しさん :2024/03/15(金) 11:53:24.75 ID:94MXVgRN.net 春だなぁw
318 :デフォルトの名無しさん :2024/03/15(金) 18:26:51.96 ID:5N0PtL1J.net ai bot
319 :デフォルトの名無しさん :2024/03/15(金) 20:40:42.93 ID:W8LQpOAr.net >>315 辛辣で草 そういう似非技術者系おじいちゃんおちょくると 怒って自分が唯一知ってる知識振り回してくるから面白いぞ
320 :デフォルトの名無しさん :2024/03/15(金) 21:07:06.30 ID:8+Y0uCh5.net Rustコードを書けない似非技術者系おじいちゃんたちは他のスレでやりとりしなさい ここはRust専用スレ
321 :デフォルトの名無しさん :2024/03/15(金) 21:26:31.60 ID:PnOJWcC7.net コーディングが出来なくなると人生はつらいと思うけどな…
322 :デフォルトの名無しさん :2024/03/15(金) 21:36:49.30 ID:3GkeGGWK.net できなくなるんじゃなくて 元々できてないんよね>>314 みたいな人は というより単に職業マじゃないのかもな 趣味でプログラム触ったことあるパソコン少年的な
323 :デフォルトの名無しさん :2024/03/16(土) 00:23:32.44 ID:/iia2JvS.net 人はいつか何もできなくなって死んでいくんだよな つまらないね
324 :デフォルトの名無しさん :2024/03/16(土) 08:54:22.01 ID:aeWu0EgX.net 肉屋がレッドオーシャンになれば豚はブルーだからこれでいい
325 :デフォルトの名無しさん :2024/03/17(日) 19:33:58.02 ID:1VtyMVPz.net Rust書けるやつ集めるの大変すぎ
326 :デフォルトの名無しさん :2024/03/17(日) 22:06:35.75 ID:BMZldfUE.net Rustで書けば速くてリソースコスト下げられるうえに保守性も良くていいことずくめだからだな ただしまともなプログラマーしか使い こなせない
327 :デフォルトの名無しさん :2024/03/18(月) 09:59:50.17 ID:ySp1yGcK.net むしろ変なやつしか使ってない感じだけど…
328 :デフォルトの名無しさん :2024/03/18(月) 10:20:48.83 ID:JObkxwF0.net しょーもないこだわり持ってるやつしか使ってない
329 :デフォルトの名無しさん :2024/03/18(月) 13:49:12.09 ID:lCCxn1Q7.net 今後の仕事考えたらRustだね
330 :デフォルトの名無しさん :2024/03/18(月) 14:26:36.03 ID:1+ObkRXf.net メモリ安全性ってなんなの?
331 :デフォルトの名無しさん :2024/03/18(月) 14:49:59.91 ID:RRSB5dTk.net 無効なアドレスを参照しない 運が良ければSegmentation Fault、運が悪ければ変な値が使われて何か起こる 無効なアドレスを更新しない 運が良ければSegmentation Fault、運が悪ければそこの値が壊れて何か起こる メモリリークは割とどうでもいい
332 :デフォルトの名無しさん :2024/03/18(月) 15:00:45.39 ID:ZJ4hMg34.net >>330 メモリ安全性のうち特に重要な一つがメモリ競合の安全性 まだ使っている値を意図せずに書き換えてしまい矛盾してしまう プログラミングで起こるバグの代表的な一つ Rustではこれを防ぐことができる
333 :デフォルトの名無しさん :2024/03/18(月) 15:02:35.53 ID:1+ObkRXf.net >>331 ありがとう 「運が悪ければ変な値が使われて何か起こる」 そういえばメモリの概念理解せずにC言語使って、動かすたびに結果がかわるバグプログラム生み出してビビリ倒したことを思い出しました……
334 :デフォルトの名無しさん :2024/03/18(月) 15:07:28.37 ID:1+ObkRXf.net >>332 ありがとう 「運が悪ければ変な値が使われて何か起こる」 そういえばC言語の現在時刻取得関数がポインタ返し&参照先書き換えるタイプの関数だったので大ハマリしたことありますね…
335 :デフォルトの名無しさん :2024/03/18(月) 18:35:36.34 ID:utey1W8X.net セルフコントならもう少し面白いやつを頼む
336 :デフォルトの名無しさん :2024/03/20(水) 01:19:02.24 ID:6E76csi8.net WebAssemblyバイナリの実行環境を提供する「Rust」で作成されたランタイム「Wasmi」に脆弱性が明らかになった。 ttps://www.security-next.com/154875
337 :デフォルトの名無しさん :2024/03/20(水) 05:37:59.51 ID:wTR4SIFK.net デフォルトで制限よりも多くのパラメーターを指定すると域外に書き込みを行うおそれがある「CVE-2024-28123」が明らかとなった。 2023年12月にリリースされた「同0.31.1」にて脆弱性は修正された。 パラメーターが128個以下であることを確認する回避策についてもアナウンスしている。
338 :デフォルトの名無しさん :2024/03/20(水) 12:50:32.15 ID:/slJg93x.net >>336 そういうのRust関係ないからわざわざここに書かなくてもいいよ
339 :デフォルトの名無しさん :2024/03/20(水) 13:00:27.22 ID:3fTCja3E.net 関係無いわけないでしょw rustで書かれてたら安全なんじゃなかったん?w
340 :デフォルトの名無しさん :2024/03/20(水) 13:48:07.28 ID:i9d3tzeg.net ガベージコレクションのあるスクリプト言語であるPythonですら脆弱性でCVE出まくってるよ
341 :デフォルトの名無しさん :2024/03/20(水) 14:22:40.25 ID:HLjoI2yW.net これは「メモリ安全」の外の話?中の話?
342 :デフォルトの名無しさん :2024/03/20(水) 16:11:18.74 ID:sC/F3tDJ.net unsafe使用箇所だからメモリ安全の外だろうな インタプリタのスタックフレーム参照で毎回境界チェックする実装も微妙だししゃーない
343 :デフォルトの名無しさん :2024/03/20(水) 16:33:56.60 ID:pz7pPV/0.net jsonの方も?
344 :デフォルトの名無しさん :2024/03/20(水) 17:50:49.65 ID:w9jt/Hdz.net コード見てみたが言語関係なくダメな書き方の見本ってだけだな ttps://github.com/wasmi-labs/wasmi/commit/f7b3200e9f3dc9e2cbca966cb255c228453c792f ttps://github.com/wasmi-labs/wasmi/blob/v0.31.0/crates/wasmi/src/engine/stack/values/mod.rs#L158-L163 修正コードは毎回境界チェックしてるのと同じ extendする前に必ずreserve呼ばなければいけないとか反省の色が見られない
345 :デフォルトの名無しさん :2024/03/20(水) 18:13:46.74 ID:ASk8Mk2n.net extendという名前も実体と違ってバクの素
346 :デフォルトの名無しさん :2024/03/20(水) 18:19:15.64 ID:sC/F3tDJ.net 修正コードはhotfixでしょ masterブランチの方は結構手が入ってると思う
347 :デフォルトの名無しさん :2024/03/20(水) 18:27:22.61 ID:ihbrcjwp.net その知識やスキルを活かして出世して欲しい
348 :デフォルトの名無しさん :2024/03/20(水) 20:04:41.25 ID:TrbgWl+Z.net ダメな書き方でもコンパイルが通れば安全なはずなのではw
349 :デフォルトの名無しさん :2024/03/20(水) 20:32:22.01 ID:sC/F3tDJ.net んなこたない ダメなunsafeの使い方すれば安全じゃなくてもコンパイルは通せる
350 :デフォルトの名無しさん :2024/03/21(木) 01:05:26.83 ID: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) } }
351 :デフォルトの名無しさん :2024/03/21(木) 01:39:19.40 ID:t5wrhqh7.net >>350 俺んとこもそのコードはよく書くけれど 今回の敗因は引数のindexが生のusizeであること そこをusize直接ではなくそのラッピングの専用型にする そしてその専用型が動く範囲が必ず範囲内であることを保証する形で get_uncheckefのunsafeを使う関数をsafeに仕上げる
352 :デフォルトの名無しさん :2024/03/21(木) 19:05:54.93 ID:QWnK+qvS.net unsafeを適切に使えないプログラマが書くと全然安全じゃないという事?
353 :デフォルトの名無しさん :2024/03/21(木) 19:57:12.18 ID:7RDAu5V5.net 全然そういう事 Rustで無闇にunsafeを使うのは日本語で無闇に「全然」を使うくらいやばい
354 :デフォルトの名無しさん :2024/03/21(木) 20:09:58.67 ID:gM/gTjZ5.net >>353 それ言うなら 無闇に「ヤバい」を使うぐらいヤバい じゃね
355 :デフォルトの名無しさん :2024/03/21(木) 20:26:53.11 ID:1l7zk65j.net 俺はむやみに「全然」とか「ヤバい」を使ってるけどトラブルになったことはないな ガンガンunsafe使ってこーぜ!!
356 :デフォルトの名無しさん :2024/03/21(木) 20:28:39.30 ID:7RDAu5V5.net >>354 それだと単なる自己言及だから352に対する答えとして不十分では
357 :デフォルトの名無しさん :2024/03/21(木) 20:45:04.06 ID:t5wrhqh7.net 少なくとも>>350 のindex: usizeは 何らかラッピング { index: usize }と別型にすべきところ まず範囲外のusizeでうっかり使っても型エラーにできる そしてラッピング型の動作が必ず範囲内に収まるコードであることを注視するだけで安全性を保証できる
358 :デフォルトの名無しさん :2024/03/21(木) 21:05:14.02 ID:7RDAu5V5.net NonZeroとかNonNullみたいな固定条件ならいいけど 範囲みたいな可変条件だと型だけじゃ厳しいでしょ 別の条件で作られた同じ型の値を使われるかもしれないし ライフタイムで条件と関連付けるのも限界がある 結局テストパターン増やしてdebug_assert踏むしかない
359 :デフォルトの名無しさん :2024/03/21(木) 21:44:37.76 ID:t5wrhqh7.net >>358 もちろん二段階 まずは専用型にすることで管轄外のusize indexがうっかり混じるのを型エラーで確実に避ける 次にコーディングやレビューやメンテでその専用型の動きに注視できる
360 :デフォルトの名無しさん :2024/03/21(木) 22:18:44.86 ID:cOunjWn7.net unsafeをsafeでないのにsafeにしておいて ある型が使い方によってはunsafeになるかもしれないから注視しろってのはちょっとキツイです
361 :デフォルトの名無しさん :2024/03/21(木) 22:27:42.27 ID:WuGieKPN.net 結局プログラマが色々意識してコーディングしないと安全にはならないのね こういうのもコンパイラがエラーにしてくれてそれを直していけば安全になるものだと思ってたんですけど
362 :デフォルトの名無しさん :2024/03/21(木) 23:07:15.31 ID:7RDAu5V5.net unsafeに手を出さなければ最悪でも暴走する前にpanicで停止する安全性は確保できる 実際は安全の為でもpanicで止まると困るから色々注意しないといけないし unsafeで余計なチェック省いたり黒魔術使ったりもする Rustの安全性のサポートは選択と集中がしやすくなる程度で万能ではない
363 :デフォルトの名無しさん :2024/03/21(木) 23:12:07.53 ID:v/mpoJJ8.net >>361 unsafeを使わなれば自動的に安全が保証される unsafeを使うならその関連箇所に人間による安全保証が必要、それ以外は自動的に安全が保証される C/C++はすべてのコードがunsafe状態なので自動的に安全が保証されるところがない
364 :デフォルトの名無しさん :2024/03/21(木) 23:22:25.34 ID:WuGieKPN.net いつもの人がきたw 結局レベルの低い人が書くとunsafeも不適切に使われて今回のように脆弱性が出てしまうでしょ Rustであれば安全と思ってる人が多そうなのでかえってunsafeによる脆弱性が見落とされたり発覚しにくくなって問題だと思うんですけど
365 :デフォルトの名無しさん :2024/03/21(木) 23:58:23.31 ID:z414Bs3I.net > Rustであれば安全と思ってる人が多そう いや一応言っとくけど多くはないよ流石にw 一部の人が連呼してるだけ ほかの人はもっと現実的だろな
366 :デフォルトの名無しさん :2024/03/21(木) 23:59:21.08 ID:t5wrhqh7.net 原則はunsafeを使うな! これだけだ 理解できていてunsafeを使う場合も とにかく閉じ込めろ! 専用のクレートを作れ 専用のモジュールを作れ 専用の型を作れ
367 :デフォルトの名無しさん :2024/03/21(木) 23:59:51.15 ID:XJ9dJAV6.net unsafe使わなければ安全
368 :デフォルトの名無しさん :2024/03/22(金) 09:16:28.77 ID:IQ7X1X+j.net まあ実際rustはコンパイル通ればいいの思想を強める傾向にはある。 それは意識して気をつけた方がいい。
369 :デフォルトの名無しさん :2024/03/22(金) 10:19:34.77 ID:avPqaarP.net ロジックや言語仕様を考えずにコンパイルが通るまでひたすらいじくり回すタイプの人間は本当にいる。 チュートリアルすら読まずに書き始めてなんもわからんから教えてと質問サイトに投稿しちゃうやつはいる。 そういうやつは早めに脱落して欲しいし大抵は脱落していくんだけどどういうわけか生き残ってあらゆるところをワヤにしていく狂人がたまにいるんだよ…… 普通に現実を見ながらちゃんと学べる人なら (たまにはミスることもあるだろうけど) 大丈夫だよ。
370 :デフォルトの名無しさん :2024/03/22(金) 11:58:26.79 ID:7Rs7masV.net >>358 0〜127の範囲のみを取りうるようなEnumなら作れる wasmiの例のように実行時にバッファサイズが変動するなら無意味だけど サイズが変動する場合はget_uncheckedに必要な安全性の保証をsafe wrapperの中でやるのが基本 それができないならunsafeのままにして上位で安全性を保証させるようにしないといけない >>359 のやり方はそれができてないように感じる
371 :デフォルトの名無しさん :2024/03/22(金) 12:34:01.41 ID:TbCMvv+/.net 実行時に範囲が変動するといっても制御下にあるのだからindexがその範囲にある時のみ有効な型を実装すればよい そうすればその型に対して常に安全にget_uncheckedを使える
372 :デフォルトの名無しさん :2024/03/22(金) 14:04:42.65 ID:ZrfX32kv.net Rustは失敗言語
373 :デフォルトの名無しさん :2024/03/22(金) 14:10:55.04 ID:ceR9yHkM.net 今回の件でRustの安全性が確実になったのが興味深いよな アンチが必死に探してきた問題も>>350 でunsafe利用だった
374 :デフォルトの名無しさん :2024/03/22(金) 16:00:31.63 ID:JqYXTM4B.net >>371 「indexがその範囲にある時のみ有効な型」の意味がよく分かってないけど 実行時に型の方でindex検査して無効時にpanic起こすなら普通にusizeでgetしてunwrapしようよ unsafeにする意味がない
375 :デフォルトの名無しさん :2024/03/22(金) 17:14:19.13 ID:vuLWDWdh.net >>374 実行時コストをかけないためにget_uncheckedを使うのが一般的 その代わりロジックでindexが範囲内であることを保証する(ことがてきる時に使われる汎用的な手法)
376 :デフォルトの名無しさん :2024/03/22(金) 19:27:28.32 ID:G6tKD1fj.net Adaなら特定の範囲の型作れるみたいよ
377 :デフォルトの名無しさん :2024/03/22(金) 20:07:18.97 ID:vuLWDWdh.net 今回は範囲が固定ではなく変わり得る
378 :デフォルトの名無しさん :2024/03/23(土) 23:29:45.64 ID:eeq00BcS.net 誰にでもunsafeが使えてしまうのが問題なのでは? 原則使えないくらいが、バカでも安全になるからRustの方向性に合ってる気がする。
379 :デフォルトの名無しさん :2024/03/24(日) 00:34:36.37 ID:iaJ2USO3.net Rust の制限は機械的に検証可能な範囲に絞ったらそうなったということであって、その制限の範囲内で十分にプログラムが書けるというものでもない。 まあ思ったよりも足りるけどやっぱり必要だから unsafe はある。
380 :デフォルトの名無しさん :2024/03/24(日) 10:55:06.56 ID:UXqlkypu.net >>375 「indexがその範囲にある時のみ有効な型」でも有効範囲が実行時に変動するなら>>350 の引数のindexをその型に変えたところでsafeにしたらダメだよ
381 :デフォルトの名無しさん :2024/03/24(日) 11:08:34.82 ID:BHU0SFkf.net なるほど、欲しい機能を実装していったら、結構安全になったって感じなのかな。OpenBSDみたいな偏執なのとは違う感じか?
382 :デフォルトの名無しさん :2024/03/24(日) 11:48:11.45 ID:uu8/yG2s.net indexの境界チェックが律速になるようなコード書いてみてえな
383 :デフォルトの名無しさん :2024/03/24(日) 20:37:14.59 ID:YsO86RjG.net >>376 型宣言の時に type My_Int is range -1 .. 5; 範囲宣言(マイナスでも、1からでもOK)できて、範囲を越えたらエラー 配列もその範囲指定で自由に作成できる。
384 :デフォルトの名無しさん :2024/03/24(日) 20:45:58.90 ID:Rrl8qRWO.net >>383 定数じゃなければ結局実行時にチェックするってことだよね
385 :デフォルトの名無しさん :2024/03/25(月) 01:12:47.74 ID:yMlw6u5B.net >>384 新しい型はint型とは独立した型なんだから変数にしたってその新しい型じゃないとコンパイル時にエラー。
386 :デフォルトの名無しさん :2024/03/25(月) 07:21:41.59 ID:CNajD+3j.net >>384 何十年も前なのですまそ array(-2)とかarray(6)をアクセスしたら例外発生 array(-1)はOK type Month is range 1..12 type Month_Array is array(Month) of Integer; ma : Month_Array := (1,2,3,4,5,6,7,8,9,10,11,12); for m in ma'first..ma'last loop // カウンタは1から12 ma(m) = m; end loop;
387 :デフォルトの名無しさん :2024/03/25(月) 14:37:28.19 ID:x/lXcXel.net 今回の話は実行時境界チェックを無くす(減らす)実行時コスト削減の話だけど そのAdaの例だと実行時に範囲外に値が動けてアクセスで例外発生するから何の解決にもなっていないね
388 :デフォルトの名無しさん :2024/03/25(月) 16:23:44.40 ID:9GDk/VLW.net How much does Rust's bounds checking actually cost? https://blog.readyset.io/bounds-checks/
389 :デフォルトの名無しさん :2024/03/25(月) 17:27:16.04 ID:MT/jL+52.net こんなもんjavaの速度低下が境界値チェックによるものじゃないってことで話は終わっとると思ったけどな。 問題は浮動小数の取り扱いだっての。
390 :デフォルトの名無しさん :2024/03/25(月) 21:23:48.62 ID:x/lXcXel.net unsafeは可能な限り避けるべきで safe Rustでの改善をまずすべき その次にindex checkの有無で意味のあるパフォ向上がある時のみ考える 現実にはsafe Rustでの改善ができてないことが多い 例えばよく見かける例としては iが動いていくのにa[i]でアクセスしてしまう これはiの範囲checkとa[i]の範囲checkで二重checkになるbad pattern 参照(ポインタ)化することで範囲checkを1回に減らせる
391 :デフォルトの名無しさん :2024/03/27(水) 15:06:55.14 ID:g9hYSxJr.net unsafeは極力避けろというアドバイスばっかりでunsafeを適切に閉じ込める基本的な考え方や実装パターンの啓蒙が不十分なんだよね unsafeを良く知れば知るほど自然と避けるようになるから避けろ避けろと言うよりもunsafeに関する知識を深められるようにする方が大事
392 :デフォルトの名無しさん :2024/03/27(水) 15:29:03.70 ID:pFQTMi8v.net 「unsafeの閉じ込めにはセンスがいるから、教えてもらわないと出来ないやつはunsafeを使うな」 が言える限界な気がする。現にunsafeを適切に閉じ込めるためのノウハウを継承できる資料とかがないので
393 :デフォルトの名無しさん :2024/03/27(水) 16:02:47.08 ID:BwG0n/Az.net unsafeはライブラリ作者とかがハード周りアクセスするために使うもので、コーダーが使うものじゃないだろ。 unsafe可能ソースファイル用の拡張子を別途用意して、rsファイルはunsafe禁止にしてもいいくらいじゃない?
394 :デフォルトの名無しさん :2024/03/27(水) 16:59:36.71 ID:LwoOYerE.net >>393 そしたら全部を unsafe 可能版で書いちゃうのが世の中の現実ってもんなんだよ。
395 :デフォルトの名無しさん :2024/03/27(水) 17:05:39.09 ID:6Vj8sISV.net >>392 センスの問題ではないと思うが仮にセンスが必要だとしてもセンスがあるやつが適切に閉じ込めた事例とダメな事例を類型化してパターンナレッジとして浸透させればいいだけ 今はそれが全然できてないから>>350 のような基本的なミスを犯すやつが後を絶たない
396 :デフォルトの名無しさん :2024/03/27(水) 17:08:09.55 ID:6japDZ8y.net windows-rs とか使うと絶望するよな。もうちょいラップして安全なAPIも提供してほしい。
397 :デフォルトの名無しさん :2024/03/27(水) 18:09:17.85 ID:345wycOn.net >>395 ~すればいいだけって言う奴はたいてい本人はやらないんだよなぁ。
398 :デフォルトの名無しさん :2024/03/27(水) 18:27:03.05 ID:3NgGdhlw.net >>397 問題点の指摘や解決策の提案と 問題解決のために実際に誰が動くのかという 2つの異なるものを混同したらだめだよ マネジメント101
399 :デフォルトの名無しさん :2024/03/27(水) 18:54:43.86 ID:nHNmKGrp.net その素晴らしい提案がなぜされていないのか考えよう そしてなぜ自分は実行から逃げているのか考えよう
400 :デフォルトの名無しさん :2024/03/27(水) 20:42:45.86 ID:deTzlgug.net >>394 Rustが流行りそうな一番の理由は「管理側」が「コーダー」にunsafeみたいなことをやらせたくないということなんだから、どこでもunsafeとか管理側が許さんだろ。
401 :デフォルトの名無しさん :2024/03/27(水) 21:06:58.89 ID:LwoOYerE.net unsafe はコンパイラが安全性を「論理的に検証できない」部分であって、理論上の都合で出来た区分だよ。 危険な操作も含まれるけど危険な部分を分けれてるわけではない。 もちろん unsafe を制限する規約のプロジェクトがあったって良いが、そのための機能じゃないよ。
402 :デフォルトの名無しさん :2024/03/27(水) 21:18:47.87 ID:deTzlgug.net >>401 安全性をコンパイラが検証できないなら、なおのこと制限すべきだと思うがね。 デフォルト禁止でもいいくらい。
403 :デフォルトの名無しさん :2024/03/27(水) 21:31:01.25 ID:LwoOYerE.net >>402 だからそうしたいならそうすりゃいいって話をしてる。 あなたが裁量権をもつプロジェクトでは。 私が反論してるのは「そのためのものだ」という部分に対して。
404 :デフォルトの名無しさん :2024/03/27(水) 21:44:58.62 ID:deTzlgug.net >>403 Rustのコンセプトとニーズからすれば、どこでもunsafe使えるのは中途半端だ、ということだよ。 unsafeはデフォルト禁止でいいよ。
405 :デフォルトの名無しさん :2024/03/27(水) 21:49:49.48 ID:Fy0R0co2.net 理想をいえばunsafeなんて無いならサイコーだったんだろうね rust陣営もしゃあなしでunsafe導入したんやろうし unsafeなしですべてがセーフで効率的だったら そりゃあrustは本当に素晴らしい文句なしの言語だったやろな
406 :デフォルトの名無しさん :2024/03/27(水) 22:08:33.46 ID:toZsv7uT.net 生ポインタすなわちCPUによるメモリアクセスはunsafe そこが出発点 unsafeを組み合わせてunsafeを閉じ込めたsafeなインタフェースを提供できる それがsafe Rustの基本原理 つまりunsafeに行き着くためunsafe無しでは何もできない これが真理 一方で unsafeを閉じ込めたライブラリ利用可を前提にすれば unsafeを用いないsafe Rustでほとんど大抵のことが実現できるのも事実
407 :デフォルトの名無しさん :2024/03/27(水) 22:24:02.18 ID:cgbLYCC5.net >>406 だったらデフォルトunsafe禁止で良い。 どこでもunsafe okはやっぱりチグハグ。
408 :デフォルトの名無しさん :2024/03/27(水) 22:52:47.09 ID:qNf/D02g.net そこまでsafeな事にこだわるなら、Haskellに行けばいいのでは…?
409 :デフォルトの名無しさん :2024/03/27(水) 22:57:38.14 ID:LwoOYerE.net >>404 「そうであって欲しいと自分は思っている」なら別にいいよ。 ニーズとかコンセプトとか、ありもしないものを根拠にしてることに反論されてるんだよ。
410 :デフォルトの名無しさん :2024/03/27(水) 23:02:28.02 ID:toZsv7uT.net #![forbid(unsafe_code)] を宣言すればいい もちろんすべてはunsafeへ行き着くため unsafeを禁止できるのは自分のコード部分だけ
411 :デフォルトの名無しさん :2024/03/27(水) 23:55:45.93 ID:pFQTMi8v.net unsafeな部分の拡張子を変えるというのが有効とはあんま思えんのだよな 平気でunsafe使ってくるガイジは当然平気でunsafeな拡張子を使ってくるだろうという予想する
412 :デフォルトの名無しさん :2024/03/28(木) 07:44:09.91 ID:OabXy/xk.net >>409 公式の「効率的で信頼できるソフトウェアを誰もがつくれる言語」に従うなら、安全でもなくて誰もが使えるわけでもないunsafeはデフォルト禁止にすべきだろ。やっぱりチグハグだわ。 >>411 拡張子以外だとどんなのができるかねぇ。コーダー向けRustとライブラリアン向けRustで完全に分けるぐらい?
413 :デフォルトの名無しさん :2024/03/28(木) 08:15:17.48 ID:wHq/ItvK.net rustもいろいろ問題を抱えてるんだね プログラマの習熟が必要だっていうなら流行らないだろう メモリ安全なソフトウェア書くことを優先するなら土方が適当に使えるjavaやc#があるだろうし 新しいc/c++/rustと競合する決定版のような言語が出てきてrustはさらなる傍流に押しやられそう
414 :デフォルトの名無しさん :2024/03/28(木) 08:34:31.08 ID:5loDhjzb.net >>412 こう書くだけでunsafeの使用が禁止されます #![forbid(unsafe_code)] >>413 普通の人はunsafeなんか使いませんからRustは安全で何も問題ありません
415 :デフォルトの名無しさん :2024/03/28(木) 08:48:28.49 ID:OabXy/xk.net >>414 >411みたいなマキャベリガイジが混ざると破綻しますな。 MSとかGoogleとかの管理側がRustに期待するのはそういった部分含めた安全性だろ。
416 :デフォルトの名無しさん :2024/03/28(木) 09:00:19.29 ID:5loDhjzb.net >>415 これでunsafeが使用禁止となり安全なsafe Rustになる #![forbid(unsafe_code)] コンパイラがunsafeをエラーとして弾く
417 :デフォルトの名無しさん :2024/03/28(木) 10:37:24.50 ID:dWo+4s1T.net 結局いつもの「無知なアンチ vs 無知な信者」の薄っぺらい対立になっちゃうのな
418 :デフォルトの名無しさん :2024/03/28(木) 14:03:58.90 ID:61/ABBlz.net まあハスケルなんかもinvalidな変数使うようにっての広めるのには役立ったからrustもそういう位置に落ち着くだろ。
419 :デフォルトの名無しさん :2024/03/28(木) 17:41:01.08 ID:Li+1uESY.net unsafeを使う人はライブラリ作成者がほとんどで、残りはシビアなインフラ作成者 一般プログラマーはunsafeを使わずに、unsafeが閉じ止められたライブラリのsafeなインターフェースのみ用いる もしunsafeを用いて閉じ込めてsafeなインターフェースを提供できる新たなパターンを発見した時のみ、 その部分だけを切り出してライブラリ作成者になれる それができない一般プログラマーはunsafeに縁がなく、unsafeを気にする必要がない
420 :デフォルトの名無しさん :2024/03/28(木) 18:27:15.03 ID:OabXy/xk.net >>419 そうならやっぱりデフォルト禁止にすべきだな。一般コーダーはunsafeを使えないようにしてコードの安全性を高めるべき。 Rustのデフォルトムーブとかshared xor mutableとかは安全側に倒しているのに、なんでunsafeだけはユルユルなのかね。
421 :デフォルトの名無しさん :2024/03/28(木) 18:35:39.73 ID:2Ez7VURh.net unsafeって書かないといけないってのは結構デフォ禁止よりの処置だと思うが このメッセージが伝わらない相手にはもうunsafeの文法を分けてunsafeだけ難しくするとかしかなさそう でもわざわざ難しい文法を用意すると言うのも馬鹿らしい話だ
422 :デフォルトの名無しさん :2024/03/28(木) 18:56:54.80 ID:Hx0Q8eMq.net 必要な各企業、各プロジェクトなどで義務付け #![forbid(unsafe_code)] これでunsafeの話はおしまい 他の言語と比べてRustはコーディング規約もAPI規約も公式で楽 Rust公式APIガイドライン https://rust-lang.github.io/api-guidelines/
423 :デフォルトの名無しさん :2024/03/28(木) 19:45:10.84 ID:OabXy/xk.net >>422 公式のドキュメントで #![forbid(unsafe_code)] の説明を探しているんだけど、どこにあるのかしらん? doc.rust-lang.org/nomicon/safe-unsafe-meaning.html の1行でおしまい?
424 :デフォルトの名無しさん :2024/03/28(木) 20:08:10.91 ID:uNPCtnZO.net forbidもunsafe_codeもrustcのlintの一部だな doc.rust-lang.org/rustc/lints/levels.html#forbid doc.rust-lang.org/rustc/lints/listing/allowed-by-default.html#unsafe-code
425 :デフォルトの名無しさん :2024/03/28(木) 21:59:19.02 ID:vhhc95Ef.net Rust Foundationによる資格認定試験に合格した者だけにunsafe使用パスワードが発行されるようにするしかないな。
426 :デフォルトの名無しさん :2024/03/28(木) 22:34:58.42 ID:jTiWvkZ+.net どの開発でも #![forbid(unsafe_code)]が原則 どうしてもunsafeが必要なら その安全ロジックを関係者で協議後に #![deny(unsafe_code)]へそのモジュールのみ変更し 許可する部分のみを #![allow(unsafe_code)]として監視対象 といった感じが一般的かと 監視対象を極一部に限定できて 全体はコンパイラにより保証できるため 他のプログラミング言語より扱いやすい
427 :デフォルトの名無しさん :2024/03/28(木) 22:41:56.41 ID:8+kd1npI.net >>420 一般とそうでない奴は誰がどうやって区別するのさ?
428 :デフォルトの名無しさん :2024/03/28(木) 22:42:31.88 ID:8+kd1npI.net >>421 正解
429 :デフォルトの名無しさん :2024/03/28(木) 23:58:52.21 ID:KGiLR8kg.net 時間がない時はunsafe使っていいよ
430 :デフォルトの名無しさん :2024/03/29(金) 00:05:51.94 ID:B//2x2dm.net 時間がない時に焦ってunsafe使って書いたコードは長期利用すると大変なことになるので書いてから1時間以内に使って捨てよう
431 :デフォルトの名無しさん :2024/03/29(金) 00:19:58.75 ID:Rgc3qInF.net >>429 safeで書くのが早くて楽で安全 わずかでもパフォ上げる必要性のあるような箇所が生じない限り、unsafeを検討する人は存在しない
432 :デフォルトの名無しさん :2024/03/29(金) 00:24:32.79 ID:Rgc3qInF.net >>430 unsafeの使用は、その論拠の安全性の検討や、それ以前に必要性の検討などが必要となるため、時間がかかる safe Rustが楽で早く書けて安全
433 :デフォルトの名無しさん :2024/03/29(金) 01:57:50.63 ID:EplliVDI.net 壊れたレコードオジ怖い
434 :デフォルトの名無しさん :2024/03/29(金) 02:36:16.29 ID:B//2x2dm.net >>432 安全性の検討も必要な検討も全部スキップして「えいや」ってやればsafe rustより速く書き上がることもあるのでは?
435 :デフォルトの名無しさん :2024/03/29(金) 07:36:27.65 ID:9Pm5HVgJ.net 雑にunsafe使って早く書けるのはFFIくらいかな FFIはどのみちunsafe必須だけど、事前条件とかの検討せずに雑にsafe化してしまうならそれは確かに早い pure Rustでunsafeの方が早いケースはちょっと思いつかないな
436 :デフォルトの名無しさん :2024/03/29(金) 08:25:13.35 ID:bd1Zch8f.net >>427 そりゃプロジェクト管理者だろ。 そもそもRust採用するメリットはソースコードの品質管理しか無いし。 デフォルトunsafe禁止は何回か話題に出てきているのな。
437 :デフォルトの名無しさん :2024/03/29(金) 08:27:22.40 ID:bd1Zch8f.net >>426 それぐらいやらないとRust採用するメリット無さそうだよな。
438 :デフォルトの名無しさん :2024/03/29(金) 08:41:03.04 ID:ev5kqnbp.net 初心者ぼく「禁止しないといけないようなもんが標準で使えるって結局それ危険な言語なんでは?
439 :デフォルトの名無しさん :2024/03/29(金) 09:16:34.82 ID:cTkAvXQI.net そもそも普通に書いててunsafe使いたいなって場面がない 多人数で書いてるならforbidで落としてもいいけど コードレビューでちょっとでも見ればunsafe使ってることは明らかなんだし、いずれにしてもどうでもいい
440 :デフォルトの名無しさん :2024/03/29(金) 09:24:57.68 ID:vaG7EqUh.net >>436 じゃunsafe使うな、で済む話じゃん。
441 :デフォルトの名無しさん :2024/03/29(金) 09:49:54.05 ID:AosFf04R.net >>440 そうだね で?
442 :デフォルトの名無しさん :2024/03/29(金) 11:01:08.74 ID:8PtB/vi4.net rustもプログラマがザコだと使いこなせない言語なんだろ? 人材確保すら苦労するってメジャーになれるのかよ
443 :デフォルトの名無しさん :2024/03/29(金) 11:23:44.57 ID:34VMnlB4.net unsafeでサッと書いたほうが出世できるぞ
444 :デフォルトの名無しさん :2024/03/29(金) 11:49:42.05 ID:ZM8BmiyA.net たしかにプログラムの品質がいいから出世するって見たことないわ 逆にクソ過ぎて出世できない奴はいるかも知れんがそういう奴はプログラム云々の問題ではないからな
445 :デフォルトの名無しさん :2024/03/29(金) 11:53:12.39 ID:opHbD1qf.net unsafeは面倒 Rustで書いていてunsafeを使いたい気分になることがない さらに通常のプログラミングでunsafeを使うメリットがあるケースが訪れることはまずない
446 :デフォルトの名無しさん :2024/03/29(金) 11:54:18.08 ID:K6ErCtbZ.net >>442 メジャーになれなくて何か問題あるの?
447 :デフォルトの名無しさん :2024/03/29(金) 12:08:03.79 ID:6hM9S6Vd.net 初心者や一般的な人は、unsafeの使い所がないなら、unsafeを使うようなすごい人でもミスをしたり理解不足だったりするって事だから、すごい人が精進すれば解決でしょ。
448 :デフォルトの名無しさん :2024/03/29(金) 12:08:08.24 ID:GuqFwMZD.net >>440 PMやったこと無いの? unsafe使うなと管理するより、そもそも使えない方が遥かに楽。
449 :デフォルトの名無しさん :2024/03/29(金) 12:13:58.45 ID:E/kaNL72.net >>442 C++ とかだと使いこなせてないのになんとなく動いちゃったりするから…… 使えてないなら使えないほうがちょっとマシなんだよ。
450 :デフォルトの名無しさん :2024/03/29(金) 12:15:29.32 ID:vaG7EqUh.net >>448 言語機能的にunsafeって書かなければそもそも使えないじゃん。
451 :デフォルトの名無しさん :2024/03/29(金) 13:21:21.11 ID:l8m+nc89.net >>446 時間の無駄
452 :デフォルトの名無しさん :2024/03/29(金) 13:35:34.69 ID:ZM8BmiyA.net >>448 そのあたりの管理は開発TLの仕事だと思ってたがPMが兼任することもあるのね
453 :デフォルトの名無しさん :2024/03/29(金) 16:25:54.97 ID:34VMnlB4.net unsafeでサクッと終わらせてどんどん仕事取ろうぜ safeでチンタラやってる無能に仕事を回すな
454 :デフォルトの名無しさん :2024/03/29(金) 17:20:13.23 ID:Cl3C8AEw.net アンチはunsafeを使うと早く書けると誤解しているのが面白い 早くもなければ楽でもないので普通は使わない
455 :デフォルトの名無しさん :2024/03/29(金) 17:36:40.68 ID:cTkAvXQI.net 「借用エラー出たらとりあえずunsafeと書いとけば回避できる」くらいのイメージなんかね
456 :デフォルトの名無しさん :2024/03/29(金) 17:56:14.07 ID:uhU4IUEm.net このスレの優秀な人たちを安月給で揃えたチーム作れたらunsafeについて真面目に取り組んでもいいんだが
457 :デフォルトの名無しさん :2024/03/29(金) 18:02:08.48 ID:uhU4IUEm.net 正常なコミュニケーション力を持った優秀なエンジニア →こいつらは出世するのでプログラミングスキルは生かされない方向に進む 正常なコミュニケーション力がない優秀なエンジニア →こいつらはどうでもいいことばかりブツブツ言っててイマイチスキルが生かされない どうしたら優秀なエンジニア揃えられるんや…
458 :デフォルトの名無しさん :2024/03/29(金) 18:06:18.85 ID:fG0MAqjd.net カチョー「では進捗を報告してください」 unsafe_man「アノー、チョット時間かかってオリマシテ、アンセーフが、ソノー(怒涛の勢いで難しいことを話し続ける)」 カチョー「???」
459 :デフォルトの名無しさん :2024/03/29(金) 18:22:45.54 ID:TAofIzHh.net >>457 放っておいても勝手に集まるから心配しなくていいよ そこに混ざりたいなら自身も優秀なエンジニアになる必要はあるけど
460 :デフォルトの名無しさん :2024/03/29(金) 18:29:23.69 ID:/REVrZ9A.net >>459 すまん、集まってるとこの実名あげてくれんか?
461 :デフォルトの名無しさん :2024/03/29(金) 19:20:01.67 ID:GuqFwMZD.net >>458 いきなり人格攻撃かよ?Rustらしいな
462 :デフォルトの名無しさん :2024/03/29(金) 19:31:34.50 ID:wqpOcL9O.net NとかFとかは優秀な人がいるイメージがない
463 :デフォルトの名無しさん :2024/03/29(金) 19:54:25.38 ID:M7FjmHlu.net unsafe使う機会ってほぼないよな よほどシビアな低レベルライブラリ作成かFFI部分くらいじゃないか
464 :デフォルトの名無しさん :2024/03/29(金) 19:58:01.23 ID:wqpOcL9O.net 優秀なエンジニアは担当している仕事がいつ頃終わるか明確に答えられる人 でunsafeを使いこなせるかどうかなんか無関係 これいつまでかかるのと聞かれていつまでに終わるか言えて理由も言える人
465 :デフォルトの名無しさん :2024/03/29(金) 19:59:06.31 ID:0Uoml8t7.net システムプログラミング用途も売りにしてなかった? Cと同等のことをしてみせようってんなら unsafeくらい当たり前に常用するやろ?しらんけど ボクは使いません!みたいな意見は誰も求めてないからw
466 :デフォルトの名無しさん :2024/03/29(金) 20:37:55.25 ID:TAofIzHh.net unsafe使うと変更する時にだるくなるからできるだけ使わない グローバル変数使うのと同じ気分 「グローバル変数くらい当たり前に常用するやろ?しらんけど ボクは使いません!みたいな意見は誰も求めてないからw」 とか言われたら知らん
467 :デフォルトの名無しさん :2024/03/29(金) 20:41:59.79 ID:wqpOcL9O.net 誰にも影響及ぼさないなら勝手に使えばいい
468 :デフォルトの名無しさん :2024/03/29(金) 20:47:48.55 ID:0Uoml8t7.net 使う必要があるからunsafeってもんがあるんであって 使う必要がない人の意見や感想は求められてないんよ 使うべきとか使うべきじゃないとか 普通はどうとか普通はどうじゃないとか 無意味な応酬はやめよう
469 :デフォルトの名無しさん :2024/03/29(金) 21:08:57.87 ID:bd1Zch8f.net コーダーの「使う使わない」の問題じゃなくて、管理者の「許可する禁止する」の問題なんだよ。
470 :デフォルトの名無しさん :2024/03/29(金) 21:45:08.79 ID:DW6NdCQ6.net >>451 君の時間の無駄ってこと? こんなところで毎日無駄な時間過ごしてるのに? それって君がやらなければいいだけだよね
471 :デフォルトの名無しさん :2024/03/29(金) 21:46:36.17 ID:wXELlTG7.net >>468 一連のunsafeコントで初めてまともな意見だな
472 :デフォルトの名無しさん :2024/03/29(金) 21:52:31.85 ID:TAofIzHh.net エンジニアが判断すべき問題を管理者が決定してるようなレベルの開発現場まで Rustが普及する日は来るんだろうか 上の方でも言われてたけどコーダー集まらない問題に直面しそうだが
473 :デフォルトの名無しさん :2024/03/29(金) 22:06:45.92 ID:wqpOcL9O.net Rustはコーダーは集まらんだろ 普通は外注先がほぼコーディングできない新人を連れてきて実質的にこちらが教育する羽目になる ある程度使えるようになるとそいつがどこか単価の高いところに送られてまた代わりの新人が送られてくる 大手だとこれの繰り返しだがRustはそれが難しい
474 :デフォルトの名無しさん :2024/03/29(金) 22:29:09.47 ID:wqpOcL9O.net 意図的にどこかで誰かが資金を投入してRustコーダーを栽培()しないと 増えるわけがない javaやpythonじゃないんだから 野良Rustコーダーなんて存在しない 使える人間は100%C++使いなので引っ張ってこれない
475 :デフォルトの名無しさん :2024/03/29(金) 22:30:50.06 ID:UmT7/PmU.net エンジニアの趣味なら高尚な言語追求してもいいと思うけど、ビジネスで使う言語はあくまでビジネスメリットが大きなもの選ばないと立ちいかなくなるよな
476 :デフォルトの名無しさん :2024/03/29(金) 22:35:31.54 ID:B//2x2dm.net まあJavaとかC++のバケモノみたいな分量のコーディング規約の存在を考えると、「Unsafe使うな」の一言で済むRustは原理的にはビジネス的なメリットありそう
477 :デフォルトの名無しさん :2024/03/29(金) 22:48:02.40 ID:0Uoml8t7.net それよりもホントにシステムプログラミングできてんのかが興味あるわ CからはOSならばUnixやLinuxやWindowsが生まれてきたけど Rustからは一体どんな素晴らしいものが生まれてくるんだろうか? Cより書きやすくて? 安全なんだよね? 期待していいんよね? Systems programming https://en.wikipedia.org/wiki/Systems_programming e.g. operating systems, computational science applications, game engines, industrial automation, and software as a service applications
478 :デフォルトの名無しさん :2024/03/29(金) 23:01:23.64 ID:B//2x2dm.net 今更OSを書いたところでビジネスに出来るのは一握りの人間だからCの頃とは話がちょっと違いそうではある でも期待するのは自由だ Rustファンはみんな期待している
479 :デフォルトの名無しさん :2024/03/29(金) 23:11:14.94 ID:JKQcuRe5.net >>477 interfaceって組み込み専門誌は毎月お題スレみたいな問題を解く記事が出てたり、Rust特集の時でもOSを作るどころか、OS乗らないような環境(Cとアセンブラの独壇場。C++不可の世界)で組み込みRust使う記事とかあったよ。 ビジネスになるかはともかく、技術的には余裕なはず。
480 :デフォルトの名無しさん :2024/03/29(金) 23:55:56.73 ID:VDRjyKLu.net 既にネットインフラは次々とRust製 ソースは>>51
481 :デフォルトの名無しさん :2024/03/30(土) 00:06:31.16 ID:v9pXWAWc.net >>472 Rustは仕様や周辺ツールが飛びぬけて優秀な故 JavaやPHP等他の言語と違って素人でも適当に書いても 大した問題は起こらないから「技術者の立ち位置」を守る観点で見ると 大規模開発現場で普及する事はこれからも無いよ。
482 :デフォルトの名無しさん :2024/03/30(土) 01:01:10.58 ID:7ofxl8DK.net それで守られるのはITコン猿の立ち位置じゃね? エンジニアは長期的な保身より目の前の利便性に飛びつきそうだが
483 :デフォルトの名無しさん :2024/03/30(土) 01:46:17.09 ID:v9pXWAWc.net 知ってる人間は黙ってRustの恩恵を受けておけば良くて 人売りサル業界は人/月だコミュニケーションスキルだと 喚いていれば良い。
484 :デフォルトの名無しさん :2024/03/30(土) 07:28:24.91 ID:6WvjgMqi.net C++が流行った経緯知ってる奴なら想像できるだろ。 C++が出た当初はSTLもテンプレートもなかったしライブラリなんかはObjective-Cのほうが多いくらいだった。 でも流行ったのはC++。
485 :デフォルトの名無しさん :2024/03/30(土) 13:15:43.05 ID:Kpt9p6/a.net C++はわかりやすく拡張されたCだからさ ライブラリのAPIとかCばかりだから最悪そのまんまCでも良かった NEXTSTEPでObjecive-C開発は呪術で入門書もなく上手くいかなくても何が悪いのかさっぱりわからない 日本語の書籍がないのが一番つらかった
486 :デフォルトの名無しさん :2024/03/30(土) 20:58:56.17 ID:IReUP+am.net 当時NeXTに触れてたやつおるん? たまげたなぁ 俺なんか図書館の奥に潜んでるObjective-Cの本読んでたよ いつごろだったかなぁ日本語のやつあったけどなぁ まさかmacOSで脚光浴びるとは思いもせずに
487 :デフォルトの名無しさん :2024/03/30(土) 21:08:50.38 ID:Kpt9p6/a.net 研究室にあったんよ 当時でももう型オチででも予算無いからリプレースも出来ず MOのデータを消しながら使ってた 古いUNIX系の雑誌の特集見てそれをポチポチやってクソうるさくて遅いHDDの音聞きながらコンパイル待って…と言う感じで 自分は図書館に埋もれたModulaの本を読んでた
488 :デフォルトの名無しさん :2024/03/30(土) 21:14:51.55 ID:IReUP+am.net 羨ましい 俺は演習室のBSDのWMをafterstepにしてニマニマしてただけ あー羨ましい
489 :デフォルトの名無しさん :2024/03/30(土) 22:32:19.21 ID:VLAlfJh3.net モーモーちゃんに入れている人は居たな
490 :デフォルトの名無しさん :2024/03/31(日) 11:42:27.74 ID:lJUXuXT4.net C の宣言の文法が無茶苦茶なのを C++ で改良するかどうか迷った話は D&E に書いてある。 結局は C のままでいくと判断した。 良くなるのだとしても、少なくとも一時的には大きな混乱が起こることを C++ は許容しなかった。 言語ってのはそれを取り巻くエコシステム (言語ユーザーやドキュメントも含む) と離れて成立することはないってこと。 C++ は C のツールチェインにほとんどそのまま乗っかる形で (最初は) 普及したし。 Rust はツールチェインの整備も一緒に取り組んだというのは普及の一助になったとは思うけど、 今までに作られた膨大なソフトウェア資源の最も低レイヤの部分は結局は C なんだよね。 そもそも ABI が C を基準にした仕様だったりするので 他の言語と接続するときは皆が C に合わせる形になる。 もしこれから Rust がもっと普及することがあったとしても低レイヤでは C の残滓はいつまでも消えないと思う。
491 :デフォルトの名無しさん :2024/03/31(日) 15:29:48.98 ID:dXzgmT0X.net ABI stableにするのはエディション単位でいいんだからさっさとやればいいのにとは思う
492 :デフォルトの名無しさん :2024/03/31(日) 16:44:42.12 ID:PaHOJUqO.net >>490 Rustで書いたOSが大流行でもしない限りCと同じようにはならない。 ただ、Linux は Rust を取り込み始めたので何十年も掛けてゆっくり Rust 化する可能性はある。 そうなると移行したライブラリは増え続け、50年後ぐらいには今のCと同じようになっているかも知れない。 もちろんその頃には別の新言語が出てきていて Rust が時代遅れな言語になっているわけだが。
493 :デフォルトの名無しさん :2024/03/31(日) 19:15:56.54 ID:r1rO2LMH.net ABI部分のコーディングする人はプログラマーの1%もいないんだから影響は昔も今後もない 多言語システムはそれより多いけどそこはABIではなく様々な通信プロトコルなどを介する
494 :デフォルトの名無しさん :2024/03/31(日) 19:55:09.30 ID:T95JlUSJ.net ABIこそ良い奴が出たら置き換えられそうだけどな 現状良い奴がないだけで
495 :デフォルトの名無しさん :2024/03/31(日) 21:03:45.67 ID:rhKYEfc8.net >>493 何言ってんのwww 相変わらず無知が過ぎる
496 :デフォルトの名無しさん :2024/03/31(日) 22:06:47.20 ID:HimKkZni.net いやまあ1%もいないんじゃない?
497 :デフォルトの名無しさん :2024/03/31(日) 23:37:37.59 ID:PUonJ710.net そりゃABIがらみのプログラミングよりはProtocol Buffersなど使う方が多いんだろうけど
498 :デフォルトの名無しさん :2024/04/01(月) 19:53:32.69 ID:QJf4H8j7.net そんなん言ったらrustを必要とするプログラマこそ1%もおらんけどな。
499 :デフォルトの名無しさん :2024/04/01(月) 20:06:07.63 ID:lQvViLVK.net C++より多いから問題ない
500 :デフォルトの名無しさん :2024/04/01(月) 22:56:49.63 ID:wqqAiPYQ.net 「ソフトウェアはメモリ安全でなければならない」との声明を発表、米ホワイトハウス:「C」「C++」よりも「Rust」などの言語を推奨 https://atmarkit.itmedia.co.jp/ait/articles/2403/18/news045.html
501 :デフォルトの名無しさん :2024/04/02(火) 08:53:54.00 ID:i0O60K8Z.net >>500 メモリ安全というならSafe Rustのみだな。Unsafe Rustは禁止すべき。 c++標準も、Safe Rust に倣って c++ subset for safe programming とか 作ればいいのに。
502 :デフォルトの名無しさん :2024/04/02(火) 09:19:58.94 ID:D6QICSr8.net メモリの具体的な番地やレイアウトに依存する低レイヤの事情が消えてなくなるわけじゃないからな。
503 :デフォルトの名無しさん :2024/04/02(火) 09:39:48.87 ID:EeET/S7r.net java, python みたいな言語ならメモリ安全だよ。お前らの用途ならそれで十分だろ。
504 :デフォルトの名無しさん :2024/04/02(火) 11:06:55.03 ID:lti1kN7b.net >>503 安全じゃ無いぞ
505 :デフォルトの名無しさん :2024/04/02(火) 14:49:37.59 ID:b3hi6lw5.net >>501 C/C++はプログラム全体がunsafe空間なので難しい safeにしようとすると全く別言語になってしまう 結局C/C++を捨てるのが正しい
506 :デフォルトの名無しさん :2024/04/02(火) 17:14:03.69 ID:kERS+9TD.net >>503 nullポイントがある時点で… 一応JavaはStream APIと同じくらいのタイミングでOptional<T>が追加されてたはずだけど,だからといって従来の「失敗したらnullを返すメソッド」がOptionalを返すように修正されたわけじゃないしなぁ
507 :デフォルトの名無しさん :2024/04/02(火) 17:14:28.23 ID:kERS+9TD.net nullポインタだ ごめんなさい
508 :デフォルトの名無しさん :2024/04/02(火) 18:23:13.98 ID:mnREx4SD.net ぬるぽ例外で止まるのはNone.unwrap()のpanicで止まるのと同じで安全に分類される nullから何かを読み出して動き続けると危険
509 :デフォルトの名無しさん :2024/04/02(火) 18:43:54.77 ID:0YGJ2wff.net >>508 Someである保証がある時のみunwrap()を使う 保証がないのにunwrap()する人はクビ
510 :デフォルトの名無しさん :2024/04/02(火) 18:54:06.54 ID:mnREx4SD.net メモリ安全の文脈だからそういう次元の話ではないのだが
511 :デフォルトの名無しさん :2024/04/02(火) 18:55:57.61 ID:i0O60K8Z.net >>505 コーダー向けだから別言語でいいよ。 new deleteは禁止していいし、ポインタ演算その他のポインタ処理は全部禁止でいい。生ポインタのヒープ領域コピーも禁止していいし、そもそも生ポインタ禁止で参照のみ可にしてもいい。 operator関数定義も禁止でいいんじゃない?
512 :デフォルトの名無しさん :2024/04/02(火) 19:03:35.75 ID:mnREx4SD.net ちょっと何が禁止なのか分からないのでローカル変数の参照をreturnしておきますね
513 :デフォルトの名無しさん :2024/04/02(火) 19:19:41.72 ID:qL7KDCYj.net rustって楽しい?
514 :デフォルトの名無しさん :2024/04/02(火) 19:20:30.34 ID:kERS+9TD.net どの言語にも共通するけど,書けるようになってくると楽しいよ
515 :デフォルトの名無しさん :2024/04/02(火) 19:40:54.12 ID:lti1kN7b.net でもってライブラリが足りて無いなって思って「使えね」ってなるんだよね
516 :デフォルトの名無しさん :2024/04/02(火) 19:43:54.71 ID:ptOw8ylO.net >>512 あ、未定義と定義されているのも全部禁止ね。
517 :デフォルトの名無しさん :2024/04/02(火) 20:13:32.30 ID:+hiVU8fL.net >>500 これでRustの知名度も上がるし普及も加速しそう
518 :デフォルトの名無しさん :2024/04/02(火) 20:26:12.86 ID:lti1kN7b.net >>517 結構前にもNASAが同じ様な事言って今やんw
519 :デフォルトの名無しさん :2024/04/02(火) 20:31:06.25 ID:EeET/S7r.net rustを無理に使ってまですることがぬるぽ対策とかアホだよね
520 :デフォルトの名無しさん :2024/04/02(火) 20:45:15.37 ID:lti1kN7b.net >>519 まあ戦争によるサイバー攻撃に備えろってのは分かるんよ 日本も来年ぐらいに戦争になるって予測がアメリカとか含めて言われてるからね
521 :デフォルトの名無しさん :2024/04/02(火) 21:20:14.32 ID:+5bQ5ala.net >>518 NASAに続いて米政府も「C/C++からRustへ切り替えろ」と明確なメッセージを出したことは大きいね 間違いなく日本も追随することになる
522 :デフォルトの名無しさん :2024/04/02(火) 21:56:04.08 ID:mnREx4SD.net Rust愛用者だけど今のホワイトハウスに推されると逆に不安になるんだがw ONCDは健全なのかな
523 :デフォルトの名無しさん :2024/04/02(火) 22:51:50.04 ID:ZP8DsSPi.net >>518 NASA?NSAじゃなく? NSAはNASAじゃないぞ。
524 :デフォルトの名無しさん :2024/04/02(火) 23:24:29.45 ID:JjgiIhmH.net ワロタ NSAとNASAの区別もできんとはww メッセージを出してるところが広がってトーンも厳しくなってきてるのは確か 2022/11 NSA 2023/09 CISA 2023/12 CISA+NSA,+FBI+Five Eyesの各機関 2024/02 White House(ONCD)
525 :デフォルトの名無しさん :2024/04/02(火) 23:39:08.04 ID:/KZzSXx2.net とりあえず良いcrateが増えまくってほしいな
526 :デフォルトの名無しさん :2024/04/02(火) 23:51:33.79 ID:DOFjhDY0.net >>524 あとは日本がどれだけ遅れるかだな 数ヶ月か、1年か、数年か、
527 :デフォルトの名無しさん :2024/04/02(火) 23:57:17.27 ID:ULMcj34Q.net 外部のお墨付きを欲しがる時点でオワっとるんよ 言語として ここでそういう話題使って必死で盛り上げようとして 消えそうな火に風送ってるつもりかしらんけど
528 :デフォルトの名無しさん :2024/04/03(水) 00:07:33.86 ID:xB8sPKZQ.net IT大手ライバル同士が GAFAMからHUAWEIまで一致団結して Rust Foundationを設立した時点で未来は確定していた そしてRustに対抗できるライバル言語の芽が今も存在しない
529 :デフォルトの名無しさん :2024/04/03(水) 05:31:15.82 ID:SWmJ9bDO.net >>527 話題にも上がらないよりまし
530 :デフォルトの名無しさん :2024/04/03(水) 07:36:47.52 ID:ClJR5oeK.net Rustの代替になる思想の言語が全くそれ以降全く見ないからな。 今のところGCレスでメモリ安全に向き合った唯一の言語でねえの? 後発の言語は Rust みたいに複雑なコンパイル時の検証を最初から書こうなんてそうそう思えないんじゃないかな。
531 :デフォルトの名無しさん :2024/04/03(水) 08:17:45.92 ID:OgaFV8I4.net >>527 欲しがってるかね? むしろ外部が乗っかろうとしてる感じ。
532 :デフォルトの名無しさん :2024/04/03(水) 08:58:53.93 ID:7dkIXzmY.net >>530 メモリ安全に向き合う、程度ならそれこそc++11が先駆けだろ。 過去互換性のせいで徹底できないけど。 それよりもRustはスタックフレーム指向であることに価値がある。 スタック is god, 再帰 is god.
533 :デフォルトの名無しさん :2024/04/03(水) 11:38:42.38 ID:TbyA9/um.net >>515 まあ標準ライブラリがかなりミニマムだなぁって感じるときはある 乱数くらい用意しておいてよ…
534 :デフォルトの名無しさん :2024/04/03(水) 11:38:56.67 ID:zWYr6uc2.net >>530 ある言語Aがあってその弱点が強烈で直したいけどすでに普及しきっている で別の言語Bが作られる その言語Bが普及しきっていなければ容易に弱点を変更できるので別のC言語は必要とされない
535 :デフォルトの名無しさん :2024/04/03(水) 13:08:37.11 ID:VOIzFFgw.net >>534 >その言語Bが普及しきっていなければ容易に弱点を変更できる これが真とは限らない 容易に変更できる場合もあればそうでない場合もある
536 :デフォルトの名無しさん :2024/04/03(水) 13:33:20.93 ID:7LWlVk3J.net Rustで過去に結構破壊的変更がされてたらしいけどそれは普及してなかったからじゃないのか wikipedia > 2015年に1.0版がリリースされるまでにいくつもの破壊的な仕様変更があったが、1.0版以降は基本的には後方互換を保って6週間間隔で定期的にリリースされている。
537 :デフォルトの名無しさん :2024/04/03(水) 21:45:24.20 ID:ClJR5oeK.net GCやJITは銀の弾丸と思われていろんな後発言語に取り込まれたけど、所有権は最初から組み込むには高度すぎるがエコシステム成熟前に組み込まないといけないという制約が大きいんだろうな。
538 :デフォルトの名無しさん :2024/04/03(水) 22:40:40.78 ID:7LWlVk3J.net 後発言語???
539 :デフォルトの名無しさん :2024/04/04(木) 03:50:23.61 ID:6dtGhNgR.net >>537 所有権は最終的にはプログラム間の境界の問題になるから、c++のスマートポインタのようにアダプタで管理範囲を調整することで改善可能。 適切なアダプタを用意しても境界のプロトコルをどうやって徹底するかという問題は残るから、Rustみたいに言語レベルで強制できると頑強になる。 ただ、Rustみたいにガチガチにすると設計の柔軟性を失うから、実装も早すぎる最適化になりがち。Rustの絶壁の学習曲線と相まって、開発初期のRust導入はプロジェクトを破綻させる要因となりうる。Rustが適しているのは、ある程度枯れた設計の実装を置き換えるようなプロジェクトかと。
540 :デフォルトの名無しさん :2024/04/04(木) 04:13:47.93 ID:KZy/sIny.net Rustはむしろリファクタリングにも向いていてなかなか良い言語だぜ とりあえず動くように雑に書いて動かしてみて 次に機能追加充実させる上で整理しながらモジュール化や共通事項のtrait化など このようなリファクタリング過程で 他の言語だとメモリ安全性だけでなく書き換え競合やヌル値エラー値取り扱いミスなどエンバグすることも多いが Rustではコンパイル通せばそれらの心配がなくリファクタリングできる
541 :デフォルトの名無しさん :2024/04/04(木) 08:02:04.20 ID:KuogGH/c.net そもそもGC無しの言語ってニッチじゃない? 当面は、Rustで充足されて安泰な気がする。
542 :デフォルトの名無しさん :2024/04/04(木) 08:06:01.77 ID:wZ/e8tnl.net うむり、実用言語では現時点で安全性とスピードを高い次元で両立できてるのはRustだけかもね。 関数型言語にも良いのあるけど、普及しなさそうだしね…。 (OCamlとか次世代HaskellらしいIdrisとか) それにCとアセンブラしかない分野(C++不可なくらい低スペックな組み込み)でC++以降のモダンな言語が使えるのは大きい。
543 :デフォルトの名無しさん :2024/04/04(木) 08:41:03.15 ID:VIrJEXhK.net 学問的には合理的な型システムとか検証器とかの研究は大きく進んでるけど メモリの動作モデルをそこそこちゃんと仕様にしてるのは C/C++ しかないんだよね。 LLVM が C/C++ を前提にしてるところもあるし、 Rust もそれに合わせる形になってるところもある。 C/C++ 的な分野をよりよくやる言語と考えると Rust はとても良い。
544 :デフォルトの名無しさん :2024/04/04(木) 12:25:37.65 ID:Gnl54rZ8.net すまんが↓これが動く理由を教えて欲しいんだけどさあ https://paiza.io/projects/uhC43ajorg-qaLG7mXbw7w 一見すると5行目で所有権が失われて、6行目で使ってるように見えるんだけど・・・・ これって5行目が借用に推定されてるの? それともリテラルを引数にした場合だと5行目で「1」が他のスタックにコピーされて、所有権が失われる問題なんか起きないのかな? へるぷみい
545 :デフォルトの名無しさん :2024/04/04(木) 12:36:31.67 ID:xh1kANkn.net マクロだからセーフ
546 :デフォルトの名無しさん :2024/04/04(木) 12:40:39.97 ID:yz59nStO.net >>544 値とその所有権が複製されて関数fに渡される分とそのまま残る分の2つになる
547 :デフォルトの名無しさん :2024/04/04(木) 12:49:08.15 ID:w8P1RFve.net 値が複製されて、複製された値の所有権が関数fに渡るだな。 所有権の複製とかいうクソワードは避けてくれ。
548 :デフォルトの名無しさん :2024/04/04(木) 14:09:00.66 ID:VIrJEXhK.net >>544 i32 は Copy トレイトが実装されてる。 普通なら所有権の移動になる文脈で暗黙に clone されると思ったら良い。
549 :デフォルトの名無しさん :2024/04/04(木) 14:21:30.05 ID:Gnl54rZ8.net そう言うことなのか、ありがとう! 理由が分からなかったから不気味だったぜ
550 :デフォルトの名無しさん :2024/04/04(木) 15:21:14.87 ID:AF0jRQyM.net >>547 >値が複製されて、複製された値の所有権が関数fに渡るだな。 複製された値の所有権は最初から関数fのスコープの中で発生するものなので 「関数f」に渡るという表現には少し違和感を感じる
551 :デフォルトの名無しさん :2024/04/04(木) 15:34:13.46 ID:1vyOHDUL.net 「違和感を感じる」という表現に違和感を感じる
552 :デフォルトの名無しさん :2024/04/04(木) 18:59:50.97 ID:mbQWc9lN.net >>551 滑ってるぞ
553 :デフォルトの名無しさん :2024/04/04(木) 19:04:00.82 ID:mNkWQBjH.net 感じてるから違和「感」だからね 要は頭痛が痛いと同じ
554 :デフォルトの名無しさん :2024/04/04(木) 19:08:09.03 ID:v0TcrcAn.net 違和感がある。これでどうだ
555 :デフォルトの名無しさん :2024/04/04(木) 19:17:51.63 ID:v7LceGlx.net >>553 感じるを感じるメタ表現だろ。 ポインタのポインタみたいなもんだ。
556 :デフォルトの名無しさん :2024/04/04(木) 20:07:49.07 ID:xDxHg+AD.net >>542 embedded 対応アーキ少なくね?
557 :デフォルトの名無しさん :2024/04/04(木) 23:05:07.77 ID:94OMF7T7.net >>553 「違和感を感じる」は「頭痛が痛い」とは違って重言ではないよ https://togetter.com/li/2067771 https://www.nhk.or.jp/bunken/research/kotoba/20240101_4.html
558 :デフォルトの名無しさん :2024/04/04(木) 23:18:56.70 ID:94OMF7T7.net >>557 重言ではあるけど間違った日本語ではない といったほうがよかったね
559 :デフォルトの名無しさん :2024/04/05(金) 00:09:35.95 ID:Lw8p7kTG.net >>556 少ないね。 でも、そもそも今までCとアセンブラ以外はほぼ無い状態だったから、出てきただけマシ。 それに、少ないといってもシェアが広いアーキなので滑り出しは順調と言えるのかと。
560 :デフォルトの名無しさん :2024/04/05(金) 00:21:09.11 ID:dub3Z8tI.net 後発言語?
561 :デフォルトの名無しさん :2024/04/05(金) 00:50:16.55 ID:Lw8p7kTG.net 少し前まで次世代言語と言われてた程度には後発。 鯖向け言語で終わると思ってたら、マジでC/アセンブラの牙城を崩し始めるとは思わんかった。 むしろ崩し始めることすら無理だと思ってた。
562 :デフォルトの名無しさん :2024/04/05(金) 05:07:52.53 ID:CPVE6BHF.net >>559 状況も追い風なのかもね。 二の足踏んでたけど、armと生きていく決心をしてrust覚えるか。 先にrust身に付けてから、非対応アーキでC++導入したらメリットあるかな?
563 :デフォルトの名無しさん :2024/04/05(金) 08:11:28.72 ID:Lw8p7kTG.net Rust知ってれば安全性の高いシステム組めますと言うアピールになるし、C++にもその安全性のための知見は役立つ。 複数言語使えますってだけでもアピールになるしね。 Rustは多分仕事自体はまだ多くない。 これからアピールして増やしていく感じなので、両方使えてた方がいい。
564 :デフォルトの名無しさん :2024/04/06(土) 22:48:03.64 ID:4i1Gvjc8.net rustというものがありながらなぜ大部分のコードはC言語なのかを知るために現場に行くのもアリ
565 :デフォルトの名無しさん :2024/04/06(土) 23:06:32.76 ID:7kpWL/Du.net Rustが実用的になったのは2020年 それ以降の新規案件はRustになっている
566 :デフォルトの名無しさん :2024/04/07(日) 01:26:10.29 ID:Hmt7T+4v.net Rustへの移行は始まったばかりだからまだまだCが残っているのは当たり前
567 :デフォルトの名無しさん :2024/04/07(日) 10:55:29.15 ID:QD1FKAnH.net 絶壁の学習曲線。 貧弱なライブラリと人材。 早すぎる最適化。 しばらくは既存コード置き換えが中心だし、今後もプロジェクト初期のプロトタイピングで使われることは無いだろう。
568 :デフォルトの名無しさん :2024/04/07(日) 14:17:46.28 ID:vzw88H1n.net P系言語の糞思考に染まっていない初心者こそ 最初にRustを学ぶべき
569 :デフォルトの名無しさん :2024/04/07(日) 18:04:59.36 ID:Sj2oLPpI.net >>567 移植なんて無駄な作業はどの言語間でも行われることが少なく
570 :デフォルトの名無しさん :2024/04/07(日) 18:05:33.79 ID:nD4MmBKu.net 初手Rustは冗談抜きで2024以降だと選択肢に入るんじゃないか
571 :デフォルトの名無しさん :2024/04/07(日) 18:09:00.76 ID:Sj2oLPpI.net >>567 移植なんて無駄な作業はどの言語間でも行われることが少なく 通常はシステム更新で全体もしくは一部が作り直される時に別の言語が使われる Rustでも同様でほとんどがそれら含む新たな案件
572 :デフォルトの名無しさん :2024/04/07(日) 18:16:09.73 ID:TV6Dkj8m.net >>567 早すぎる最適化という意味不明なデタラメ書いているのは君一人だけ そしてRustを叩きたいためにウソを散りばめる
573 :デフォルトの名無しさん :2024/04/08(月) 02:24:45.08 ID:BHlkyWwA.net >>567 貧弱なライブラリとかエアプかよ そしてRustを叩きたいためにウソを散りばめる
574 :デフォルトの名無しさん :2024/04/08(月) 03:09:59.48 ID:BqmMXmQi.net 単なる感想を必死にウソ扱いして何がしたいんだコイツw
575 :デフォルトの名無しさん :2024/04/08(月) 11:48:22.86 ID:hzcejt90.net ライブラリはPythonと比べると流石に貧弱 特に数値計算とか物理・機械学習系 簡単な数値計算の時点でnumpy•scipyのようなデファクトがなく、雑魚が乱立している もっと高度な計算系ではもっと雑魚が乱立しているか、そもそもない
576 :デフォルトの名無しさん :2024/04/08(月) 12:32:47.46 ID:64QjhTLf.net >>575 キチガイアンチ すべての分野でライブラリが充実している言語は存在しない ある分野で一番充実している言語を棍棒にしたら他のすべての言語が負けるのは当たり前 そういう無意味なことをして叩いて楽しいか?
577 :デフォルトの名無しさん :2024/04/08(月) 13:16:14.61 ID:JoalanBl.net >>576 貧弱なことを指摘するのは叩きではない 俺はただ、「貧弱なライブラリとかエアプかよ」とか言っているエアプに現実を指摘しただけだ
578 :デフォルトの名無しさん :2024/04/08(月) 14:02:16.22 ID:7wfBslr8.net >>576 そこは「Rustなら〇〇分野のライブラリがどの他言語より充実している」と反論するところだろ。
579 :デフォルトの名無しさん :2024/04/08(月) 14:10:54.87 ID:7wfBslr8.net >>570 絶壁の学習曲線だから無理だろ。 moveを意識しないshared xor mutableの無い、Rc中心のEasyRustとかが無いと、fnひとつ呼び出せないんじゃない?
580 :デフォルトの名無しさん :2024/04/08(月) 14:43:36.67 ID:IC0NBj1d.net Crypto分野はRustが他言語よりも充実してるかもね
581 :デフォルトの名無しさん :2024/04/08(月) 15:06:06.34 ID:rjHvzTUw.net ライブラリの多さってイコールでユーザの多さなんだよ 更にいうとその言語開発者の意欲の表れでもある ライブラリが少ないという事はユーザが少ない 更に少ないユーザの中でも意欲の有る人間は少数って証明なんだよね
582 :デフォルトの名無しさん :2024/04/08(月) 15:43:54.88 ID:JoalanBl.net いやまあ数はあるんよ数は 意欲のある人はいるっぽいんだけど、デファクトとるようなライブラリってやっぱりそれなりの人数でちゃんと資金とって作られてるんだよな 資金取るのは個人の意欲だけじゃなくて、お金のある人を納得させる理屈が必要で、少し前までのRustは少なくとも数値計算の分野でそれが出来る言語ではなかったと思う
583 :デフォルトの名無しさん :2024/04/08(月) 16:39:42.51 ID:9qnuy4NE.net てかrustユーザーってnvidiaのcudaサポートの酷さにガチギレするような奴ばっかでしょ。 そんなんで数値計算ライブラリが入るわけがない。
584 :デフォルトの名無しさん :2024/04/08(月) 17:11:27.78 ID:7wfBslr8.net 初心者向けのSimplified Rustと、 c/c++ライブラリバインドを強化したAdaptor Rustあたりは欲しいなぁ。 Safe Rustじゃ難しそうだし。
585 :デフォルトの名無しさん :2024/04/08(月) 17:54:43.90 ID:JoalanBl.net ゼロからプログラム書くならSafe rustが一番簡単だよ こいつに従っているだけで割と見通しが良くてバグりにくいコードが書ける まあGoto 多用しているようなFortran おじいちゃんとは相性が悪いかもしれんが
586 :デフォルトの名無しさん :2024/04/08(月) 19:05:28.67 ID:ifgKIXku.net C++を完全に理解した者のための言語それがRust 故に誰も
587 :デフォルトの名無しさん :2024/04/08(月) 20:39:36.28 ID:cqL1RV99.net C++を使ったことないけど Rustで困ったことないな Rust理解で必要なことはポインタとスタックとヒープとRAIIくらいかな 所有権は単なるヒープ解放責任だから大したことではない 所有権を他へ譲渡しないとRAIIによって自動解放されるというだけの話 非常にシンプル
588 :デフォルトの名無しさん :2024/04/08(月) 21:02:11.65 ID:YkdU7kgc.net 所有権を複製するとか間違った事を言い続けてる人が良く言うわw
589 :デフォルトの名無しさん :2024/04/09(火) 00:09:53.71 ID:pItuq1gX.net >>588 それは俺じゃないぞ
590 :デフォルトの名無しさん :2024/04/09(火) 02:45:12.09 ID:hsAXyuRl.net >>589 誰だよお前。
591 :デフォルトの名無しさん :2024/04/09(火) 09:16:17.69 ID:OXfvzIgi.net 今のところ>>458 が一番面白い
592 :デフォルトの名無しさん :2024/04/09(火) 10:16:36.65 ID:Po0ZJOeT.net 昭和ギャグ? ちょっと意味がわかりません
593 :デフォルトの名無しさん :2024/04/09(火) 11:01:29.74 ID:cj+QXWpg.net 今どきイジりを面白いとか、イジメ肯定派かよ。
594 :デフォルトの名無しさん :2024/04/09(火) 13:18:19.32 ID:9AcR/8+u.net 進化論肯定派じゃないの 人を淘汰することを志している
595 :デフォルトの名無しさん :2024/04/09(火) 17:18:23.86 ID:+rnauHt3.net カチョー「???」じゃなくて カチョー「で?」なら共感できたかも
596 :デフォルトの名無しさん :2024/04/10(水) 01:14:02.81 ID:/k7xUJZy.net rustだいぶ分かってきたつもりだけど ライフタイムとジェネリクスとクロージャが一斉に襲いかかってくると無理 好きな言語だけど世の中にはプログラミング言語に強い興味を示す奴が稀なので厳しいなぁと感じる
597 :デフォルトの名無しさん :2024/04/10(水) 08:03:56.89 ID:ltqciZ07.net >>592 進捗報告相手が課長というのが昭和かもな そんな会社で働きたくない
598 :デフォルトの名無しさん :2024/04/10(水) 11:01:40.54 ID:5Js//1cu.net >>596 moonbit くらいならどうかな?
599 :デフォルトの名無しさん :2024/04/10(水) 11:35:35.51 ID:AS+TZoYk.net >>596 それぞれ理解していれば組み合わさって困ることはないんじゃないかな Rust特有のライフタイム注釈は構造体なら「参照を持ってるよ」の印で関数なら「この引数の参照は返り値の参照に対応するよ」の印であとは有効期間を満たすだけなど
600 :デフォルトの名無しさん :2024/04/10(水) 16:55:22.63 ID:yZA7mDLP.net Rustってfunctionをfnって略すくらい気が短いのに、なんでメソッド定義時にはわざわざselfみたいなPython臭いの入力しないとだめなんですか?めんどいんですけど
601 :デフォルトの名無しさん :2024/04/10(水) 17:30:31.18 ID:Fk7YBwaR.net メソッドをそうでない普通の関数と区別するためにはなんらかのマークは要るじゃろ。
602 :デフォルトの名無しさん :2024/04/10(水) 17:38:51.91 ID:t7JkSWKp.net self/ mut self/&self/&mut selfの区別もいるしな self自体これ以上短くしてもよくわからん単語になるしまぁ妥当では
603 :デフォルトの名無しさん :2024/04/10(水) 17:52:25.08 ID:5Js//1cu.net C++ の ref-qualifier とか無理のある文法だもんな。 そこに書くんか!? という変な驚きがある。 引数の一種ということにしたほうがかなり単純でよい。 実際、 C++ でも C++23 から this を明示的な引数に取れる文法が追加された。 (deducing this)
604 :デフォルトの名無しさん :2024/04/10(水) 17:58:48.34 ID:Q64PiueS.net RustでPython実装すりゃ良いんじゃね
605 :デフォルトの名無しさん :2024/04/10(水) 18:34:01.75 ID:3h5gXXiJ.net >>602 普通に全部ダサいんだよなあ 何とかならなかったのかとならなかったのかとならなかったのかと…
606 :デフォルトの名無しさん :2024/04/10(水) 19:34:40.80 ID:8DE+tVvz.net selfより短ければ良いのか、それともC++みたいに省略できてしまってどこで定義されてるのかようわからんくなるのが好きなのか
607 :デフォルトの名無しさん :2024/04/10(水) 19:44:04.66 ID:y0DX5npz.net ぜひとも >>605 の考える最高にイケてる構文を教えてほしい Rustを今から変えるのは無理でも、後継言語に採用されるかもしれんし
608 :デフォルトの名無しさん :2024/04/10(水) 19:47:55.68 ID:IjfZ+vUr.net >>605 nimの関数呼び出しルール 関数名(第一引数,第二引数...) 第一引数.関数名(第二引数...) で第一引数がself相当 が一番スマートかと。
609 :デフォルトの名無しさん :2024/04/10(水) 20:06:03.20 ID:AS+TZoYk.net >>605 むしろ>>602 はそれらの区別のためにもselfは必須と言ってるようにみえる さらに構造体などフィールド名と関数内の変数名との区別のためにもselfは欲しい 現状のRustの仕様がベストかな
610 :デフォルトの名無しさん :2024/04/10(水) 21:28:15.02 ID:8DE+tVvz.net selfじゃくてthisならC++マニアも納得
611 :デフォルトの名無しさん :2024/04/10(水) 21:34:35.54 ID:6SjCdg5T.net >>608 nimを知らないけど、Rustのassociated functionもその二種類の呼び出し方法がとれる点は同じだね Vec::push(&mut vec, 123); (&mut vec).push(123); vec.push(123); この&mutを省略できてRust便利
612 :デフォルトの名無しさん :2024/04/10(水) 21:37:52.75 ID:Mpv09JwO.net thisはたまにselfの代理で使われてるな Rc::into_innerとか
613 :デフォルトの名無しさん :2024/04/10(水) 23:19:28.12 ID:AS+TZoYk.net deref後のinto_inner適用と区別のため 敢えてself使わないことでメソッド呼び出し形式をできなくして 明示的にRc::into_inner呼び出しさせるパターンだね
614 :デフォルトの名無しさん :2024/04/10(水) 23:45:41.84 ID:Fk7YBwaR.net メソッドを呼び出すことと関数の第一引数に渡すことを同一視する構文は LISP 用に作られたオブジェクトシステム new flavors でやってた。
615 :デフォルトの名無しさん :2024/04/11(木) 02:11:03.37 ID:4f6XcC0j.net それは同一視というか構文が1つしかないだけでは
616 :デフォルトの名無しさん :2024/04/11(木) 02:14:15.06 ID:7FNbL3Xb.net 呼び出し時には与えない引数って紛らわしくね?
617 :614 :2024/04/11(木) 02:45:03.24 ID:C4qhk0zm.net >>615 メッセージを送る構文と関数呼出しの構文の両方があって構文糖として扱える仕組みになってたという話。 new flavors の前に flavors というのがあって、それはメッセージを送る構文しかなかったのだけど new flavors で改良 (かどうかわからんけど) された。
618 :デフォルトの名無しさん :2024/04/11(木) 04:57:52.23 ID:r6y9Ju0a.net >>616 むしろ逆かな target.method(arg1, arg2, ...)という targetへのメソッドコールを実現するのを関数で表すと method(target, arg1, arg2, ...)とする言語が多い Rustでも同じでこのtargetをselfと書く targetは送る側から見た視点 selfは受け取った側から見た視点 各実装は受け取った側でなされるためself
619 :デフォルトの名無しさん :2024/04/11(木) 08:24:38.80 ID:McLA6Ner.net UFCSは第一引数を1つ目だからというだけの理由で特別扱いするのが気持ち悪いんだよな レシーバとして扱われるなら構文上も特別であってほしい
620 :デフォルトの名無しさん :2024/04/11(木) 08:39:59.21 ID:UjbgXeUt.net >>619 何が気持ち悪いのかさっぱりわからない まず、全ては関数呼び出しになりそれ以外の方法はない、というのはいいよね? 次に、その関数呼び出しでのレシーバの渡し方は最初の引数になる、というのも自然だよね? ほとんどの言語がこの方式なのに何を気持ち悪がっているのだろう
621 :デフォルトの名無しさん :2024/04/11(木) 08:49:57.16 ID:azFLg2co.net 言うほどほとんどの言語がこれか? pythonは後付けでOOPぶっこんだからただの関数の引数にSelfなんだ これがPythonいまいちだなって思うところ c++も似た様な理由でstaticでthis 後発で考慮する余裕あるのにそれを引っ張ってる
622 :デフォルトの名無しさん :2024/04/11(木) 09:02:17.34 ID:NXydgA7G.net >>621 君の感性がおかしいんじゃね? NimもZigもRustもPythonと同じ標準方式 foo(receiver, arg1, arg2, ..) または receiver.foo(arg1, arg2, ..)
623 :デフォルトの名無しさん :2024/04/11(木) 09:02:43.98 ID:7FNbL3Xb.net >>618 なるほどちょっと納得した
624 :デフォルトの名無しさん :2024/04/11(木) 09:11:33.28 ID:azFLg2co.net >>622 実質Pythonフォロワーを含めて言われても…
625 :デフォルトの名無しさん :2024/04/11(木) 09:14:09.83 ID:azFLg2co.net C言語のときはOOPじゃなくてただの関数の第一引数に構造体を指定してた それがOOP言語になって指定不要になった それがまたC言語時代に逆戻り
626 :デフォルトの名無しさん :2024/04/11(木) 09:15:22.73 ID:NXydgA7G.net >>624 何を言ってるのかわからん 文句を言うなら望ましい代案を出してみて
627 :デフォルトの名無しさん :2024/04/11(木) 09:17:05.47 ID:azFLg2co.net あらかじめ書いておくけどreceiver.Foo()じゃないメソッドがあるのは receiverがNullの可能性がある場合でそう設計されてただけ
628 :デフォルトの名無しさん :2024/04/11(木) 09:20:43.92 ID:NXydgA7G.net 代案を出せないってことはRustに言いがかりをつけてるだけだな
629 :デフォルトの名無しさん :2024/04/11(木) 09:24:05.56 ID:azFLg2co.net 別に他のOOP言語のように関数にマークつけてこれはこのインスタンスのメソッドですよと言えばいいだけ その表記は時間をかけて考えたらいい
630 :デフォルトの名無しさん :2024/04/11(木) 09:30:34.30 ID:cvuvfjXO.net >>625 レシーバは必ず必要 Goでも func (receiver ReceiverType) Foo(引数…) { return receiver.xxx + receiver.yyy } と書く レシーバ指定不要という主張は理解できない
631 :デフォルトの名無しさん :2024/04/11(木) 09:45:56.75 ID:gYo8nOa5.net レシーバの名前を自由につけられると人によってバラバラで読みづらいんだよな selfなら必ず揃うし予約語としてシンタックスハイライトされるのもいい
632 :デフォルトの名無しさん :2024/04/11(木) 09:51:28.66 ID:azFLg2co.net いやいやw 無知って怖いねとしか…
633 :デフォルトの名無しさん :2024/04/11(木) 09:52:17.20 ID:azFLg2co.net >>630
634 :デフォルトの名無しさん :2024/04/11(木) 10:19:57.47 ID:UmgPKlgb.net UFCSはフリー関数でもメソッド風に呼び出せる機能のことでRustやその他多くの言語のメソッド呼び出しとは似て非なるもの >>619 はそれを分かった上でNimについて書いてるのかもしれないけど>>620 や>>622 は明らかに誤解してる
635 :デフォルトの名無しさん :2024/04/11(木) 10:33:59.60 ID:Nlu6ipA3.net >>631 そう言われるとRustの仕様がベストなのかな レシーバに名前を付けないと名前空間の分離ができなくて レシーバに名前を自由に付けられると読みづらくて
636 :デフォルトの名無しさん :2024/04/11(木) 11:00:57.82 ID:azFLg2co.net IDころころお爺さんは明らかに話を理解できないな
637 :デフォルトの名無しさん :2024/04/11(木) 11:23:46.71 ID:CaCoKmZ3.net Rustは小文字selfが値、大文字Selfが型を示していて使いやすいよな 型指定にSelfやSelf::Itemなど使えるだけでなく Self::CONSTANT_NAMEやSelf::function_without_self()などの呼び出しもできる Selfによって自分自身であるとわかりコードが読みやすい 型名変更の影響も受けず読みやすいメンテしやすい ダメな言語だと以下のダメなパターンがある ・Selfの代わりに型名を書かなくてはいけない言語 (自分自身だとわかりにくくメンテ性も悪い) ・Selfの代わりにself(やthis)を用いてしまう言語 (値と型の区別がつかない) ・Selfを使わずに名前空間の区別がない言語 (間違いが起きやすく自分自身だとわかりくくメンテ性が悪い)
638 :デフォルトの名無しさん :2024/04/11(木) 11:57:27.19 ID:17a5lmDN.net 関係ない長文でごまかすフェーズに入ってるってことは内心恥ずかしくて死にそうになってるんやろうな……
639 :デフォルトの名無しさん :2024/04/11(木) 11:57:34.08 ID:6x2Zth+c.net 複オジは見えてる範囲が狭過ぎる だから長文になればなるほど勘違い度や害悪度が高まる
640 :デフォルトの名無しさん :2024/04/11(木) 12:47:47.10 ID:ZruVErXu.net 自分が使ってきた特殊な仕様の言語に慣れ親しんでいると 一般的なの仕様のRustに違和感を感じて文句をつけたくなる気持ちはわからんでもない Rustを叩く前に視野を広く持つべきだな Rustの仕様はよく考えられ機能的に洗練されている
641 :デフォルトの名無しさん :2024/04/11(木) 12:59:00.66 ID:AZdBjU6j.net >>640 Rustに無いからといってUFCS叩くのはさすがにアホかと。
642 :デフォルトの名無しさん :2024/04/11(木) 13:15:55.80 ID:4f6XcC0j.net そんなことよりError::sourceの戻り値に'static要求されるのってなんでなん
643 :デフォルトの名無しさん :2024/04/11(木) 15:57:20.01 ID:R8LZpbjl.net >>642 エラー返す時に参照してるリソースをつかんだままにしたくないからじゃない
644 :デフォルトの名無しさん :2024/04/11(木) 15:59:23.14 ID:v1XXdeLJ.net くだらないレスは頻繁にするのにまともな質問が来ると急に黙るの面白い
645 :デフォルトの名無しさん :2024/04/11(木) 16:41:03.54 ID:KhnNkcJ8.net まともな質問にいつものノリで適当に答えて嘘だったら良くないしね
646 :デフォルトの名無しさん :2024/04/11(木) 17:01:08.25 ID:TWMZ6q+3.net そっか 俺の答えも間違ってたしな 正しくはdowncastのために必要らしい 詳しくはfix_errorのRFC見て
647 :デフォルトの名無しさん :2024/04/11(木) 17:41:58.72 ID:McIjmFt1.net Playgroundがwebsocket接続のタイムアウトエラー(504:Gateway Time-out)で全然動かないんだが俺環?
648 :デフォルトの名無しさん :2024/04/11(木) 17:48:38.15 ID:McIjmFt1.net 動き出した サーバー側の問題っぽいな https://github.com/rust-lang/rust-playground/issues/831
649 :デフォルトの名無しさん :2024/04/11(木) 18:55:11.06 ID:4f6XcC0j.net downcastなんて別にしないからいらねーよって思ったけど そういえば内部で似たようなことやってるあれがあったな、どっちかっていうとあれのためか ヒントありがとう
650 :デフォルトの名無しさん :2024/04/11(木) 19:06:32.42 ID:VFM//2+p.net 複おじはc++も使ってなかったんだな
651 :デフォルトの名無しさん :2024/04/11(木) 20:25:23.50 ID:81s1BzdD.net >>641 UFCSはメソッド名空間の汚染であるため、まともな言語では採用されていない。 RustはUFCSを採用しないだけでなく、更に厳しく孤児ルールによってメソッド名空間の汚染を防いでる。 Rustでのメソッド追加拡張は、そのための新たなトレイトを用意することで、その利用空間に限定して安全に行うことができる。
652 :デフォルトの名無しさん :2024/04/11(木) 20:52:12.80 ID:AZdBjU6j.net >>651 UFCSはそもそもメソッドとか無いんだから、ありもしないメソッド空間の汚染とか考えるだけ無駄。 それに、メソッド呼び出しは人間の思考パターン(大域から局所に絞り込む)に従った自然な記述方法なんだから、それを拡張困難なメソッドだけに限定するのは酷い制約かと。カス文法のPythonを思い浮かべますな。
653 :デフォルトの名無しさん :2024/04/11(木) 21:02:41.98 ID:81s1BzdD.net >>652 Rustでメソッド呼び出しは拡張困難ではなく、拡張用トレイトを自由に新たに用意することで、他への汚染を招かずに安全に拡張できる。 そのためUFCSのような愚かな方式を採る必要がない。
654 :デフォルトの名無しさん :2024/04/11(木) 21:15:01.99 ID:mF0oHAZm.net 答えを教えてもらっているのにヒントありがとうというオジさんw
655 :デフォルトの名無しさん :2024/04/11(木) 21:16:29.71 ID:2g+gCFiF.net メソッド名空間www
656 :デフォルトの名無しさん :2024/04/11(木) 21:54:13.50 ID:AZdBjU6j.net >>653 それって単にメソッドだけ特別に名前空間を管理していという話で、UFCSだから問題になるという話では無いな。 もっとUFCSならではの問題点を指摘してくれ。 せめて関数が左作用ならUFCS捨ててもいいけど、どの言語も馬鹿のひとつ覚えで右作用を採用するからメソッドとかUFCSが重宝される。
657 :デフォルトの名無しさん :2024/04/11(木) 23:54:23.85 ID:A4VQpdsZ.net アラビア語でコーディングすれば、入力左から右へ進むから右作用が思考の順になるぜ アラビア語おすすめ
658 :デフォルトの名無しさん :2024/04/12(金) 00:40:05.77 ID:fvGN/jjJ.net >>656 それはメソッド呼び出しのメリット モジュール化や結合の観点からも最初からメソッド定義していくのが正しい UFCSはそれが出来ないあるいは間違ったプログラミング設計によりフリー関数を多数作ってしまった間違った環境でメソッド呼び出ししたくなった時のみ必要とされる 具体的には歴史的な負の遺産でボロボロなC++が該当する そのためC++ではUFCSを導入しようと今も悪あがきをしている ほとんどの言語にUFCSがないのはそんなものを必要としないためだ
659 :デフォルトの名無しさん :2024/04/12(金) 00:44:02.94 ID:tVNhffJ+.net モジュール化や結合の観点から、関数が一つの変数の型に紐づくのがそんなに優れているとはあんま思えんけどなあ RustのAdd演算子とかrhsとlhsの型が違う時は演算子がlhsのみに紐つくことになってかなりキモい
660 :デフォルトの名無しさん :2024/04/12(金) 02:47:17.34 ID:DYhqcHWh.net それはAddが交換法則の成り立つ二項演算子だからそう見えるにすぎない AddAssignやSubやShlなど多くの演算は非対称
661 :デフォルトの名無しさん :2024/04/12(金) 04:21:38.21 ID:tVNhffJ+.net いや別にSubでもDivでも左のみに紐づいているのはキモい
662 :デフォルトの名無しさん :2024/04/12(金) 04:49:28.47 ID:rUQyilnM.net >>658 やっぱりUFCSじゃなくて名前空間の設計の問題にしか見えんね。 例としてc++を挙げているが、名前空間を使っているライブラリとかで問題になっている事例てあったっけ? グローバルのフリー関数は影響範囲が広すぎて問題を引き起こすというなら、Rustのトレイルと同様に適切な名前空間を用意しないと関数を定義できないようにすればいいかと。
663 :デフォルトの名無しさん :2024/04/12(金) 05:26:42.25 ID:CIaMPOtu.net >>662 トレイルではなくトレイト トレイトは名前空間を用意するものというより、トレイトをuseすることでそのトレイトにより実装されるメソッドが使えるようになるだけ
664 :デフォルトの名無しさん :2024/04/12(金) 07:31:40.11 ID:rUQyilnM.net >>663 だったらなおさら>662だけの話かと。名前空間で「メソッド空間」を管理するのをRustは「トレイト」で管理しているだけにしか見えないね。
665 :デフォルトの名無しさん :2024/04/12(金) 12:27:40.08 ID:OadUyd3M.net >>659 >モジュール化や結合の観点から、関数が一つの変数の型に紐づくのがそんなに優れているとはあんま思えんけどなあ 同意
666 :デフォルトの名無しさん :2024/04/12(金) 12:33:34.40 ID:rAepnpk2.net >>664 Rustはそうやってきちんと管理できつつ便利でいいよなー 他の言語も導入すればいいのに
667 :デフォルトの名無しさん :2024/04/12(金) 12:43:39.99 ID:6xQx5uEa.net >>665 オブジェクト指向を全否定するキチガイか クラスのある言語もクラスのないGoやRustなどの言語も 一つの変数の型に関数を紐づけることがプログラミング言語の中核機能だ
668 :デフォルトの名無しさん :2024/04/12(金) 13:04:32.76 ID:qd6Rxygz.net とりあえず感覚で一行目から罵倒する人
669 :デフォルトの名無しさん :2024/04/12(金) 15:24:23.71 ID:XC+pkKeZ.net >>667 >一つの変数の型に関数を紐づけることがプログラミング言語の中核機能だ オブジェクト指向前提思考?
670 :デフォルトの名無しさん :2024/04/12(金) 16:22:22.83 ID:RDQRwL9V.net >ほとんどの言語がこの方式なのに何を気持ち悪がっているのだろう からの >UFCSはメソッド名空間の汚染であるため、まともな言語では採用されていない。 schizoかな?
671 :デフォルトの名無しさん :2024/04/12(金) 17:02:05.38 ID:oSrgtnnN.net それらの件でもRustの仕様が優秀すぎ
672 :デフォルトの名無しさん :2024/04/12(金) 20:51:13.79 ID:NYkXEvAJ.net >>670 虚言癖などと同じパーソナリティ障害の一種だから生温かく見守ってやれ
673 :デフォルトの名無しさん :2024/04/12(金) 22:18:23.28 ID:HgYc1X5O.net おじいちゃんは昼だけ起きてて 夕方を過ぎると寝てしまう
674 :デフォルトの名無しさん :2024/04/12(金) 22:50:23.70 ID:3nYhUDoK.net RUSTがトレンドに!!
675 :デフォルトの名無しさん :2024/04/12(金) 23:58:18.71 ID:lpyrPPhz.net >>667 つジェネリック
676 :デフォルトの名無しさん :2024/04/13(土) 04:39:15.20 ID:0YGiYUZr.net ジェネリックにも同じように安全に適用できるのはRustにトレイト境界があるおかげか
677 :デフォルトの名無しさん :2024/04/13(土) 07:36:48.57 ID:beXAxXwF.net トレイト境界はc++ conceptみたいに同じ関数集合ならOKなんだっけ? 柔軟性のために外延性は欲しいところ。
678 :デフォルトの名無しさん :2024/04/13(土) 08:07:59.96 ID:S51MIqUj.net 異なる型間の共通項をトレイトとして切り出すだけでよく コードを美しく整理して保守性を高めやすい
679 :デフォルトの名無しさん :2024/04/13(土) 13:32:34.24 ID:OrtqC7Lq.net 敬称ないせいで苦労してるんだってな
680 :デフォルトの名無しさん :2024/04/13(土) 13:36:34.54 ID:F3jinTSj.net 143 デフォルトの名無しさん 2024/04/07(日) 19:27 純関数型言語でなくても モダンなプログラミング言語 Go、Rust、Zig、Nim、Julia、Elixirなどは クラスおよびその継承を言語仕様から排除しておりクラスは存在しない それら各々の言語は全く異なる方針を採っている言語だがクラス排除だけは全てが同じ方針である クラスとその継承は悪手であるとプログラミング言語界では結論が出ている
681 :デフォルトの名無しさん :2024/04/13(土) 16:56:52.49 ID:L60jXWVE.net 継承がなくても構造体にメソッドついてたら実質クラスだろ 関数に構造体渡してたらそれはクラスじゃないけど
682 :デフォルトの名無しさん :2024/04/14(日) 23:56:10.96 ID:RjsA2T1t.net >>681 構造体にメソッドが付くことはカプセル化と言う クラス=カプセル化+実装継承 なのでクラスとカプセル化は異なる このクラスを成り立たせている実装継承が悪であるためにモダンな言語群がクラスを採用しなかった 実装継承とは具体型が別の具体型を継承することを指す クラスでは派生クラスが基底クラスを継承するため悪の実装継承となる 正しい方法はインタフェイスやトレイトなどの抽象型からのみ継承する つまりクラスを完全に排除できるためモダンな言語群にクラスはない
683 :デフォルトの名無しさん :2024/04/15(月) 00:05:55.58 ID:R9iMDmBn.net 用語も色々。 Rust で言うところのトレイトみたいなやつを Haksell とかでは型クラスって呼んでるし、 JavaScript のクラスの実体は (特定のプロトタイプに紐づいたオブジェクトを生成するための) 関数。 極論すればクラスと名付けたものがクラス。 Rust でクラスと呼んでない以上はもう別概念として捉えるしかしょうがないだろ。 C++ のクラス的なことの一部を Rust でも「可能ではある」というという主張なら賛成するけど、 クラスとは何かを定義せずにクラスかどうかを論じても無意味。
684 :デフォルトの名無しさん :2024/04/15(月) 00:26:07.32 ID:rd9697wK.net 型クラスとクラスは全く異なるので混乱しない クラスとはクラス継承すなわち親クラスから子クラスへの実装継承できるものを指す JavaScriptはプロトタイプを親として実装継承するためクラス 一方でRustにクラスはない
685 :デフォルトの名無しさん :2024/04/15(月) 01:47:00.44 ID:YLFAz6O4.net クラスとは何か?継承とは何か? こういう基本的な概念を特定言語の実装から離れて理解しようとしない限り何を言っても虚しい >>681 が一番まとも
686 :デフォルトの名無しさん :2024/04/15(月) 01:58:25.85 ID:CPtYka/u.net 話は非常に単純 具体的な型から具体的な型への継承が実装継承でこれがよくない classは具体的な型superclassから具体的な型subclassへの継承があるから実装継承 interfaceやtraitは具体的な型ではなく抽象的な型なので該当しない 最近の言語がclassのみ採用しなかった理由はその違い
687 :デフォルトの名無しさん :2024/04/15(月) 02:39:20.65 ID:zOelqs9y.net RustにはJavaのクラスはありません RustはJavaではないからです あたまいいね
688 :デフォルトの名無しさん :2024/04/15(月) 03:16:04.95 ID:0QcDOjSQ.net Javaの生みの親であるJames Goslingも、 「もう一度最初からJavaを作り直すとしたら、どこを変更したいですか?」に対して、 「クラスを除外するでしょうね」と答えている。 その理由は、クラス継承が実装継承となっているためで、この設計を後悔していて、インターフェースによる継承が望ましいと述べている。
689 :デフォルトの名無しさん :2024/04/15(月) 08:31:26.40 ID:Mqs/ngjj.net クラスのようなものでいいよ
690 :デフォルトの名無しさん :2024/04/15(月) 10:16:50.96 ID:dcBtWsLv.net バカの一つ覚えの相手をしても時間の無駄
691 :デフォルトの名無しさん :2024/04/15(月) 12:54:52.68 ID:f4iHJAq/.net クラス継承のある言語でも今はクラス継承を使わない設計するのが良いとされてるので要らんよな
692 :デフォルトの名無しさん :2024/04/15(月) 21:09:43.00 ID:97bFGSba.net それは単に使い分けが出来ない馬鹿な子向けの説明だぞ
693 :デフォルトの名無しさん :2024/04/16(火) 07:27:41.72 ID:10PaZXAR.net >>691 言語仕様としてあった方が良いということ。
694 :デフォルトの名無しさん :2024/04/16(火) 07:42:24.51 ID:KU96szRc.net 馬鹿が使うとクソになる仕様がある言語は馬鹿をチームに入れただけで開発が即破綻するからクソ
695 :デフォルトの名無しさん :2024/04/16(火) 08:43:42.78 ID:OvO8gS8m.net Javaの生みの親も言ってるようにクラス継承の機能はない方がいい なくても困らない あると問題を引き起こす
696 :デフォルトの名無しさん :2024/04/16(火) 09:30:25.53 ID:YlYBNC7y.net そういうのは話半分に聞いておけばいいよ nullを使ったのは失敗だったとか 後からそれらしいことを言ってるだけ javaはクラスと継承が無くなったらまともに機能しない interfaceにデフォルト実装がなかったので全部自前かコンポジションで実装することになったはず
697 :デフォルトの名無しさん :2024/04/16(火) 09:50:49.42 ID:pgei3+18.net >>696 interfaceにデフォルト実装を後から入れたので問題なくなった そうなるとclass継承は不要
698 :デフォルトの名無しさん :2024/04/16(火) 09:55:41.24 ID:YlYBNC7y.net 最初はなかったしずっと取り入れなかったのはそれがJAVA風じゃなかったから 今JAVAが生き残ってるのは最初の設計思想が世間に受け入れられたからであって 後から○○無くせばよかったと言うのは誤りで浅はか NULLを無くせばよかったと言うが当時メジャーな手法でそれの代替手段がなかったのと同じ
699 :デフォルトの名無しさん :2024/04/16(火) 10:21:05.77 ID:pgei3+18.net 今となってはclass継承は廃止でいい
700 :デフォルトの名無しさん :2024/04/16(火) 11:59:36.87 ID:NkOUpCFP.net インターフェイスにも集合で言うところの外延性は欲しいところ。
701 :デフォルトの名無しさん :2024/04/16(火) 13:49:22.28 ID:DzgCvS5T.net そういうの使いたいならTSがいいよ
702 :デフォルトの名無しさん :2024/04/16(火) 14:56:34.55 ID:vP0l1V0c.net 具体的なデメリットって何なの?
703 :デフォルトの名無しさん :2024/04/16(火) 15:29:25.10 ID:ePcpSD5e.net ダサい
704 :デフォルトの名無しさん :2024/04/16(火) 20:45:11.55 ID:scEyspJl.net そういう感覚的なもの?
705 :デフォルトの名無しさん :2024/04/16(火) 22:20:54.32 ID:pbIQ4i0L.net 基底クラスで保証してる内部条件を継承クラスで壊されやすい Javaは基本的に全部オーバーライド可能でprivateとfinalで変な継承を抑えてたけど C#はabstract/virtualかつsealedでない要素だけオーバーライド可能になってたと思う 古い知識だから最近の動向は知らない
706 :デフォルトの名無しさん :2024/04/17(水) 08:15:23.25 ID:eua5YI/M.net Unreal EngineがRist対応するんだってね
707 :デフォルトの名無しさん :2024/04/17(水) 16:42:11.69 ID:eua5YI/M.net Ristってなんだ、Rustだた
708 :デフォルトの名無しさん :2024/04/17(水) 21:06:33.89 ID:ZcFRYo3q.net Rast Rist Rest Rost
709 :デフォルトの名無しさん :2024/04/17(水) 21:31:42.40 ID:O0zLY4aF.net Risp
710 :デフォルトの名無しさん :2024/04/18(木) 23:48:18.11 ID:mul2o/Jt.net >>706 時代の流れだな
711 :デフォルトの名無しさん :2024/04/19(金) 17:19:41.25 ID:QdSz4ItG.net 隙間作って床下チェスト収納ってできなくなった?動画みてるけどうまくできん
712 :デフォルトの名無しさん :2024/04/20(土) 17:39:26.03 ID:pCmD4UWo.net shift-jisのファイルをBufReaderで1行ずつ読み込もうと思ったら無理でOKが流れてこない 全部読んでデコードして\nで切り分けるしかないの?
713 :デフォルトの名無しさん :2024/04/20(土) 17:53:01.46 ID:AAPU1iqE.net read_lineはutf-8じゃないと無理だけどread_untilならバイト列で1行ずつ取れそう
714 :デフォルトの名無しさん :2024/04/20(土) 22:11:31.95 ID:pZNdwQSZ.net >>712 encoding_rs_io::DecodeReaderBytesBuilderでsjisをdecodeするreaderを作る あとはreader.lines()で同じ
715 :デフォルトの名無しさん :2024/04/20(土) 22:28:20.55 ID:pZNdwQSZ.net std::io::BufReader::new(encoding_rs_io::DecodeReaderBytesBuilder::new().encoding(Some(encoding_rs::SHIFT_JIS)).build(std::fs::File::open(SJIS_FILE)?)).lines()
716 :デフォルトの名無しさん :2024/04/21(日) 07:15:48.69 ID:QKVewSeW.net BufReaderもFile::openもそのまま使える点がいいね
717 :デフォルトの名無しさん :2024/04/21(日) 10:23:00.52 ID:Be3/0qjS.net >>715 ありがとうございます 動作確認しました ちょっと仕組みがむずかしいですね
718 :デフォルトの名無しさん :2024/04/21(日) 18:25:05.39 ID:GAd5jyBU.net decoderが挟まるだけだよ // UTF8の場合 let file = File::open(path)?; let reader = BufReader::new(file); for line in reader.lines() { // SJISの場合 let file = File::open(path)?; let decoder = DecodeReaderBytesBuilder::new() .encoding(Some(SHIFT_JIS)) .build(file); let reader = BufReader::new(decoder); for line in reader.lines() {
719 :デフォルトの名無しさん :2024/04/22(月) 06:09:19.12 ID:kZ9sSSe5.net バッファリングせず丸ごと贅沢にメモリ使っていいなら単純 let bytes = fs::read(path)?; let (s, _, _) = SHIFT_JIS.decode(&bytes); let reader = BufReader::new(s.as_bytes()); for line in reader.lines() {
720 :デフォルトの名無しさん :2024/04/22(月) 20:07:02.52 ID:g+YSHIF5.net コマンドラインからファイル名取るようにしたらパニック windowsで文字コードが違うかららしいけどこういうバッドノウハウを開発者に積み重ねていかないと使えないのはめんどい
721 :デフォルトの名無しさん :2024/04/22(月) 20:46:10.62 ID:ZfX6SpnE.net 何を言ってんのw
722 :デフォルトの名無しさん :2024/04/22(月) 21:19:42.71 ID:g+YSHIF5.net 知らないとそういう反応するんだろうけど std::env::args_osを使ってOsStringを取って対処する必要があるんだよ 勉強になっただろ?
723 :デフォルトの名無しさん :2024/04/22(月) 21:24:48.26 ID:g+YSHIF5.net 日本人だから日本語名が付いたファイルを扱う機会に恵まれてるからこういうことに出会える アメリカ人だったらこういうのに出会わないでコーディングしてリリースしてるだろう 世界中で使ったらパスの問題で落ちるプログラムがガンガン量産されている
724 :デフォルトの名無しさん :2024/04/22(月) 23:12:07.98 ID:ljq3CdpU.net >>722 チュートリアルレベルの基礎を バッドノウハウwとか 積み重ねでいかないといけないwとか 言ってるから何言ってんのwになる
725 :デフォルトの名無しさん :2024/04/22(月) 23:32:38.83 ID:cr/ZTax6.net >>720 Rustのパニックはどの関数で何をした時に発生するかすべてドキュメントに明記されてるのでパニックはプログラミングした側に問題がある さらにパニックがソースコードの何行目のどの場所で起きたのかもわかるのですぐにそのバクを調査できる まずは基礎知識を身につけよう >>722 std::env::argsのドキュメントにどういう時にパニックが起きるか書いてある さらに対処方法はargs_osを使えと明記されている ドキュメントを見よう
726 :デフォルトの名無しさん :2024/04/22(月) 23:35:51.77 ID:g+YSHIF5.net >>724-725 こういう低能がありがたがるんだろうな 信者としか言いようがないw
727 :デフォルトの名無しさん :2024/04/22(月) 23:42:55.88 ID:g+YSHIF5.net リリースした後の実行時のpanicを有り難がる信者 Rustのライブラリの思想がいまいち馴染みにくいと言うか素人が作るとこうなりますと言う見本
728 :デフォルトの名無しさん :2024/04/22(月) 23:57:01.81 ID:kZ9sSSe5.net >>722 Rustではそんな個別の知識を知らなくてもpanicさせた関数が分かるから その関数のドキュメントのpanicの項目を見れば明記されてる 他の言語と比べても良い環境
729 :デフォルトの名無しさん :2024/04/23(火) 00:03:29.34 ID:aheV4X/O.net 馬鹿と話しててもらちが開かない 世界中で使ったらパスの問題で落ちるプログラムがガンガン量産されているのは事実 お前らそれを一個一個プルリク送ったりしてるのか?
730 :デフォルトの名無しさん :2024/04/23(火) 00:13:45.98 ID:aheV4X/O.net 所有権とか導入してバグを静的に弾こうとしてる割にはこういうところではガバガバ 世界中で英語じゃないwindows環境でpanicが起こるコードが蔓延してる 非合理的
731 :デフォルトの名無しさん :2024/04/23(火) 00:34:48.42 ID:tNw43TTr.net そんなことより The Embedded Rust 読み始めたんです。 冒頭からリンカで割り込みベクタマップの取り方やら panic 無効にしての main 関数導入やら、HAL は自分でこさえるんだよね?と言わんばかりの内容。 おおむかしのMCU開発環境みたいで嫌いじゃないけど、arch 対応してないと敷居高いねこれ。
732 :デフォルトの名無しさん :2024/04/23(火) 09:44:34.04 ID:SlAsUTut.net 公式チュートリアルすらまともに読めないお馬鹿さんは自分が使う道具を間違えててもそれを言語のせいにしたがる プラスドライバーを使うべき状況でマイナスドライバーを使って使いにくいじゃねーかこんな道具は非合理的などと言い出す ヤバすぎね?
733 :デフォルトの名無しさん :2024/04/23(火) 11:06:58.83 ID:PMnHeW+x.net >>725 なんでコンパイル時にエラーにできないんだろう? Rustのポリシーからすれば安全優先でargs_osだけにしてargsは削除すべきでは? c++じゃあるまいに、コマンドラインのデータが常に正しいunicodeだと信用するプログラムを書けるとか、セキュリティーホールになりかねんと思うけど。
734 :デフォルトの名無しさん :2024/04/23(火) 12:06:18.33 ID:cfnwg7MD.net panicは安全ですヨ
735 :デフォルトの名無しさん :2024/04/23(火) 12:11:09.83 ID:r76fNggU.net >>734 緊急停止して「安全ですよ」はちょっと……
736 :デフォルトの名無しさん :2024/04/23(火) 12:14:00.43 ID:jXQ0V2HY.net >>733 セキュリティホールにならない 異常データに対して止まり動作を続けない
737 :デフォルトの名無しさん :2024/04/23(火) 15:43:54.29 ID:3Xc7JqWG.net >>733 >なんでコンパイル時にエラーにできないんだろう? 出来るわけないだろw 実行時に与えられる外部入力をコンパイル時にどうやって判定するんだよw バカすぎる
738 :デフォルトの名無しさん :2024/04/23(火) 16:19:44.91 ID:1rwyWp7B.net しいて言えばargs()を使う方が特殊ケースなのにデフォルトの名前を引き継いだのは設計ミス もう治る見込みはないからargs_os()を使おうねってだけだけど
739 :デフォルトの名無しさん :2024/04/23(火) 16:52:58.90 ID:Kbb8det7.net 一応argsをdeprecatedにして徐々に移行させていくのはできるだろうけど 特に提案もなさそうだし誰も困ってないんじゃないかな そもそもほとんどのケースでclapとか使うだろうし
740 :デフォルトの名無しさん :2024/04/23(火) 17:20:16.94 ID:jbFpiEtG.net >>733 >>>725 >なんでコンパイル時にエラーにできないんだろう? むしろ何でできると思ってるんだろう。謎
741 :デフォルトの名無しさん :2024/04/23(火) 17:22:13.22 ID:SM3r9/qB.net 環境変数もvarとvar_osがあるから慣れろとしか言えない OS標準が全部utf-8になる未来もありえるし
742 :デフォルトの名無しさん :2024/04/23(火) 17:48:20.12 ID:x1LuxzDZ.net >>741 紛らわしいけどvar/var_osとvars/vars_osは別物だよ varはinvalid UTF-8でもエラーハンドリング可 varsはpanic argsは引数にUTF-8以外はダメだよって前提で使える余地がまだあるけど varsはそんな前提をおける状況はほぼなくてよりたちが悪い
743 :デフォルトの名無しさん :2024/04/23(火) 18:06:35.01 ID:DF4k8ks3.net >>741 >OS標準が全部utf-8になる未来もありえるし 10年前のその未来予想が大外れしてるから今となっては設計ミスとしか言いようがない もう10年経ったとしても状況は変わらないと思う
744 :デフォルトの名無しさん :2024/04/23(火) 19:06:07.68 ID:rRGY+2Qg.net >>732 公式チュートリアルまともに読めるならC++で良いからな
745 :デフォルトの名無しさん :2024/04/23(火) 20:01:34.96 ID:+uJAOtCC.net よーわからんけど10年ぐらい前はすべてutf16になると考えられてたのでは? どう考えてもstd::env::argsを非推奨にしろとは思うけどね 欧米人がつくるとこんなことになるんだ 普通は2種類の扱いがある ・実行環境に合わせて自動的に内部での標準形式に変換 か ・何もしない 何もしないならOSから受け取ったままOSに渡して置けば大体問題はない 第三の愚策がRust 受け取ったままそのままOSに渡してもコケる Rustは何もしないように見えるけど何かしてるからコケるのでは?
746 :デフォルトの名無しさん :2024/04/23(火) 20:52:29.82 ID:xiHKhQOf.net >>745 間違いだらけだな 世界の標準はUTF8 ウェブももちろんUTF8 RustもUTF8 Rustがこの件でコケることはない きちんと各関数の仕様が明記されていて常に正確に動作している
747 :デフォルトの名無しさん :2024/04/23(火) 21:05:41.35 ID:ykVY4Q8s.net Rustのパニックは綺麗なパニック いいね?
748 :デフォルトの名無しさん :2024/04/23(火) 21:12:51.81 ID:xiHKhQOf.net >>747 一般的なパニックは色んな意味合いがあるけど Rustでのパニックは関数ドキュメントに明記されている想定のことが起きた ライブラリ関数の作成者はパニックを発生させる時の条件をドキュメントに明記しなければならない だからそれを利用する各プログラマーにとっても想定内のことのみパニックが起きる
749 :デフォルトの名無しさん :2024/04/23(火) 23:35:29.98 ID:v0qt2UCV.net >>745 勘違いしてることが多すぎてもう笑うしかないwww
750 :デフォルトの名無しさん :2024/04/23(火) 23:41:39.78 ID:x1LuxzDZ.net >>745 >よーわからんけど10年ぐらい前はすべてutf16になると考えられてたのでは? 30年以上前にUCS-2がWindowsやJavaに採用された時代のことを言ってるのかな? (UTF-16と違ってUCS-2は固定幅なので今でもまだ使い所はあるけど) ↓これが15年くらい前のUTF-16に対する一般的な認識 https://softwareengineering.stackexchange.com/questions/102205/
751 :デフォルトの名無しさん :2024/04/24(水) 00:43:41.33 ID:5EZEwmZn.net utf-16はUnicode 2.0(1996年7月)のサロゲートペア導入でutf-8に逆転されたな しばらくはBMPしか使われなかったから耐えてたけど 1990代前半に始動したJavaは運が悪かった
752 :デフォルトの名無しさん :2024/04/24(水) 01:21:01.63 ID:YBOQY0J9.net >>749 そう書きながら何もまともなレスすらできないレス乞食
753 :デフォルトの名無しさん :2024/04/24(水) 01:23:24.26 ID:YBOQY0J9.net Rust界隈では狂信者がいてそいつらはまともに反論すら出来ないけど Rustが正しいRustが正しいと繰り返すばかり
754 :デフォルトの名無しさん :2024/04/24(水) 12:36:38.15 ID:A+y4lqIx.net >>737 >>740 windows環境とかunicode以外が混ざる環境でargをコンパイルエラーにできないのかね。 そもそもargは廃止していい。
755 :デフォルトの名無しさん :2024/04/24(水) 12:47:56.41 ID:HIQuAly7.net すげーどうでもいい話だな
756 :デフォルトの名無しさん :2024/04/24(水) 12:47:57.96 ID:A+y4lqIx.net >>746 なるほど。 「RustはWindowsをケアする気が無い」 ということですか。
757 :デフォルトの名無しさん :2024/04/24(水) 12:58:45.05 ID:GRRi3Rgr.net >>754 Windowsでも設定すればUTF-8になるしLinuxだってUTF-8以外に自由に変えられるわけだから、そんな判定は不可能 まぁ廃止していいには同意するけども
758 :デフォルトの名無しさん :2024/04/24(水) 13:18:14.84 ID:meF6WBmz.net Windows は Windows の機能として文字コードの管理はしてるが歴史的事情でツギハギのグダグダ。 今の Linux はおおよそ UTF-8 で統一されているけど規約で縛っているだけで、 OS としてはバイナリ単位で素通し。 保証としてはあてにならん。
759 :デフォルトの名無しさん :2024/04/24(水) 13:18:30.26 ID:HIQuAly7.net コンパイルエラーにできないから引数まで廃止するとか原理主義もここまで来てんのか。
760 :デフォルトの名無しさん :2024/04/24(水) 14:25:14.78 ID:up+AoO7k.net >>754 無知にもほどがある! unicodeとUTF-8が区別できない Windowsに限らずLinuxでもmacOSでも非UTF-8の引数や環境変数が使われる可能性があるのは同じなんだがそんな常識を知らない
761 :デフォルトの名無しさん :2024/04/24(水) 15:25:54.44 ID:65hs2nTl.net >>760 そんなんだったらなおさらのこと、Rustの安全指向に従ってargs_osだけにすべきで、argsは廃止にすべきだろ。 Rustはメモリ安全しか興味無いんかね。
762 :デフォルトの名無しさん :2024/04/24(水) 15:53:48.65 ID:gLaneKFw.net 保証できるものはするに越したことはないけど (充分に実行コストが小さい形では) できんからしゃーない。
763 :デフォルトの名無しさん :2024/04/24(水) 16:02:42.64 ID:zvblwt+/.net どうでもいい話でもめてるな Rustはすべて提供してドキュメントにそるぞれ明記しているのだから使う側の各自の問題 こちらはUTF8環境でしか使われないのでargs()のみ利用している
764 :デフォルトの名無しさん :2024/04/24(水) 16:05:40.76 ID:AQu1Dr63.net https://github.com/rust-lang/rust/issues/91226#issuecomment-1034188905 関係する議論はこのあたりかな もともとはargs/varsをパニックさせずに無視するか置換してほしいって要望だったが 無視や置換はセキュリティ上問題になる可能性があるので却下 varsは将来的にdeprecatedにするかもと言っている なんでargsもdeprecatedにすべきだろって提案すれば通る可能性はあるかもね
765 :デフォルトの名無しさん :2024/04/24(水) 16:26:19.27 ID:MMJHgfnp.net 正しく使え論は暴論だな それが許されるならスマートポインタやGCは出ずみんな今でも生ポインタを使ってる
766 :デフォルトの名無しさん :2024/04/24(水) 16:40:56.16 ID:zvblwt+/.net >>765 生ポインタは安全ではないから全く違う argsは常に安全
767 :デフォルトの名無しさん :2024/04/24(水) 16:44:59.20 ID:MMJHgfnp.net 常に自動変換したほうが安全だけどな 開発者が特別コードを書く必要もない
768 :デフォルトの名無しさん :2024/04/24(水) 17:05:56.77 ID:MMdiZvh6.net Rustはファイル名も自動変換なんかしていないように 変換するかどうかは各自の自由裁量であるところが非常に良い点だよ 自分の好みと合わないからといって批判している人たちは頭がおかしいので相手にしても無駄なのだろうけど
769 :デフォルトの名無しさん :2024/04/24(水) 17:17:38.15 ID:MMJHgfnp.net >>768 ここまで読んで何の話をしているのか理解できないならRust使うのは辞めたほうがいい
770 :デフォルトの名無しさん :2024/04/24(水) 17:21:01.52 ID:MMJHgfnp.net ファイルの引数だけ標準では何もしない 普通のキーボード入力などでは変換している
771 :デフォルトの名無しさん :2024/04/24(水) 17:23:28.05 ID:D1bqYp6J.net >>770 え??
772 :デフォルトの名無しさん :2024/04/24(水) 18:26:14.33 ID:AQu1Dr63.net >>768 自動変換は正直意味不明だが(変換元の文字コードが判定不能なのに何を変換するのか?) argsは今RFC出したらResultにしろって突っ込まれると思うし 1.0であまり深く考えずに入れちゃった気はするよ
773 :デフォルトの名無しさん :2024/04/24(水) 18:50:02.66 ID:5HDpMmrb.net Resultとかのハンドリングが面倒な人向けの簡便方法として用意されてるのでそれはないと思う argsじゃなくてargs_utf8onlyとか名前をダサくして 逆にargs_osを元のargsに戻しとけば リファレンスをよく読まない人たちがつまづく可能性を下げられる
774 :デフォルトの名無しさん :2024/04/24(水) 19:00:18.55 ID:65hs2nTl.net こういうのを見ると、RustのデザイナーはRustに求められているのがなんなのか理解できていないと思うわな。 Rustは雇われコーダー用Safe Rustのニーズがほとんどで、Unsafe Rustとかのニーズは無いと思うがね。
775 :デフォルトの名無しさん :2024/04/24(水) 19:01:34.27 ID:MMJHgfnp.net >>772 自動変換が本当に意味不明ならここまでの話が見えてないとしか言いようがない
776 :デフォルトの名無しさん :2024/04/24(水) 19:14:39.18 ID:9A8KMAyG.net 自動変換とかそんなアホなこと言ってるのはあんただけやで そんなものは無いし必要ない
777 :デフォルトの名無しさん :2024/04/24(水) 19:18:07.57 ID:MMJHgfnp.net こいつOsStringの概念が分かってないのか 本当に知能レベルが低すぎる
778 :デフォルトの名無しさん :2024/04/24(水) 19:45:20.62 ID:AQu1Dr63.net OsStringはOSから渡されたバイト列をそのまま格納するだけで EUC-JP環境ならEUC-JPバイト列がそのまま入るし何も変換されたりしないが…
779 :デフォルトの名無しさん :2024/04/24(水) 19:49:39.48 ID:MMJHgfnp.net 想像力が欠如しているか頭がおかしいか指示待ち人間だからそういう幼稚なレスになる 結局内部で使う場合は簡単にutf8に変換してる なにからutf8に変化するか指示も必要がない ただのボイラープレート
780 :デフォルトの名無しさん :2024/04/24(水) 19:58:53.67 ID:ArOBrbBE.net >>777 自動変換なんてものはない むしろ自動変換を避けるために用意されているのがOsString もちろん自動変換は行われない
781 :デフォルトの名無しさん :2024/04/24(水) 20:02:00.63 ID:MMJHgfnp.net 人間じゃなくて壊れたロボットに話しているようだな いくつになろうとこんなダメな人間になってはいけないな
782 :デフォルトの名無しさん :2024/04/24(水) 20:16:20.94 ID:il94IOIF.net ぼきのかんがえたさいきょうのげんごにはstring<encoding>とchar<encoding>があって どんなエンコーディングの文字列でも統一的に扱うことができましゅ Rustもまだまだでしゅね
783 :デフォルトの名無しさん :2024/04/24(水) 20:44:42.25 ID:xJ62MSkB.net ほとんどの環境がWebも含めてUTF8に統一となったからRustのstr/String内部表現がUTF8であるのは合理的といえる もちろんWebでもローカルファイルでも古いものは様々な文字コードが使われているため必要なら各々で対処する必要がある
784 :デフォルトの名無しさん :2024/04/24(水) 21:30:38.14 ID:nN1vQ+Ae.net 文字コードをUTF-8とか特定のものに決め打ちにしないという点ではRubyが一番先進的だったが、あれはやりすぎで以降の言語には採用されなかったな。
785 :デフォルトの名無しさん :2024/04/24(水) 21:49:41.83 ID:tlaf0qkO.net めちゃくちゃ間違ってるのになぜ上から目線で自信満々にレスするんだろう? 複オジは昔の自分を諭してる気分じゃないか?
786 :デフォルトの名無しさん :2024/04/24(水) 22:41:53.26 ID:MMJHgfnp.net Rustが正しいの一点張りの狂人
787 :デフォルトの名無しさん :2024/04/25(木) 01:24:12.71 ID:fpMjozoS.net >>0774 お前の着眼点は凄えよ!感動した。 その通り、Rustは初心者/素人 御用達言語だよ。
788 :デフォルトの名無しさん :2024/04/25(木) 07:30:11.27 ID:xsazBswH.net おじいちゃん誰にも相手にされず寂しくなったんだねw
789 :デフォルトの名無しさん :2024/04/27(土) 03:20:12.65 ID:nhA0znD3.net 聞き分けることができない。 https://kanji.reader.bz/pronunciations/last,lust,rust
790 :デフォルトの名無しさん :2024/04/27(土) 21:28:13.67 ID:+PotGQRe.net crates.io が死んだときはどうすれば良い?
791 :デフォルトの名無しさん :2024/04/27(土) 21:31:55.69 ID:Ik8q0/YE.net cargo run --offline
211 KB
新着レスの表示
掲示板に戻る
全部
前100
次100
最新50
read.cgi ver 2014.07.20.01.SC 2014/07/20 D ★
本文 スレッドタイトル 投稿者