Rust part29

**デフォルトの名無しさん** · 2025/05/03(土) 00:47:30.13

公式
https://www.rust-lang.org/
https://blog.rust-lang.org/
https://github.com/rust-lang/rust

公式ドキュメント
https://www.rust-lang.org/learn

Web上の実行環境
https://play.rust-lang.org

※Rustを学びたい人はまず最初に公式のThe Bookを読むこと
https://doc.rust-lang.org/book/

※Rustを学ぶ際に犯しがちな12の過ち
https://dystroy.org/blog/how-not-to-learn-rust

※Rustのasyncについて知りたければ「async-book」は必読
https://rust-lang.github.io/async-book/

※次スレは原則>>980が立てること

前スレ
Rust part28
https://mevius.5ch.net/test/read.cgi/tech/1742805420/

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

**デフォルトの名無しさん** · 2025/05/22(木) 11:53:24.27

>>705
作者がその件で書いている話の正確なところは、
stable版ではLinkedListのcursorと、
カスタムアロケータのallocator_apiがまだ使えないため、
それがnightly版を使った理由。
あとはifとwhileでのletチェーンも使いたいから、と追記してるね。

**デフォルトの名無しさん** · 2025/05/22(木) 12:12:32.32

このレベルはwarning出そうだが、リリースするまで見落とすのか
https://github.com/microsoft/edit/pull/137/files

**デフォルトの名無しさん** · 2025/05/22(木) 12:27:27.75

warningは出ない
panicは安全
データ喪失も安全

#メソッド

**デフォルトの名無しさん** · 2025/05/22(木) 12:32:59.97

ほかの言語でも同じ
ほかの言語でもデータ破壊も安全

#複おじメソッド

**デフォルトの名無しさん** · 2025/05/22(木) 12:33:48.78

作者のRust評/Zig評は複オジまとめじゃなくて原文を読むことを勧める

>>720
行入れ替えじゃなくてunindent
テストも書かれてないし現状はその程度の品質だろうね

**デフォルトの名無しさん** · 2025/05/22(木) 12:41:36.62

>>720
x[i]はiが範囲内に確定してる時のみ使う構文
panicを起こしうる構文やメソッドを確定していない時に使うことはRust的じゃないな

**デフォルトの名無しさん** · 2025/05/22(木) 12:46:06.84

アニヲタ: アニメなら第一話を必ず見る、周りの反応が気になる、切る
複おじ: Rustなら必ず飛びつく、周りの反応が気になる、切る

**デフォルトの名無しさん** · 2025/05/22(木) 12:46:41.09

イテレータ使えないオジサンがMSいるって

**デフォルトの名無しさん** · 2025/05/22(木) 13:01:08.00

元がCやZigで書いてるからそんな変なコードになっていてその時からあるバグをそのまま持ち込んだのだろう
if let/let elseやイテレータを使ったコードへリファクタリングすれば安全性が向上するだろう

**デフォルトの名無しさん** · 2025/05/22(木) 13:09:18.28

リファクタリング棒て
そんなの簡単に出来たら35万デッドエンドしてないて

**デフォルトの名無しさん** · 2025/05/22(木) 13:10:28.75

松居棒的なものかな

**デフォルトの名無しさん** · 2025/05/22(木) 13:10:29.98

テストをきっちり書いてからLLMだな

**デフォルトの名無しさん** · 2025/05/22(木) 13:22:57.18

>>728
その手のリファクタリングすらできないならかなり能力の低いプログラマ
Rustの基本知識を身につけていれば普通のプログラマなら可能

**デフォルトの名無しさん** · 2025/05/22(木) 13:44:14.99

>>728
すでにGitHub Copilot Coding Agentがパブリックビューで出てきてる。
ごく近い将来、commitしたソースを自動でlint:fixして勝手にAIがレビュアーが指摘と対策コードを
提示して勝手にsquashしてcommit履歴すらも綺麗にするようになるんじゃないかな。

**デフォルトの名無しさん** · 2025/05/22(木) 13:49:19.61

>>732
C/C++コードを静的に安全確認は無理なことがわかっているためAIでも不可能なので
その時代になるとRustへの移行がますます加速するんだろうな

**デフォルトの名無しさん** · 2025/05/22(木) 13:51:10.87

>>732-733
ほかの言語でも同じ
むしろRustの伸びしろが小さいまである得る

**デフォルトの名無しさん** · 2025/05/22(木) 13:54:16.75

>>734
Rustに勝てそうな言語が現状見当たらない

**デフォルトの名無しさん** · 2025/05/22(木) 13:57:52.09

>>735
めっちゃ頑張ったんだけど1位になれなかったな

悲報！Rust版AV1デコーダーがCより5%遅い問題が解決できず、カネで解決しようとする
https://www.memorysafety.org/blog/rav1d-perf-bounty/

**デフォルトの名無しさん** · 2025/05/22(木) 14:02:35.00

>>727
Rustの伸びしろが小さいとどんどんC/C++/Zigに置いて行かれるね

**デフォルトの名無しさん** · 2025/05/22(木) 14:05:09.70

>>736
それはLLVMの問題点が指摘されてる

>>737
静的に安全確認できないそれらの言語はAI時代に捨てられる運命

**デフォルトの名無しさん** · 2025/05/22(木) 14:14:30.21

手厚くお相手開始

**デフォルトの名無しさん** · 2025/05/22(木) 14:31:07.15

>>738
やっぱgccで納得だよな

**デフォルトの名無しさん** · 2025/05/22(木) 14:50:43.05

度々Rustがビミョーに遅いのはLLVMのせいでしたが仮に本当なら
一個人のホビーコントリじゃどうにもならんよ

**デフォルトの名無しさん** · 2025/05/22(木) 15:09:08.16

>>738
いや現実には複合要因だろう
他責にして手をこまねいてる間にRustが停滞していくのが心配

**デフォルトの名無しさん** · 2025/05/22(木) 15:13:41.62

LLVMならAppleがなんとかしてくれんか

**デフォルトの名無しさん** · 2025/05/22(木) 15:15:07.07

>>731
> その手のリファクタリングすらできないならかなり能力の低いプログラマ

お試しも含めて広まるべきところには行きわたって
これからは質が悪くなる一方だな、人的にも成果物的にも

**デフォルトの名無しさん** · 2025/05/22(木) 15:31:34.14

Rustコードのちょっとした変更に対して生成コードが大きく変わることが問題として挙げられている
特にcmov/cselを用いて分岐命令を回避できていた生成コードが条件分岐に変わってしまう問題が遅くなる顕著な例
LLVMが振る舞いを変えていて結局cmov/cselが消える問題はスタックの使用量が増えると発生するらしい
Rust側のソースコードとコンパイラだけでは対処が難しい領域

**デフォルトの名無しさん** · 2025/05/22(木) 15:32:41.47

これがAI時代のプルリクエストか
https://github.com/microsoft/edit/pull/164

**デフォルトの名無しさん** · 2025/05/22(木) 15:37:54.16

>>746
テストしてから出直してくれって優しい作者だな
Microsoftってもっとキツい印象あったさかい

**デフォルトの名無しさん** · 2025/05/22(木) 15:38:10.97

>>746
さっそくRustの今後
> これからは質が悪くなる一方だな、人的にも成果物的にも

**デフォルトの名無しさん** · 2025/05/22(木) 15:40:33.23

情報があればLLMの精度も上がらんかな

**デフォルトの名無しさん** · 2025/05/22(木) 15:42:18.46

>>746
メソッド乙

複おじ: 気になる、貼る、煽る、反応を見る、切る

**デフォルトの名無しさん** · 2025/05/22(木) 15:45:34.88

>>749
もっとLLVMへの指定とLLVM側での対応が増えれば解決する問題ではある
ケースによってrustcまたはRustソースコードで指定

**デフォルトの名無しさん** · 2025/05/22(木) 15:46:16.26

>>747-748の通り一瞬で分かるのに、>>746は本当に英語出来ないのか

>>746が
> これからは質が悪くなる一方だな、人的にも成果物的にも
を体現しているな

**デフォルトの名無しさん** · 2025/05/22(木) 15:48:23.67

>>751
じゃあ、gccrsでビルドしなおすだけで$20,000もらえるの？

**デフォルトの名無しさん** · 2025/05/22(木) 16:30:41.91

>>753
ただし欧米かニュージーランドかオーストラリア在住が必須とあるので、日本人お断り案件

**デフォルトの名無しさん** · 2025/05/22(木) 16:33:47.34

最適化ってのはレジスタ割り当てとかは合理的な割り当てアルゴリズムがあるが、
ヒューリスティックな手法も合わせて使ってる。
大量の置き換えパターンを辞書として持っておくという泥臭い仕組みだったりする。
これは言語の性質によるので言語中立で高性能な最適化機構を持ったコンパイラバックエンドなんて無理なんじゃねーかなと思ってる。

**デフォルトの名無しさん** · 2025/05/22(木) 17:31:19.79

Rustって泥臭い役割を避けているから愛され言語イエーイしてるよね

**デフォルトの名無しさん** · 2025/05/22(木) 17:33:10.42

Rustはルールが厳しくてすんなり書けない事が多い　お世辞にも書きやすい状況じゃない
それ自体は仕方がないけど回避するために何か方策が必要になることが多い

現在のstableでは機能不足でありeditの作者はnightlyビルドを使ってる
関数の充実が待たれるが結局その都度使える関数を探さないといけない

**デフォルトの名無しさん** · 2025/05/22(木) 17:42:54.78

ネット上での統合失調症【糖質】の機器の説明との押し問答と同じ状態を表している
無知だからこうなのだよ！
※ 周囲の人は統合失調症の思考を聞いているのでしょうならその思考通りに統合失調症は話せばよいのでしょう？
※同じ話を統合失調症も聞いておりますけれど？

「AIがMicrosoftの従業員を徐々に狂わせていく様子を見るのが趣味」というネットユーザーの投稿が話題に
2025年05月22日 14時00分
https://gigazine.net/news/20250522-github-copilot-coding-agent-error/
>>「AIが『直しました』と言い、人間が『いいえ、まだ壊れています』と言い、AIが変更を加えて『問題ありません、直りました』と言い、さらに数回繰り返すところが気に入っています」といったコメントや、
>>「残念なことに、私もまさにこのパターンに従う人間の開発者と一緒に働いたことがあります」とのコメントのほか、
>>「問題は、今後10年間でモデルが実際に改善され、実現可能になるという確かな証拠がないことです。テストと研究はともかく、製品に導入するのは全く別物です。大手ソフトウェア企業は、株主の利益を満足させるために運営されています」など、未完成で不確かな製品を公開することに異議を唱えるコメントが付けられました。

**デフォルトの名無しさん** · 2025/05/22(木) 17:45:59.66

生ごみ拾ってくんな

**デフォルトの名無しさん** · 2025/05/22(木) 18:00:14.35

>>755
>>500,736 の場合は特にasmコードが実行時間の大半を占めている前提で考えて
「inline」asmとその前後(のCコードのgcc出力)が相性良く仕上がっているからかなぁ、と思ったら
dav1dにはinline asmはなくて関数単位でasmを使っているだけの様に見える
https://code.videolan.org/videolan/dav1d

それでもgccとclangで差があると言うのだから「泥臭い」最適化には頭が上がらない

ましてやasmコードそのままに横入り/ただ乗りするプロジェクトに憤りを感じる

**デフォルトの名無しさん** · 2025/05/22(木) 19:00:56.60

考えて見たら
> 横入り/ただ乗りするプロジェクト
の方は内々ではちゃんとお金出すってさ、videolan側で変更が発生した場合
videolan側へも関わった人数分の懸賞金配分があるべきだよね

**デフォルトの名無しさん** · 2025/05/22(木) 19:18:13.29

>>760
オープンソースライセンスで、しかも二条項MITという緩いライセンスを選択している以上はただ乗り歓迎という意思表示だろう。
性能的に不十分ではあっても技術的開拓をしてる分だけ単なるユーザよりは貢献してるわけだし、そこに憤るのは筋違いだと思うぞ。

**デフォルトの名無しさん** · 2025/05/22(木) 19:23:31.51

>>762
tailwindも勘違いしてる

**デフォルトの名無しさん** · 2025/05/22(木) 20:47:22.62

ガーイガイガガイガガイガガイ私ガイガイガイガイゴミガイジ
周りに迷惑をかけ続けるクソガイジ
プログラミング出来ないイキリ無能
死んだ方がマシ人間
ガイガイクソガイジ

**デフォルトの名無しさん** · 2025/05/22(木) 20:47:47.49

死にますクソガイジです

**デフォルトの名無しさん** · 2025/05/22(木) 20:49:14.84

やる気ある無能クソガイジだけど質問ある？

**デフォルトの名無しさん** · 2025/05/22(木) 20:53:07.80

なんでRustで作られたモノが極端に少ないのかと思ってたけど
理由が分かっちゃったよ

**デフォルトの名無しさん** · 2025/05/22(木) 21:18:38.27

rav1d高速化コンテストだけど
MaybeUninit を使ってゼロクリアを避けただけで
実行時間差の2割が解決したらしい

**デフォルトの名無しさん** · 2025/05/22(木) 21:25:17.88

>>767
新たに作られたものはRustが多い

**デフォルトの名無しさん** · 2025/05/22(木) 21:28:24.04

>>767
Rust の公式リポジトリ (crayes.io) のクレートが 18 万個。
python のリポジトリ (pypi.org) にあるパッケージが 63 万個。
JavaScript が 200 万個。

まあ比較すれば少ないが、 JavaScript の1割弱ならかなり多い部類だろ……
Hakell だと1万7千、OCamlなんて4千ちょっとだぞ。

**デフォルトの名無しさん** · 2025/05/22(木) 21:31:44.54

>>768
そんな基礎的なことをやっていなかったことに驚いた
何かデータ構造ベクタとかスタックとかキューとか作ったことがあれば初期値のサイズ0で必ずMaybeUninit使うのにな

**デフォルトの名無しさん** · 2025/05/22(木) 21:33:15.61

>>770
こっちが恥ずかしくなる

**デフォルトの名無しさん** · 2025/05/22(木) 21:33:58.09

ゼロクリアする必要がない (から削除してよい) ことをコンパイラが見抜けないもんなのか？

**デフォルトの名無しさん** · 2025/05/22(木) 21:53:24.32

>>773
特定の使われ方するものに限って将来型システム拡張で対応できる可能性があるかもしれないらしいけど現状は無理だね
型Tの入る場所には型Tの何か入れておかないと未定義動作となってしまう
そこで現在はMaybeUninit型という初期化しなくていい型が用意されていてそれを使うことでCと同じ速さにできる

**デフォルトの名無しさん** · 2025/05/22(木) 22:18:19.76

Apple M3で8.8%遅かったのが7%になったとな
「5%遅い」はAMD Ryzenでの数字

**デフォルトの名無しさん** · 2025/05/23(金) 00:20:06.09

>>767
> なんでRustで作られたモノが極端に少ない
crateばっか作ってるなw

>>770
githubレポ数で割ると

Rust 21%
Python 5%
JavaScript 8%

Rustはこれで良いのか？

**デフォルトの名無しさん** · 2025/05/23(金) 00:34:18.82

>>720
静的解析ツールで検知できそうなもんだけどな
Rustにはないのかね？

**デフォルトの名無しさん** · 2025/05/23(金) 01:14:01.61

外部の状態が関係してるから静的解析では無理だろ

self.buffer.extract_raw(beg.offset, end.offset, &mut replacement, 0);
で取得したreplacementが長さ0である可能性とか分からん

**デフォルトの名無しさん** · 2025/05/23(金) 18:12:15.45

開発自体は別言語で行って最後にRustに移植で良い気がしてきた

**デフォルトの名無しさん** · 2025/05/23(金) 19:45:55.43

バカはそれでいい

**デフォルトの名無しさん** · 2025/05/23(金) 20:53:28.09

神は仰った
天才と思う者だけRustを使いなさい

Rustを使うものはバカだけになった

**デフォルトの名無しさん** · 2025/05/23(金) 20:55:45.35

バカは移植できないしRustも使えないだろ

**デフォルトの名無しさん** · 2025/05/23(金) 21:06:36.34

>>779
別言語って具体的に何？

**デフォルトの名無しさん** · 2025/05/23(金) 21:11:13.25

バカは別言語が気になる

**デフォルトの名無しさん** · 2025/05/23(金) 21:14:51.67

オレはTypeScriptで書いてたWEB APIをRustで書き直したよ
その後保守性わるくてTypeScriptに戻したけど
またRustで書き直そうかと迷ってる
性能か保守性か悩ましい

**デフォルトの名無しさん** · 2025/05/23(金) 21:20:15.08

保守性の高さからRustが使われる
Rustより保守性の高い言語はない

**デフォルトの名無しさん** · 2025/05/23(金) 21:25:40.65

プロトタイプはPythonでいいぞ

**デフォルトの名無しさん** · 2025/05/23(金) 21:48:17.92

GC言語などでメモリ関係なくコード書いて最後にRustでいいんじゃないか
asmの代わりがRust

**デフォルトの名無しさん** · 2025/05/23(金) 22:03:24.19

保守性高いと進化留まりガチ

**デフォルトの名無しさん** · 2025/05/23(金) 22:31:16.60

Rustの保守性の高さは並列排他に至るまで対応する強力な型システムがベース
進化を重ねていて両立

**デフォルトの名無しさん** · 2025/05/23(金) 23:00:21.91

体言止めおじ

**デフォルトの名無しさん** · 2025/05/23(金) 23:13:32.86

>>785
Rustの保守性の良し悪しはともかく、そんなしょっちゅう書き直せる程度のものなら保守性なんか気にする必要ないっしょ

**デフォルトの名無しさん** · 2025/05/23(金) 23:21:45.26

>>778
今回のは長さ0になる可能性があることが分かるやろ

はっきり分からないような場合でも解析ツール的にはフォルスポジティブでも安全側に倒しておいたほうがいいから「長さ0にならないとは断言できない」っというので警告を出す条件としては十分

**デフォルトの名無しさん** · 2025/05/24(土) 09:17:30.06

コンパイルが通れば安全じゃなかったの

**デフォルトの名無しさん** · 2025/05/24(土) 09:24:29.16

>>794
アホ？テスト通せよ

**デフォルトの名無しさん** · 2025/05/24(土) 09:42:12.79

>>794
安全だよ
この件でメモリのセキュリティのホールになることはない

**デフォルトの名無しさん** · 2025/05/24(土) 09:42:56.36

Rustでもほとんどのプログラミング言語と同じでインデックス境界チェックエラーにより落ちてくれる

**デフォルトの名無しさん** · 2025/05/24(土) 09:44:36.18

Rustでこれを避けるにはindex値が範囲内か不明の時はxxx[index]アクセスをしないこと
get*やイテレータなどを使う

**デフォルトの名無しさん** · 2025/05/24(土) 10:24:46.55

イテレーターとインデックスアクセスじゃスピード変わりそう
と言うより用途が違う

**デフォルトの名無しさん** · 2025/05/24(土) 10:39:58.90

末尾\0が保証されてるCのコードをそのまま移植したんでしょ
いわゆる「Rustは清書用」バグ

**デフォルトの名無しさん** · 2025/05/24(土) 11:01:12.40

たとえば「任意のコードを実行可能」な脆弱性が「異常終了するだけ」の実行時エラーで置き換えられる
この種類の置き換えはJavaでもできる

**デフォルトの名無しさん** · 2025/05/24(土) 11:12:53.59

>>800
C言語の段階で範囲外インデックスのバグだな
落ちなくてヤバかった

**デフォルトの名無しさん** · 2025/05/24(土) 11:25:25.71

>>800
関係ないやろ

**デフォルトの名無しさん** · 2025/05/24(土) 11:33:16.13

アクセス違反だがCでは落ちずに動いていた
Rustにしたことでバグが露呈

**デフォルトの名無しさん** · 2025/05/24(土) 11:58:41.99

>>795
このスレでさんざんコンパイル通れば安全という話を見てきたんですが

**デフォルトの名無しさん** · 2025/05/24(土) 12:00:21.23

ていうか、mutを制限しない限り、末尾\0は別の値に変更できるから末尾\0は保証されない

**デフォルトの名無しさん** · 2025/05/24(土) 12:06:04.95

>>805
コンパイルが通れば安全というのはRust-bookの翻訳の間違いな。原文読まないと
手を動かさないと理解できないだろうが、Rustにはテストフレームワークが組み込まれてるし、さらに外部のクレートを使うことが推奨される

cargo-nextest
cargo-insta
あたりね

ライブラリークレートをコーディングするときに並行してテストコードも書いて、バウンダリーズとかに問題がないことを確認した上でcrates.ioやgithubに公開しないと恥かくよ。上のヌル文字終端とかもCから来た人なら絶対テストに入れるべきよ

恥を気にしない人なら好きにしてくれ！

**デフォルトの名無しさん** · 2025/05/24(土) 12:24:06.94

>>805
Rustではコンパイラが通れば必ず安全が保証されるよ

**デフォルトの名無しさん** · 2025/05/24(土) 12:24:29.19

>>805
MSエディタはインデックス範囲外をpanicするAPIを使っていて安全に落ちていて他の言語と同じ

**デフォルトの名無しさん** · 2025/05/24(土) 12:26:01.00

>>805
Safe Rustに限定すればRust自身にバグがない限りは安全
今回のはpanicするだけなので安全の範疇だよ
「安全 == ロジックバグがないこと」だと思ってるならそれは間違い

**デフォルトの名無しさん** · 2025/05/24(土) 12:30:11.61

panicがイヤならpanicしないAPIを使えば解決するね
panicするAPIを使っておいてpanic違反するのはマゾみたいなもの

**デフォルトの名無しさん** · 2025/05/24(土) 12:45:05.58

>>803
Cの場合は空文字列でも\0があるから最初に
if (str[0] == '\t)
をぶつけても問題にならないよ
このフローをそのままRustに持ち込んだ感じ
もとのコード見れないから断言はできんが

**デフォルトの名無しさん** · 2025/05/24(土) 12:45:10.09

とっくに化けの皮は剥がれてるのに、こんな新規参入のない掲示板で耳障りのいいことばっかり書いて何になると思ってるんだろうか

**デフォルトの名無しさん** · 2025/05/24(土) 13:50:39.66

コード見たけどRustならスライスとそのメソッド使うところ
なぜかインデックスアクセス多いな
該当部の直後も
while remove < self.tab_size as usize
　&& offset + remove < replacement.len()
　&& replacement[offset + remove] == b' '
{
　remove += 1;
}

**デフォルトの名無しさん** · 2025/05/24(土) 14:01:45.35

最初に機能の弱い他の言語で書くからそうなる
最初から抽象的に書けるRustを使うべき

**デフォルトの名無しさん** · 2025/05/24(土) 14:17:39.59

えー、このクソ言語で？

**デフォルトの名無しさん** · 2025/05/24(土) 14:34:27.01

crates.ioの恥は描き捨て

**デフォルトの名無しさん** · 2025/05/24(土) 14:47:03.56

続けるだけでは意味がない。研究が示した「成長できない人の条件」
公開日2025.05.24 13:00:14 SATURDAY
http://nazology.kusuguru.co.jp/archives/177845

**デフォルトの名無しさん** · 2025/05/24(土) 15:05:18.87

古く機能が弱いプログラミング言語にこだわってる人は成長できない