Rust part35

公式
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 part34
https://mevius.5ch.io/test/read.cgi/tech/1764213923/

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

Rustってネットで持ち上げられすぎてね？
https://mevius.5ch.io/test/read.cgi/tech/1774264073/

排斥すべきゴミ言語 C++ Rust 他
https://mevius.5ch.io/test/read.cgi/tech/1643696741/
結局C++とRustってどっちが良いの？ 9traits
https://mevius.5ch.io/test/read.cgi/tech/1701997063/
Rustアンチスレ
https://mevius.5ch.io/test/read.cgi/tech/1509028624/
競プロにおいてのRust
https://mevius.5ch.io/test/read.cgi/tech/1663352373/
Rust(unsafe) vs C
https://mevius.5ch.io/test/read.cgi/tech/1646151892/
C/C++のソースをRustへ全力で置き換えるスレ
https://mevius.5ch.io/test/read.cgi/tech/1681777958/
Rust最強(仮)
https://mevius.5ch.io/test/read.cgi/tech/1735954922/
Rust vs Go
https://mevius.5ch.io/test/read.cgi/tech/1654019126/
そんなにRust,Rust言うならゲームエンジンでも
https://mevius.5ch.io/test/read.cgi/tech/1678619820/

>>1
O2

平和教育

このスレにたくさん居た驚き屋ってみんなユーチューブに行っちゃったの？

C/C++に帰っていったのかも

C/C++ スレも過疎ってるよ。

>>2 が本スレ

>>9
お薬飲み忘れないでくださいね

パワハラ相談ok?

マ板でやれ

>>11
Rustに関係してるなら

>>6
驚き屋ワロタ

そもそも5chの老人たちの中に、Rustみたいなモダンな言語に追従できるやつがどれだけいると思うよ？

Rustはもうモダンとは言えなくなってきた

若い連中は言語なんか気にせずヴァイブコーディングだからな
いまだにコードに拘ってる時点でもはや老人

なぜおっさんは若者にこだわるのか

若い頃にC++で苦労したシニア世代じゃないとRustの利用価値は分からないと思う
昔のC++の闇を知らない世代だと逆に学習曲線のハードルが高そう

そもそもモダンに見えない

Rustは最もモダンなプログラミング言語の一つ

モダンな掲示板へようこそ

大正モダン言語

喪男の言語？

そんな、だれもlispに追い付けてないのにモダンなとか言われても。いやforthは追い越してるかもしれんが。

for文使ってデータ処理して結果をVecにpushしていくよくある処理を、
for文使わずにモダンにイテレータメソッドチェーンにしてVecへはextendまたはcollectすると、
モダンな方が実行速くなったという記事があるけど、
仕組みと理由が納得できた。

Haskellからパクってるからそっちが正しい

>>26
真にモダンな言語ならそういう差異は生まれない

Rustはモダン以前の問題

>>25
思想としてはFORTHの足元にも及ばん。Joyのほうがマシ。
もっとスタックフレーム指向で計算モデルを整理すれば追い越せるかもね。

ffmpegがcからRustに書き直してるそうで
速度が10倍遅くなるそうだ

>>31
それはすごい。せめて3倍くらいにおさえないとやる気なくしそう。

>>30
ああ、もしかして誤解をあたえた？forth だけはlisp を追い越してるかもしれんが、Rust ほかは全然だよね。ということで。

lispは人工知能分野で強い

Rustの論文書いたぞ。
感想聞かせてくれ。
英語、フランス語、日本語。
日本語版はスクロールすれば下の方にある。

https://files.catbox.moe/6x0oat.pdf

Q. RustとLispとForthどれが一番モダンなプログラミング言語ですか？

A. Rust、Lisp、Forthのモダン性についての比較は難しいですが、以下の点が挙げられます

Rust: 高安全性とセキュリティが求められる分野での使用が増加しており、特にブラウザ開発やIoTアプリケーションで注目されています。

Lisp: 関数型プログラミングの先駆者であり、メタプログラミングやAI研究において重要な役割を果たしていますが、現代のモダンプログラミング言語としてはあまり一般的ではありません。

Forth: 1950年代に開発された言語で、手続き型プログラミングの典型ですが、現代のモダンプログラミング言語としてはあまり普及していません。

>>35
おじいちゃんの独り言じゃないかｗ
AIの反応が優しすぎて涙が出る

Rustについても誤解してる

どっちがモダンかという比較において年度で比べるのが間違ってることをAIに教えたい

モダンなプログラミング言語は、効率性・柔軟性・安全性を重視した現代のソフトウェア開発向けの最新言語です。
以下のような特徴を持っています。
・効率的で読みやすい構文：コードの保守性や生産性を向上させる設計。
・柔軟性と拡張性：大規模システムやクラウド環境での開発に適応。
・安全性の重視：型安全やエラーハンドリングの改善によりバグを減らす。
・非同期処理や並列処理への対応：高性能なシステム開発をサポート。
・コンポーネントベース設計やマイクロサービスとの親和性：再利用性やスケーラビリティを確保。

Common Lisp なら型安全以外はだいたい実現出来ているな。

aiコピペぉぢさんの魅力

この業界のポストモダニズムはLisp回帰か
悪くないな

Lispは逆ポーランド記法にしてくれればいいんだけどなぁ。

>>40
その型安全が全ての根幹で最重要
Rustの場合はトレイト境界を満たすことも含まれるから例えばデータ競合も型安全で防いでいる

lispにないってことは型安全って実は要らないんじゃないの

AIにも見捨てられたrust

AIの盟主アンソロピックがAIにRust標準ライブラリの知識だけでRustによるCコンパイラ作成を完全自動生成
することに成功

Building a C compiler with a team of parallel Claudes
https://www.anthropic.com/engineering/building-c-compiler

To stress test it, I tasked 16 agents with writing a Rust-based C compiler, from scratch, capable of compiling the Linux kernel.

This was a clean-room implementation (Claude did not have internet access at any point during its development); it depends only on the Rust standard library.

>>47
> Published Feb 05, 2026
> The compiler, however, is not without limitations. These include:
...
> The generated code is not very efficient. Even with all optimizations enabled, it outputs less efficient code than GCC with all optimizations disabled.

>>47
>Rust標準ライブラリの知識だけで
これは完全な嘘
GCCパクリまくり

つか何ヶ月も前の終わった話を
持ち出さなきゃいけないくらい下火なのか

Rewriting Project Claw Code
https://github.com/instructkr/claw-code

Rust port is now in progress on the dev/rust branch and is expected to be merged into main today.
The Rust implementation aims to deliver a faster, memory-safe harness runtime.
Stay tuned — this will be the definitive version of the project.

今時cコンパイラ作ったからなんやねん
驚き屋しか見ないやろそんなもん

>>35
これが論文？　バカじゃねえの
老人ホームから逃げ出してきたのか？

>>45
Lisp にないのではなく Common Lisp にないって話。
高度な型システムはあって型システムをカスタマイズする仕組み (メタオブジェクトプロトコル) もあるけど静的に整合性を検証したりはしない。
Common Lisp は実行時エラーになったらそのままデバッグモードに入ってエラーが出たときの環境を調査したり書き換えたりしてプログラムを停止せずに続けられる仕組みがある。
ランタイムと人間もシステムの一部であるという思想なので運用の前提が Rust とは違う。

まあどれだけガチガチに型で固めてもどうせ不具合は出るもんだという前提に立つと Common Lisp のほうが現実的な場面は結構あるかもしれない。
ちなみに Lisp 系言語には静的型を指向するものもあるよ。

>>50
一瞬で10万スターが付いた今最も勢いのあるAIプロジェクトがRust製というのが時代の流れを感じるなぁ

最初pythonで作られたやつじゃん
訴えることができるならやってみろ、おしりぺんぺん！ってしてるみたいなもんだからpython, rustだけじゃなくtypescript以外の他言語でも実装していくかもね

速さと安全を両立して読み書きしやすいRustが採用された

>>53
null safetyな言語ある？
typed racketですらダメだからlisp系とは根本的に相性悪いんだろうと思ってる

>>57
Typed Racket は漸進的型付け。
根本的には動的な言語であるという前提で部分的に静的な検査を導入しただけで、それほど強くは静的型検査を指向してない。

Lisp 系でかなり強く静的型に寄ってるのは Carp だと思う。
Lisp 系にしては GC がないという思い切った設計になっていてメモリ管理は Rust を参考にした借用モデルを使っている。
でもまあ Lisp らしさって動的な部分にあると思うんで、あえて Lisp でやる価値もそんなには無いかなぁ……という気持ちもある。

>>58
Carpもnull safetyは備えてないみたいだね

NimもそうだったしCにコンパイルする言語は
null safety無しのほうが実装難易度が低いんだろうね

>>59
何のことを null safety と言ってる？
carp でヌルを発生させる方法を私には見つけられない。

>>56
最初からRustで書けないのが面倒だよなあ

最初からRustで書けば良いのに

整合性チェックが広範囲に波及するから
git branchとか使わないと最初からRustで書くのはしんどい

面倒だからバージョン管理使わない派の人だと
変更を元に戻すのも面倒になって詰む

https://www1.daiwair.jp/qlviewer/e-cast/2509059702scTvDPnFfu/index.html

>>51
人を全く介さずにCコンパイラのコードを自動生成させたのは初めて
なぜ作らせるものをCコンパイラにしたかというとLinuxをコンパイルできて動くという点で実用性を示せる題材だから
そして自動生成したRustコード製によるCコンパイラという点

>>65
Opus 4の頃からやってると書いてあろうが
読んでないのか？

今回は2週間$20,000かけて作った
2カ月前からほったらかしのドッグフード

https://www.youtube.com/watch?v=YVbKTpfRbcc

()乙

このスレで発達イジリやめようや
ム板なんて多少なりとも発達気味な人多いんだから仲間だぜ

>>47
もともと、Cコンパイラのソースコードは、完全なものから最小のものまで色々なレベルの物がネットに転がっている
から、AIは当然の事ながらそれを学習しているだろうから、有利に働くと思う。
ブロック崩しのソースコードがネットにあるから「ブロック崩しのコードを書いて」と言えば書けるのは当然なのと
同じ。そもそもブロック崩しとは何かがAIは言葉以上には実は分かってない。

>>71
[追加]
・現実のCコンパイラは速度を上げるために複雑なコードになっていることが多い。
・最適化するために、最適化層に至る前の層も複雑なコードになっていることが多い。
・例えば、後半部分を LLVM にして良いなら劇的に簡素化される。

>>72
[追加2]
・どういう仕様書に基づいて生成させたのかも重要。
・人間用のANSIの仕様書は難解。
・プログラマーとコーダーを分けて考える人がいる様に、仕様書を分かりやすく書いておけば、
　それをこーどに直すのは易しくなる。
・例えば、・・・の時には・・・とする、というような場合分けを丁寧に自然言語の言葉に書いておけば
　それをプログラミング言語に直すのは容易になる。
　しかし、そのように書かずに人間的な言葉でなんとなく書いてあれば、コードに直すのは難しくなる。

>>73
[追加3]
・ANSIのC言語でも、前処理(preprocess)のマクロ展開は難解な部分とされていて、分かりにくい言葉で書いてある事が有名。
　それ故に仕様に曖昧さが残るといわれている。
・もしその部分を丁寧に書き直して分かりやすくすれば、コードに直すのは容易になる。
・しかし、現実のプログラマーの仕事は、そのような曖昧さの残る難解な仕様書から、本当に分かる仕様に
　変える作業も含まれている。

>>31
ffmpeg公式の4/1ツイートは失敗したrav1dへの皮肉だよね
https://x.com/FFmpeg/status/2039115531744334180

>>71-74
お前暇すぎだろw
そんな暇なら無駄レスする前にAnthropicのブログ読めよ

あと該当リポジトリのissue読めば多くの技術者がどういう評価を下してるかも分かるぞ

>>71
ネットに繋いで学習しない>>47と明記されてるようだが

Rustは遅い
でも安全
速度はマシンスペック上げれば良い
安全性はスペックのように気軽に上げれない

それはそう。
でも現実に今、目の前にあるカスいコンピュータがカスだという状況もある。

>>78
バカかw
ネットに繋いでないのとネットにある情報を学習してないのと違いが分からないのかよ
>>47の「Rust標準ライブラリの知識だけで」みたいなミスリーディングは意図的かと思ってたが真剣に理解できてないだけだったんだなww

AIがなかったらRustにもワンチャンあったかもだけど
もう駄目じゃね

>>82
AIにC/C++コードを吐かせると危険なことが判った
そのためC/C++分野は全てRustが貰っていくことになった

ハァ？

複雑になるとダングリングポインタが生じるコードなど紛れ込ませてくる
AIにはそれが起きないRustコードを吐かせるしかない

人間にやりやすいのは AI (LLM) にもやりやすい。
人間が間違えるものは AI (LLM) も同じように間違える。
良くも悪くも LLM は人間の言語活動の模倣なんだよ。

Claude Codeとかに書かせてても結構人間的なミスをするよね彼らはコンパイルエラーを見ながら修正するループを高速に回せるから最終的には動くものを出してくるけど
エラーにできない言語だと厳しい

丸投げだと初歩レベルの脆弱性をバシバシ仕込む、AIエージェントによる丸投げが業務レベルでも当たり前になってる世界で
熟練のプログラマでも初歩レベルの脆弱性をバシバシ仕込めるC/C++は本当にいいところがない

コンパイルエラーにしてくれる領域が広ければ広いほど生成AIと相性いいね
そしてRustが最もコンパイルエラーにしてくれる領域が広い

Rust の型システムの使い難さは静的検査の厳格さとのトレードオフ「ではない」という評価も有る。
つまりシンプルに出来が悪い (部分が多い) と考えられている。
それでもなお C++ とかより大幅にマシではあるんだが、これからもっと良い言語が生まれる余地はありそう。

同期Rustはいい感じ
非同期Rustは未完成のゴミ

>>90
Traitが基本的に早すぎる最適化に寄った言語設計だから、大規模プログラムとかインクリメンタル開発とかと相性が悪いというだけじゃない？

RUSTにも静的ダックタイピングとか構造的部分型とかは欲しい所。
（c++にも無い）concept の静的インターフェイス化とかやってる言語ないんかな？

>Rust の型システムの使い難さは静的検査の厳格さとのトレードオフ「ではない」
めっちゃわかります

Rustの次の言語に期待だね

Rustはまだコンパイル時間が短すぎるから次の言語に期待する人の気持ちも分かる
わいはもう十分だけど

次に来るのはもうAI前提の仕様記述言語みたいなものだろうから、もうどうでもいい話だわな

>>95
>Rustはまだコンパイル時間が短すぎる
長すぎるの間違い？？

>>97
もっとよい言語が出来たとしたらコンパイル時間がもっと長くなる (から Rust のコンパイル時間は相対的に短い) という皮肉だろ。

>>98
ほんまかいな。

Rustの比較対象がまだ存在しない未来の言語になってる時点でなあ
現状Rust一択だと認めざるを得ない

Rust が良いとしても Rust ほど高度な言語機能が必要ないケースで使えばそれは不必要に設計コストやコンパイル時間を浪費してるってことになる。
牛刀をもって鶏を割くってやつだ。
そんなにいつも Rust が唯一の選択肢だとは思わないな。

最近JavaやC#使うならRustでいいと思ってる

Rust自体はAIで生成してもう手で書かないわけだから、もうそのへんの事務のおっちゃんでも楽勝なレベルで難しいってのは問題にならなくなったけど
コンパイル時間についてはAIでも消えないからなあ

そのうち、AIがビルド後のバイナリを返してくれるようになる

技術的に可能であることと一般に普及することは異なる。
データセンターが AI のために使っている電力は想像以上に伸びているようで、昨今のエネルギー事情を考えれば AI に依存しきってしまうのはリスクが大きい。

AIが生成した複雑なC/C++コードが安全かどうかを実行前に静的に調べる方法が存在しない点がネックだよな

>>106
動かしてみたら分かるからいいよ
あとコードレビューも役に立つ

コンパイルエラーにしてくれるRustはAIと相性がいいな

java c#てプログラマから嫌われすぎやろ
これ使ってるoss見たことないし
まあ実際うんこだけども

Java も C# もそれなりに存在感はあるし、 (昔はともかく) 今の言語仕様は使いやすいよ。
動作環境をサンドボックス化出来るというのもセキュリティが重要な場面では有用。
ただ、当初に計画されていたほどには理想的にポータブルには出来なかったし、環境の分離はネイティブハイパーバイザのほうが性能が出るので相対的に価値が失われてしまったという事情はある。
なんだかんだで Android が Java の技術を基盤にしているというのもある。
Java や C# のクソなところは嫌でも使わざるを得ない場面があるってところだ。

C#はともかくJavaのOSS見たことないのは流石に他の言語ディスっていいレベルじゃないぞ

Rustの一番の問題は誰も使ってないってことなんだよ
AIすらRustを苦手

JavaはOracleが余計な事してから仕事以外で使う気失せた

今はOSSでもAI関係以外は入れないのが普通だろうし
PythonやElectronばっかりで、SwingとかEclipseのあれの上で動いてるツールとかは
若者だと見たことないのは普通かも

見えてるOSSの範囲が狭すぎじゃね？

ローカルのデスクトップ環境にインストールするアプリやツール類に限った話ならJavaやC#が少ないのは当然だよね

どうしてボコボコダウンロードしまくるの?

小さなライブラリをビルドするだけなのに

リリースごとのアーカイブにまとめないでリリースになんの意味があるの?

どうしてもなんどもダウンロードさせるなら
リリースアーカイブを配布するのやめなよ

>>116
最初の1回しかダウンロードしないだろ
その後はオフラインで開発できている

>>113
ほんそれ
AIが生成した複雑なC/C++コードじゃなくて
AIが生成したRustコードを基にAIが生成した複雑なC/C++コードを吐かせれば良いのでは
怪しいかどうかはRustコードの方を観れば良い

バイブコーティングだと
シェア1位がTypeScriptで
2位がRustだという記事を見かけた

まぁJavaScriptとか明らかに学習量多いはずなのに
普通に動かないコード出してくるからな
やはりコンパイル時点である程度チェック出来ない言語はLLMには厳しい

>>115
C#のOSSはコード資産の量としてはまあまあ多いけど、
ライブラリばっかりで単独で使えるものは極めて少ないから、C#使ってないなら視界に入らないのはまあ仕方ない
Javaが見えてないのはさすがによほどの初心者か、そうでなければ見たいものしか見えない病気としか考えられない

Javaはオワコン
javascriptよりオワコン

java c#はベンダーもキモいし仕事でしか使いたくない

JavaはWeb系の自社開発みたいな、消滅してもさして困らないところではシェア低いけど
公共系の社会の基盤になってるようなところではシェア高いから安泰だろう

Javaを極度に嫌ってる人はOO苦手が多いイメージ

Javaはマインクラフトの実績がある時点で他の言語は足を切って寝ないといけないよ

javaもRsutを同じ土方言語じゃん
仲良くしろよ

JAVAはnullが無ければマシなんだけどね。

今後はJava捨ててRustでええやろ

もうほとんどRustに書き換えたけどRustええわ
ビルドがどんどん重くなってるのが今難点だけどaxumもレスポンスが素晴らしい

正直api程度なら書き味も含めてgoでいいような

見た目でRustをパクってる新言語はいくつもあるけど、Goをパクってる言語はない
だから書き味でGoはないと思う

>>131
api程度ってｗｗｗ

Goの書き味最悪なんだが
使う理由は「クラウドアプリでなんか強いらしい」とかじゃないの

Go は C を順当かつ「最低限度に」改良したくらいのポジションだと思う。
こういうのでいいんだよこういうので……という手頃感を感じている人は多いと思うが他の言語がこぞって真似したくなるほどのインパクトはない。
高度な抽象化は皆が想像するほど必要ではないしむしろ害悪なことが多い (不必要な抽象レイヤを構築するために手間をかけてしまう事例が多い) という発見が Go の思想の前提にある。
そして実行時の性能も普通は CPU より I/O のほうが足を引っ張っているので無茶苦茶に最適化を頑張る必要はなくランタイムライブラリを頑張ってチューニングしておいたほうが効果的としている。
だからマイクロベンチマークでは Go はそれほど成績は良くないのにアプリケーションの性能は悪くない。
キッチリするよりも素朴で良いというのが良い書き味に感じるか不快と感じるかは人による。

Rustは過剰だしなあってときの代替がgolangしかないだけ

GoはC言語並の素朴さで並行プログラミング対応のスクリプト言語のようなもの
その範囲内においてメリットを感じる領域と人たちがいる
その領域でもガッチリ書くならRust

なんだかんだで大手が採用しているというのは安心感がある。
もちろん言語として及第点以上だというのは大前提として、さらに選択肢を絞り込むとなったらやっぱりそういう安心感が左右してしまうってのはある。
良し悪しを論じる前にそもそも知られてなければ選択肢に上がらないってのもあるから名前を知る機会が多いほうが使われやすい。

Goは標準ライブラリが充実していて枯れてるから、AIがブレにくいのは強みだね
その点Rustは周辺がカオスすぎて収束しにくく、AIにとっても人間にとっても厳しい面がある

Goは例外なくしてる上にChdir()の戻り値無視してファイル作ってもスルーするから
暴走する前にkillする思想のRustユーザには受けない
そんなレベルまでC言語に寄せなくてもいいと思う

やっぱ大手が採用してる言語っていうのがでかいのでは
メンテとか含めてコントリビュータ依存にならないのは大事だと思う

crates.ioの運営費って大手が負担してくれてるのかな？

Rust Foundationが出してるやろ
大元は大手含むスポンサーだが金以外でどこまで関与してるかは分からん

ぽまいらももっとgo布教汁！ｗ

Goは使える領域が狭すぎてな
文法も弱すぎる

// 文字型定義（Go布教用）
#[allow(non_camel_case_types)]
type rune = char;

？

Goの文字型はルーン文字だった記憶がある

>>144
良し悪しとは別に好き嫌いがあるのでな。
プログラミング言語は機械の動作を合理的に記述する道具であるだけでなく人が読み書きするということを忘れるな。

>>149
残念ながら人が読み書きする時代は終わってしまったのだ

書かないはギリあっても読まないはまだ無理やろ

>>150
AIは、やりたいことが定型に近い場合は伝えやすいが、他の人が余りやってない独自なことは、詳細を自然言語で
伝えるのがめんどくさくなるので、プロググラミング言語で書いた方がむしろ効率がいい。

まだそんなこと言ってるのかよｗ

馬鹿には無理

>>153
Excel の簡単なプログラムだけしている様な人は AI で全て出来ると思っている人が多いが、
もっと難しいプログラムをしている人は、そうではないと言っている人が多いと思う。

AI に関して :
1.「枯れた技術（Webフロントエンドなど）には強い反面、非常に特殊なハードウェア制御や、
　まだ世の中にコードが少ない新しいライブラリ、低レイヤーの最適化などでは精度が落ちます」
2. AIは、「もっともらしいが微妙に間違っているコード」を書いてくることが有る。

>>156
3. 間違っていてもそれが発覚するのがレアなコードの場合、テストしただけではすり抜ける事が多い。
　そのため、コード自体を良く見て頭の仲でシミュレーションし、どんな場合でも、
　あるいは、レアケースな場合でも、安定して動作するかどうかを見極める事が必要である。

OpenClawの人はOpusレベルのモデルを使うなら
AIが自己テストと検証でコミットしていいと言うなら、人間はレビューもせず無確認でコミットしてよく
実際にそれで開発を回して問題も起きては無いと言っている

>>158
nVidiaのCEOは、既に AI が AGI に達したと言ってみることもあれば、AI は人間から仕事を奪うものではない、
などと言ってみたり、よく分からない状態にある。

>>153
まだHTMLの仕様書を作る前の段階(今から数十年前)で、それを考えるのを今の最新AIに丸投げしても、
良い仕様書が出来るとは思えない。
だから人間が考えないと。仕様書を考えるのもプログラミングの一部。
それに、それを表示するブラウザ(Chrome)のプログラミングも、細かい指示なしに全部丸投げでAIが作れる段階には
ないと思う。
それに機能追加とか、バグ取り、機能修正なども今の AI には難しいと思う。

AIωがあなたの仕様書にはバグがありますって言ってくれる時代まだかな

>>155
2年前ぐらいのことの話？

Firefoxがクラッシュする原因の最大15％がメモリのビット反転によるものだという分析結果
https://gigazine.net/news/20260306-firefox-bit-flip/

>>163
Firefoxも安心安全のRustを採用すればこんなことにならないのに馬鹿だなｗ

Rustのメモリ安全あればECCも要らなくなるというのか

宇宙線のいたずらも防げる

>>164
Firefoxのメモリ管理部分はC++で書かれたまま
Rustになっていない

メモリ安全とミドリ安全って似てるな

>>163
今だにFFの人のかなりの割合が元パワーユーザーか何かで
年期の入ったPCを使い続けてヘタっているのに
CPUやメモリをオーバークロックしてるのでは

Rustの本家本元がこれじゃあ広まらんわ

何年も前にFirefoxは資金難でRustを手放してIT大手各社で結成したRust Foundationへ移管したよな
Webブラウザについて今はむしろChromeやEdgeのRust化が進行している

Linuxの時もそうだったが、指摘された問題点を信者はいつも全否定してきた。

Firefox開発者「 ちくしょー！ Rustさえ手放さなければー！ 」
↑こんな感じか
いろいろ難しいんだな

>>173
Rust を使えなくなる形で手放したわけではないし、実態としては管理の手間が消えただけなので Firefox 開発者が後悔するような要素はないよ。

やっぱ自分で管理するよりコストも手間も減って助かってるってことね
Mozillaやるやん

ビット反転なんて初めて聞いたけど、そんなのが起こるのはそもそもコンピューターとして失格だろ

>>176
ビット反転とかはプログラマーしか使わなさそう

>>164
リンク先の記事のいう「ビット反転」とは、ソフトウェアでなく、ハードウェアに起因するもので、
ソフトウェア実行時の不具合の多くはソフトウェアそのものや実行環境との相性によるものですが、ハードウェアが
原因で不具合が発生する場合もあります。Firefox開発チームの一員であるガブリエレ・スヴェルト氏は、
「Firefoxのクラッシュのうち最大15％はメモリに存在する物理的な欠陥が原因だった」という興味深い調査結果を報告しています。
とのことだ。

>>176
残念ながらビット反転は普通に起きるので
サーバ向けのメモリには反転したビットを訂正できる機能が付いてるし
もっと高信頼なシステムだと複数のCPUで結果を突き合わせながら実行したりするのです…

マリオ64 RTA 宇宙線
で検索

宇宙線信じてる奴いるの？

>>181
ホントそれ

よく引用されるIBMの統計
Studies by IBM in the 1990s suggest that computers typically experience about one cosmic-ray-induced error per 256 megabytes of RAM per month.

最近の第3者研究
https://arxiv.org/html/2407.16487v3

Not all studies agree that cosmic rays dominate DRAM errors in production clusters; a recent large‑scale HPC analysis found no clear correlation between cosmic rays and observed DRAM errors at their sites, suggesting other failure modes and system factors matter. Treat published rates as context, not absolute truth.

宇宙線由来だけでなく半導体パッケージ内の微量放射性物質などの原因でもメモリのビットエラーは起きている
プログラムが常駐するサーバ用途などでは実際に問題が発生しているため
エラー自動訂正のECCメモリが使われてるよ

宇宙線はネタ半分だけど可能性は否定できない

宇宙線信者w

でも、再現性の無いバグという物は、ハードウェアや宇宙船が原因でも良くあることなんだ。
典型的には、変数の初期化し忘れ。
後は、Window の WM_XXXX メッセージが、非常に特殊ケースで順序が変わったり、来なかったり、余分に着たりすること。
あるいは、滅多に来ないが、0 での除算が起きるとか。
あるいは、マルチスレッドで微妙にタイミングがずれることがあるのが、実験ではなかなか発見できないとか。
ゲームの場合なら、2つのポリゴンの境界の目には見えないスキマみたいなところですり抜けが起きるとか、
シーン切り替わった時に2つのキャラが同じ座標に出現して重なって動かなくなったり、それが変なロジックにはまって
ハングアップのような事が起きたりとか。
その他、非常に多くの事が原因で再現性の低いバグが入り込む。

>>186
誤: でも、再現性の無いバグという物は、ハードウェアや宇宙船が原因でも良くあることなんだ。
正: でも、再現性の無いバグというものは、ハードウェアや宇宙線が原因でなくても良くあることなんだ。

＞でも、再現性の無いバグという物は、ハードウェアや宇宙船が原因でも良くあることなんだ。
典型的には、変数の初期化し忘れ。

↑脳がバグりそうになった

Windowsアプリだったら、CreateWindow() 直後に CMyWnd::OnSize() (WM_SIZE) が必ず来ることを当てにして、そこで
サイズが決定した/変更された後の処理をまとめて書いておいたとしても、特殊ケースでは、WM_SIZE メッセージが思った
タイミングでやってこないがために、サイズを発端とした多くの変数の変更や初期化が行われないとか。
子ウィンドウが初期化されるタイミングでは、親ウィンドウのそのような変数が初期化されていることを前提にして良い
のかどうか、OSの仕様をよく確認する必要がある。
基本クラスの初期化のタイミングが仮想関数やメンバ変数が絡んだ時に、盲点となる場合もありえる。
良くあるのは、メンバ変数の「親」の this を、メンバ変数に渡したような時に、thisのメンバがまだ
初期化されて無いのに、親クラスのメンバ変数を呼んでしまっているとか。
或いは、多重継承した時は、cast する時に、アドレスが変化してしまうときがあるとか。
もっと言うと形式的には同じ仮想関数なのに、引数の this と、関数定義部分の this は、実はアドレス偏差が
あって同じ値ではなくなっていることが有るが、余り語られることは無い、とかもある。
項いう事に気付かずにプログラムしていても、再現性の無いバグの原因になるかもしれない。

よく知られていることでは有るが、WM_LBUTTONDOWN に対して、WM_LBUTTONUP が対に来るのが基本では有るが、
Window A でボタンを押して、Window B でボタンを離すと、Window A には、WM_LBUTTONUP は来ない、という現象がある。
WM_LBUTTONUP が必ず来ることを仮定するとバグるが、実験ではそのようなことは発覚しにくいので再現性の低いバグになる。
或いは、MessageBox() が、Modal Dialog 的に出て停止しているときに、Windows OS の TaskBar の右下の小さな縦長の長方形
を押すと、全ての Window が画面から消えてしまうが、同じアプリだが MessageBox() の Owner 以外を RESTORE すると、
Modal Loop が想定したのとは異なる状態になって非常に分かりにくい現象が起きる。

ビット反転エラーだと判明したのは
例えば本来指しているへきポインタ値がランダムに1bitだけおかしいなど
バグでは起きえないことが起きていたわけだろ

>>191

>>191

Gabriele Svelto
@gabrielesvelto
And to reinforce this estimate I've looked at the numbers we got from the users who run the memory tester after having experienced a crash: for every two crashes we think are caused by a bit-flip the memory tester found one genuine hardware issue. Keep in mind that this is not doing an extensive test of all the machine's RAM, it only checks up to 1 GiB of memory and runs for no longer than 3 seconds... and it has found lots of real issues! 4/5

メモリテスターで分かる程度にヘタレタ機器らしいね。
基盤直付けのMacでもそういう症状があったとの事。

Gabriele Svelto
@gabrielesvelto
And for the record I'm looking at this mostly on computers and phones, but this affects *every* device. Routers, printers, etc... you name it. That fancy ARM-based MacBook with RAM soldered on the CPU package? We've got plenty of crashes from those, good luck replacing that RAM without super-specialized equipment and an extraordinarily talented technician doing the job. 5/5

>>188
宇宙船からコンピュータを守る方法ってないの？？？？？？

銅で3重に覆う

トイレを3個用意する

>>195
金属ケースの中に入れるだけでも効果が有ると言われている。
だから、自作PCの透明ケースを使う人はアホ。
せっかく金属で覆っていたのに。

ちなみに、宇宙線は通常、空からやって来るので、ケースの置き方にもよるが、PCケースの空に近い面が金属で有れば、
だいぶましになるが、斜めから入っていることもあるので、側面も金属である方がいい。
鉛などの「重い金属」は効果が高いと言われている。電磁波に対しては電気を通しやすいものも効果が高いと言われている。
通常、鉛は人体に毒性があるので、鉄、胴、アルミなどが使われる。
なお、同じ金属であれば、分厚い方が効果が高いと言われている。

現代の集積密度のコンピュータだとシールドで宇宙線を防ぐのはそれほど効果がない。
アクリルとかよりは金属のほうが効果があるのは本当だけどどっちにしろ些細な効果しかないので考えるだけ無駄。

半導体の設計の時点でビット反転を検出できる仕組みが必要だと考えられていてそれが ECC なんだが主要なメーカは家庭用途・オフィス用途程度では ECC なしでも充分な信頼性があると言い張ってる。
でも大規模に運用されているソフトウェア (もちろん Firefox もそう) のエラーリポートでは実際問題としてメモリのビット反転による問題が結構な割合を占めている事実もある。

宇宙線でレジスタ書き換わるとかメモリ書き換わるとか普通にあるから、想定したコード書けばいいだけ
下手すると通信ケーブルとかバスラインでも変な値に化けることあるよ
組み込みとかやってるならチェックサムや再送入れとくと良いとされる

なんのスレやねん

キチガイのスレ

Rustスレ的にはどうでもいいことに限って
複おじの琴線に触れて自演がはじまってしまう

こんなスレどうでもよくないと思ってるの複おじだけや

部屋の電灯を蛍光灯からLEDに変更したら
紫外線か高エネルギー粒子が増えたのか
保存してたBDディスクの劣化が速くなった気がする

>チェックサムや再送入れとく
伝送部分はそれで解決してもレジスタやメモリ書き換わるのはどうすんの

そらメモリもプロセッサも冗長化して多数決よ

rustling 全部終わってから日本語版があることに気付いたorz
https://github.com/sotanengel/rustlings-jp

Servo v0.1.0 (LTS) がリリースされたぞ
近ごろ勢いづいてる

Servoは5chが正常にレンダリングされるところまでいくにはどれぐらいかかるだろうか
CursorのところがAIエージェント丸投げで、Googleがレンダリングできるブラウザをゼロから作ったって自慢してたりもしたけど・・・

ladybirdでよくね

いいね

Servo on Android just got a big refresh:

- Material 3 design
- A dedicated tablet layout
- A new browsing history view

https://github.com/servo/servo/pull/43795

https://floss.social/@servo/116414209371196954

>>213
PC用ももう少しservoshellに手を入れてほしいが
あくまでテスト用UIて扱いなのかな

まず間違いなくBlinkがAIによってRustにリライトされる方が早いから、もはやどうでもいいな

ossもai製のうんこプルリクが多くてメンテナが困ってるそうな

理解した上で使ってればいいけどな

実際AI丸投げのプルリクやら技術記事やら投稿してるやつらは溢れるほどいるけど
金に直結する企業ならまだしも、個人でそんなことやって何か承認欲求満たされるもんなのかね？

具体的に自分が欲しい機能があるなら単に要望を出すだけよりは(AI 丸投げでコードとして質が低くても) プルリクエストの形になっているほうが効果的な可能性はある。
今までその機能を欲しいと思ってなかった人が使い勝手を確かめて有用だと認識すれば真っ当なパッチを作ってくれるかもしれないので。
プルリクエストをすることが目的になってるやつはなんかおかしいなとは思う。

日本に第三帝国を造るらしいぞ🇯🇵
https://x.com/teamjces
https://farcaster.xyz/teamjces

やぱCよりも遅いの？
なんでリヌースは認めたんだろ。

もちろんCより速いこともある
抽象度の高い記述がそのまま最適化されやすくなるために起こり得る

>>211
試していないから現状はどうなのか分からんが、あと数ヶ月くらいで出来るようになるか？


@servo is now capable of rendering @Mastodon !

Servo is becoming usable, such a good news ! (this post was also created from #servo)

#webbrowser #rust

https://mastodon.social/@rsm92/116435935388464051

今のServoで5ch、普通にレンダリングされるけど？
レス先のポップアップとかも
細かい挙動までは知らんけど

まだそんな話をしてるレベルなんだな

Linux Foundationに移管されて息を吹き返したか

この更新ペースだと完成しても使おうってならんくね

そもそも何のために開発が続いているのか

生物多様性と同じ。
実装の多様性に乏しい状態は規格の健全さを損なう。

ブラウザってよくメモリリークぽい挙動するから期待してる

Firefox「…」

>>228
Tauriのレンダリングエンジンとしての活用が期待されている
内部のコンポーネント単体でも使い出があるだろう

最近はAndroidとかOpenHarmonyサポートが入ったりしてるから
アプリへの組み込みレンダリングエンジンとして期待されてるんだろうね

でも完成するのは20年後とかなんだろ

>>234
お前が完成させるんじゃい！

>>232
Tauriアプリ配布にServoエンジン同梱になれば
サイズが増えるがよろしいか？

約100MB増量ですな

>>236
選択式になるんだよ
同梱したい人だけが同梱する

プログラミング完全初心者のパソコンの大先生だけどrust始めるね

RustってCを学んでからやったほうがいいと思ってたんだけれど、どうなん？
Cをやる前にthe book読んだら全く以て意味不明だったわ
わいの頭の問題かもしれんがｗ

まあCSをしっかり学んでからやる言語だよね
人によっては数学から必要

C の延長線上にある低レイヤ向け言語ではあるけど型システムは抽象度の高い Haskell 風だし Lisp 系から持ち込まれたマクロも合わさったキメラ的デザインだよ。
低レイヤ側の人も高レイヤ側の人も馴染みにくい部分がある。
たぶん Rust と立場が近いのは C++ だと思う。

Rustはアセンブラを知ってる人間がニヤニヤしながらイテレータを選ぶもんだろ。

Rustやるならまずアセンブラだな

そもそもCは高級アセンブラだ。

74の履修は赦されたか

まあ読め。下にスクロールしていったらフランス語版と日本語版が出てくる。

https://teamjces.github.io/www/paper/2026-03-31-compile.pdf

rustなら右辺値参照なんて事を考えなくていいって事か。

Rustと立場が近いのはC++と言う点は同意するが
RustとC++の相性は最悪

継承なしのOOPならCでもできるし実際やってた。

リーナスもc+はクソてゆってた

Cにプリプロセッサの皮被せたのがC++の最初だから
CでOOP出来ないわけないんだよね

今のTypeScriptみたいなもん

オブジェクト指向自体はプログラムの構成というか方法論なのでプログラミング言語によらず可能といえば可能ではある。
でもプログラムは人が読み書きするものだからね。
オブジェクト指向の思想で書くのならオブジェクト指向に「見える」のが望ましいし、プログラミング言語として様々なサポートが充実していればより良い。
どれくらい充実していればオブジェクト指向言語と言えるのかは明瞭な基準があるわけではない。

継承ありのOOPもCでできるし実際やってた。

C++はいらない子だったのかもな

いちお　カプセル化と継承と多態化は出来ないとね。
まぁちろちろ調べてたら、C系との住み分けが出来そうで良かったね。
rust 勉強しようっと。

>>255
C++ の理念のひとつは「今、使えるものでなければならない」だよ。
理想的なものが出てくるまでぼんやり待ってるわけにいかないだろ。
C++ が登場した時期に C++ みたいなものはなかったんだから要る言語だったよ。
今からも要るかどうかは知らんけど。

>>257
そういう時代だったんだね

C++が要らない子と思われていたのは
MFCが30年以上もC++の顔して覇権をとっていたからかな
GoFのInterViews風の設計や、WTLが普及していれば色々マシだった

MFC全盛期はデスクトップアプリケーション全盛期でもあるけど、あのころってC++以外にGUIで使える言語何があったかな
まともなのDelphiぐらいで、後は当時の貧弱なPCでは壮絶な重さのJava+Swingぐらいしかなかったような

>>260
そこに入るのはVisual Basic のことか？それともTcl/Tkのことか？

DelphiはIDE、言語としてはObject Pascal
DelphiやC++BuilderならVCL、さらに前のOWL

みんなrustやってるから仕方なくやってるけど、macroは嫌い

> sudo, core-utils, ntpdとしてRustベースの実装が導入されています。core-utilsの一部
> （cp, mv, rm）はGNU実装のままですが、これら以外はRust版が導入されます。
https://gihyo.jp/admin/clip/01/ubuntu-topics/202604/24

C++ はカスだとは思われていたけど要らないと思ってた人は少ないでしょ。

>>261
VBは最近は影も形もないから忘れてたけど、俺も当時はVB6で業務システム作ってたな
Tcl/Tkはあの当時からそんな使われてたかな…git-guiぐらいしかTcl/Tkで作られたアプリ思い浮かばないんだけど

世の中の重要なソフトはC++多いし
Haskellなんかよりも圧倒的に世の中に貢献してる

Cはもっとだろ。

C++も膨大な資産あるからね

まあ変換ツールとAI次第でどうなるかわからんけどね
クリティカルな部分は優先的に置き換えが進むだろう

C++はどんなOS書いた？UnixはそのすべてがC（とアセンブラ）で書かれたよね？

>>260
Objective-C
tcl/tkは結構使われてたイメージ

Haiku OS？

>>270
横槍だけどwindows

Mona…？

WindowsはC++じゃなくてCだな
APIやFrameworkやCOMにはC++使われてるが

linuxも周辺からちょびちょびrustが絡むって事でしょ。
残念ながらc++は嫌われてまった。

Windows のカーネルにも一部は C++ が使われてる。
Windows はシステムコールとそれ以外を (アプリケーションからは) 区別しないし、カーネル以外のコンポーネントも Windows の一部ではあるので総合的にはかなり C++ は使っていると言っていいんじゃないか？

嫌われたんじゃなくて論文読め。RustですらCのABIでやってくことにしたんだ。C++が例えば「CのライブラリもC++でコンパイルし直そう。そうすれば名前空間の恩恵に与れる」みたいなことになったか？

https://teamjces.github.io/www/paper/2026-03-31-compile.pdf

カーネル以外がrust化すれば色々変えれるかもね。昔のelf移行のように

snapdragon x2出たのにQualcomがパッチを投げないせいでlinux on arm実現しないのどうにかしてクレメンス…

ubuntuでhello world 出来ました。わーいわい
次はmutithread でsocket遊びします。

>>266
まあtclでというのはあんまりないかもね。またVB/VCよりもう少しふるい。

うむ、時間ができたらこれも遊んでみるとよい。

https://twitter.com/i/status/2047475020486816069
https://twitter.com/thejimwatkins

C++ だとそれぞれのコンパイラは「意図的に」マングル規則を違わせていて統一を避けてる。
オブジェクトのレイアウトや関数呼び出し規約 (ABI) を統一したとしてもそれ以外の様々な部分で協調できないと簡単にクラッシュするからうっかり混ぜることがないようにそうなってる。

ABIがウザければこういうのに逃げる手もあるぞ。Common Object Model on Java Virtual Machine。COM/JVM だ。

https://twitter.com/i/status/2047361259293806634
https://twitter.com/thejimwatkins

JVMがあるのはいいとして例えばJavaのオブジェクトとして振る舞うファイルシステムがRustとかで書かれたらどう思う？ファイルシステム以外のものもさ。

ギリギリのチューンなんて個人のコンピュータじゃなくてクラウドにやらせとけばいいんだよ。

有名な話だけどハードウェアが速いのは「並列だから」だ。あと「同じことの繰り返し」も速いみたいだな。

>>284
>C++ だとそれぞれのコンパイラは「意図的に」マングル規則を違わせていて統一を避けてる。
>オブジェクトのレイアウトや関数呼び出し規約 (ABI) を統一したとしてもそれ以外の様々な部分で協調できないと簡単にクラッシュするからうっかり混ぜることがないようにそうなってる。
そういうことよりも、gccのマングリングにしてしまうと、gccのコードを使ったと疑われて、
GPL違反だからソース公開しろ、と言われて名誉毀損されてしまいそうだから、gccのマングリグにだけは絶対にしたくないという
事情がある。
msvcのマングリングだと真似てもそいいう事は言われなさそう。なぜなら真似るソースがないから。

jvmとか重すぎてうんこ
rustの80倍メモリ食うてペイペイもゆってるけん
blog.paypay.ne.jp/scaling-paypay-with-rust/

>>288
事実は逆だ。
同じようなことの繰り返しが多いことの発見からそれを効率的にこなせるように設計されるようになった。

jvmは過去で一番うんこだったな
良いとこ一つでもあったか？Rustは本当に神コスパ
C,C++の頃は苦しんでたけどAIが今はあるし今までの時間が一番悔やまれる

メモリの安全はAIにやらせるからRsutはいらない子になったはず

JVM の元々の意図は組み込みシステム用途、特にサンドボックス化が重大なポイントだった。
たとえばブルーレイディスクのメニュー画面を比較的自由に制御できるのは JVM バイトコードを使う仕組みになってるからだが、
サンドボックスが不十分だと再生機器を乗っ取る攻撃に使えてしまう可能性がある。

サンドボックス化はウェブのバックエンドに有用だという方向になってからが混迷の始まりだが当初は上手くいってた。
チューニングを頑張るよりもスケールアウトで対処するという思想で回してたから。
ところが世の中の情報システムが発展すると「もっと」という経営的要求が出てくる。
スケールアウトもするが個々の性能も引き上げろってことだ。
そうなるともう JVM でどうにかするには限界を過ぎてしまった。
そんでもって今はハイパーバイザの技術で実行環境を分離するやり方が出てきたからなおさら。

てな経緯だから一応は JVM が有用だったときはあったよ。

ハイパーバイザの方がトータルでメモリーを食うが？

現在のサンドボックス化はWASIでRustで書いてるよ

そりゃGNUハイパーバイザというのが理想だと思う。

独習Rust
¥4818
6/15

たか

技術書の値段はそんなもんだよ。
何もかも値上がりしている昨今の事情を考えればそんなもんでおさまってるのはかなり頑張ってる。

unlimited に入った方が

独習シリーズは昔C言語でお世話になったけどRust版は目次が心配になるな

第9章　構造体とトレイト
　9.1　構造体
　9.2　ジェネリクス
　9.3　トレイト
　9.4　列挙体

列挙体がunionみたいな扱いになってそう

まあunionであることに違いはないか…
せめて構造体の次に並べてほしかった

列挙体っていう表現は初めて見るな

enum とは違うんかい

日本語か英語かそれだけのこと

>>302
トレイトは構造体に対するものではなく全ての型に対するものだから「構造体とトレイト」のタイトルに違和感がある

enumは列挙型でよいけど
普通はトレイトより先に登場させるものだよ
例えばthe bookのように「列挙型とパターンマッチング」
そういえばパターンマッチングの章立てがない？

関数型を学ぶとこの辺自然になるがOOPから来るとこの並びになるんだろう

Rustのenumは関数型で言うところの直和型、実装的にはdiscriminated union

Enumを列挙体観たく表現してしまうのはC/C++の悪臭だよな
翻訳は違う名前にするべきだった

俺のツイート
¥0
4/30

https://twitter.com/i/status/2049648080182751510
https://twitter.com/thejimwatkins

その第9章までenumが出て来ないならパターンマッチングを扱う章はどこ？

第1章 イントロダクション
第2章 Rustの基本
第3章 演算子
第4章 制御構文
第5章 関数
第6章 所有権と借用
第7章 ライブラリ
第8章 コレクション
第9章 構造体とトレイト
第10章 スマートポインター
第11章 エラー処理
第12章 モジュールシステム
第13章 テスト
第14章 マクロ
第15章 高度なプログラミング

目次セクションが別にあってそこに書いてたよ

最終章にならないとこれらが出て来ない…

第15章 高度なプログラミング
　15.1　マルチスレッド処理
　15.2　async/await
　15.3　属性
　15.4　ライフタイム

マルチスレッドは後回しで良いと思うが、ライフタイムをそこまで後回しに出来るもんなのか？

昔はmallocを解説せずに終了するC入門書もよくあった

目次見比べた感じだと独習Javaをベースにしてそう
章の並び順が近いしライブラリの章の内容が一致してる
Javaは標準ライブラリ＋例外だからいいけど
Rustでエラー処理の前にライブラリの章があると不自然だな
サンプルコードはtry/catch感覚でunwrapするんか

独習Rust
https://www.shoeisha.co.jp/book/detail/9784798189314

独習Java 第6版
https://www.shoeisha.co.jp/book/detail/9784798180946

>>316
ライフタイムは参照を使ったら必須だよなあ
Rust本で一番最後にライフタイム持ってくるのは理解に苦しむ

Lifetime Respect 三木道三:2001

Rustの場合、エラー処理の基礎を入門させられるより、anyhowの使い方が書いてあった方が
初心者には嬉しいだろうな

>>321
冗談でも止めてくれ……

なんとanyhowを返すライブラリを公開してしまったダメな例もあるから同時にthiserrorの習得も必須

まずは標準ライブラリの範囲で初心者に向いてるエラーの返し方はio::Result<T>
発生するエラーの多くがioエラーな点とそれ以外のエラーはio::Error::other(err)で包み込めるため

同名Resultは初心者には紛らわしいな

むしろio::Resultもanyhow::ResultもResultのaliasだから同じResultを用いているのだよ
そしてパラメータはT一つだけになるから曖昧性もなし

std::result::Result<T, E> じゃいかんの enum

何でもかんでも同名同名
ライブラリAとライブラリAを再エクスポートしたライブラリBとかあるとバージョンがどうのこうので面倒

std::io::Resultもanyhow::Resultも同じくstd::result::Resultなので振る舞いも使えるメソッドも同じ
むしろ別の名前を付けられたら混乱する

Errの型が違うだろ

>>330
違うのではなく<T, E>のパラメータEが定まっているだけ
それでパラメータ1つの<T>になるため容易に区別を認識できる

独学でRustマスターするなら独習Rustの順番だとよく分からないと思う
公式のブックを読んだ方がマシ

>>328
tokioのプリミティブと標準ライブラリのプリミティブ (Mutex, mpsc) の違いとか、
tokio_stream の StreamExt と futures の StreamExt の違いとかも初見じゃ分かりづらい

公式のブックを終えられる人はエリートだよ

色んなサイトははあるだろうけど、まぁ山田さんの本だし、流れは大体わかるので買いますよ。
老眼なのでkindleで。不明点はここに書くかも。

>>331
そう言う理由なら猶更
特化側のio::Result<T>やanyhow::Result<T>よりもresult:Result<T, E>の方を強く薦める

Result を同名で定義することについて、個人的には現行の慣例のほうが良いと思うがエディタが出すヒント情報にモジュール名修飾がなくてよくわからない場合があるといった使いにくさはある。
もはや慣例が確立したのだから慣例通りにやって使いにくいのは開発ツールのほうが悪い。

名前空間が分離できてればResultの型エイリアスがあっても別に問題無いんじゃないか？
動的型付け言語だと頭爆発しそうだけど、静的型付けならコンパイル時に型エラー捕捉できるし

直接のResult<T, E>は滅多に使われない
thiserror等で自分のエラーを定義してるのなら
常にResult<T, 自分のエラー>になるから
type aliasで自分のResult<T>にしてしまう

io::Result<T>やanyhow::<T>も同じ理由でそうしている
どちらも自分のエラーはio::Errorとanyhow::Error
自明なのにわざわざResult<T, anyhow::Error>と何度も書くのはめんどい
だからanyhowを使う時はuse anyhow::Result;してResult<T>だけを使う

Resultのaliasを定義して使うのは悪いコーディングスタイルだって
主張してる人がたまにいるね

Rustの標準ライブラリからanyhowまで全てを否定することになるそういう人がいてもいいけど超少数派

良いとか悪いとか言ったって標準ライブラリも一般的な慣例もそうなっちゃってるんだし、これから変えられる可能性はもうないだろ。

型エイリアス使うのは構わんから
Rust勉強してる人には最初に本体のResultを教えてくれ

どうせAIが書くんだからどうでもいいよ
エイリアスは積極的にAIに使わせてトークン削減しろ

(1) fn foo() -> Result<()>
(2) fn foo() -> io::Result<()>
(3) fn foo() -> Result<(), io::Error>

(1)より(2)か(3)のほうがコンテキスト探らなくていいからトークン削減できるじゃね？

それはResultとは関係ない問題
何をuseしてるかで変わるため判別できる

どのxxx::Resultをuseしていようが関係なく
関数の返り型は常にResult<T>になるからコンテキストは安定していてトークン削減できるんだよ

1と2一緒じゃね

二つのxxx::Result<T>が同時に出てくることはないから混乱しないんだよ

例えば以下の単純な文字数を数える関数を作ったとする
fn foo(path: impl AsRef<Path>) -> Result<usize> {
Ok(fs::read_to_string(path)?.chars().count())
}

もしanyhowを使う場合
use anyhow::Result;だけでいい
途中にio::Resultが返されるけど自動的に変換されて出て来ない
std::error::Errorトレイトを実装するエラーならどれも自動変換される

もしthiserrorを使う場合
自分でMyErrorとResultを定義する
type Result<T, E = MyError> = std::result::Result<T, E>;
#[derive(thiserror::Error)]
enum MyError {
#[error("I/O Error")]
Io(#[from] std::io::Error),
}
io::Errorが返された場合の自動変換ルールはこのように自分で定義する
したがって関数から返されるio::Resultは出て来ない

もう一つ重要な点はこのResultの再定義の方法
type Result<T, E = MyError> = std::result::Result<T, E>;
デフォルト値をMyErrorとしているだけなので
本来のResult<T, E>としてもそのまま使える
同じ再定義をしているanyhow::Result<T, E>も大丈夫

>>349
>二つのxxx::Result<T>が同時に出てくることはない
んなこたぁないｗ

>>350
Rustで主流推奨のthiserrorやanyhowを使っている限り
各モジュールで関数に書くxxx::Resultは一つしか現れないよ

>>351
>thiserrorやanyhowを使っている限り
全然関係ないよ
もうちょっと視野を広く持とうね

結局Rustのエラー処理はthiserrorとanyhowが主流のままで行くんだろうか

Resultは自動変換しちゃうかmap_errなどで変換しちゃうからコードに書くことは稀かもな
唯一の例外は入れ子だが複雑な型はtype aliasしろと言ってくるので消える

anyhowより新しくて良さげな奴が３つぐらいあった気がする
使ったことないけど

最近はeyreも結構人気なんじゃない？

よーしらんけど、color-eyreが便利そう

こういうのはたとえ不便なところがあっても統一されていることが大事なんじゃないの？

目的が異なるので別
実行が遅くなるけどリッチにカラフルなエラーを出したいならcolor-eyreの価値がある

他によく名前を見るのが
terrors
error_set
eros
あたりかな、使ったことないけど

ものは言いようだな

erosは会社で使えないな

プログラミングクソなぞなぞ: certbotが会社で使えない理由ってな〜んだ？

言語の方針とはいえ、標準ライブラリが薄いのはやっぱ面倒だな
PyO3なんかを見てると、エラー型としてanyhowとeyreを、時刻型として chrono と time クレートをサポートしてたりする
こういう「同種の複数のライブラリへの対応」をする必要が出てしまうというのは、標準の薄さが原因

例えば tokio や serde に変わる強力なライブラリが出たら、結構な数のライブラリやフレームワークに影響するだろうし

他の言語でも似た問題はあるけど、エラー定義みたいな基本的な問題でも外部ライブラリを使うのが推奨されるエコシステムはどうなのかとも思う

Pythonが厚すぎるんでは？

標準化を目指すと日曜日と月曜日のどっちを0にするかで喧嘩になる

独自標準作ろうとするから
0は使わず日曜が7が世の中の標準
ISO 8601、JIS X 0301

そうだねUTF-8にBOM付ける馬鹿が出て来るのは実証済み

言ってるのは時刻形式とかISOとかの意味の標準化じゃなくて、言語の組み込み機能や標準ライブラリの話なんだが

都合の悪い話だからズレた話題にしたいのだろう

c++並に難しいのでわ

だって真面目に問題解決を考えるならAIと壁打ちしたほうがいいし……

逆にこういうときに一切槍玉に挙げられないlogクレートくんの存在感
真に優れた設計とはこういうことを言うのかもしれぬ

日時時刻のライブラリぐらいは、C++にも標準に入ってるからな
なんかRustの標準ライブラリって、機能の抜け方が歪なんだよね

たぶん、それをやりたい＆標準ライブラリとして使えるクオリティのものを開発できる人が
本体のメンテナにいなかったっていうシンプルな理由な気もするが

>>372
何が問題なのかわかってないやつに問題解決は無理！

時刻については標準ライブラリに入っていて欲しいことには同意するけどライブラリの管理について C++ と Rust では思想が違うので C++ と比較して論じるのはちょっと筋が違うんじゃないかな。
実態として chrono が事実上の標準の地位を得てるし、標準ライブラリなのかそうではないクレートなのかは cargo.toml に一行 (と必要に応じて use) を書くだけなのだからそれが大した問題だとは思わない。
chrono のメンテナンスが停滞したこともあるけど、標準ライブラリでも停滞するときはするので標準ライブラリに入れる強い動機は特にないだろ。

コアチームの人も時々言ってるけど別に標準入りしたからといって
メンテナーが湧いて出てくるわけじゃないからな
標準ライブラリを厚くしてコンパイラの開発が停滞するよりは
コンパイラに注力してくれた方がいいとは思う

>>377
今のRustは名だたるビッグテックが顔を連ねる金ジャブジャブプロジェクトなんだから、もうそういう物言いをする資格はない
どっかの会社が社員を供出すれば済む話

むかしのjavaそっくりだな

Rustの時刻ライブラリは、先行した chrono と time がいまいちで
最近やっと本命の jiff が出てきたところ

安定していて機能豊富で使い勝手のよいchrono一択だよ

真にオープンなら標準と非標準の扱いに差異がない方が健全ってことよね
標準にバックポートされないベンダーパッチが乱立するなら、言語をGPLにするしか無くなるし

jiff のほうが手厚いよ。
サポートしている機能の範囲は広いというか、そのために作られたのだから当たり前だが。
その上で多くの場合で chrono で十分には感じてる。

高い金もらってんだからちゃんとメンテしろや１

>>384
突然アホなことを言い出した

汎用OS並みのでかいプロダクトか、偏執的な規格バカメンバーがいないと国際標準にはなり得ないと思う
Rustにはその両方がない

それこそWasi Canonical ABIでは？
先行してるから、Rustでやらないって選択肢は無いかと思う

規格として提案するにはまず現行の仕様をまとめなきゃならんのだがさっぱり進んでいない。
https://github.com/rust-lang/spec
変遷が著しいのでまだまだ決定稿として仕様書にするのは時期尚早という考えなんだと思う。

Rust のあるべき姿としての仕様ではなく今の処理系の挙動を説明するという意味での文書化 (もし挙動と矛盾した場合は文書のほうを修正するという思想で運用される) はそこそこ出来てる。
https://github.com/rust-lang/fls
ただ、標準ライブラリについてはほとんど触れられていない。

ジップロックにみえたし

そんなドキュメント、Claude Codeに作ってって投げればできるだろうに

>>390
いや、Rustに関してはAIは全く使い物にならないから任せるのはNG

完成した言語が存在するなら文書化するのはある程度は AI にもできるだろうが、あるべき Rust の完成形 (未来の Rust の姿) を予言することは出来ないよ。
現行仕様をまとめる計画 (FLS) が回っているのだから Rust の実際の挙動が固まってきたらレビューしながら FLS から spec へ移していくんじゃないかな。
その作業のサポートには AI を利用することもあるかもしれない。

>>391
RustとAIは相性良い
それとは別に現在仕様が確定して部分は作れる
まだ仕様が確定していない部分にRustの本領発揮が見込まれるから全体をまだ決めないことが得策かな

プログラミング言語がAIと相性が良いか悪いかって、何かしらのソースを参考にしてるの？
それとも単なる想像？

似たような話で、Haskell や OCamlといった関数型言語は
Java に比べてAIのコード生成のスコアが悪かった、という論文はあるんだよね
https://arxiv.org/html/2601.02060v1

Rust はこれと直接は関係しないけど、Rust みたいに宣言的に書ける言語が
AIにとって必ずしも有利だとは限らないと思う

普通に使ってればすぐわかるやろ
相性良いわけないんだよな

ClaudeやCodexは普通にRust書けるけど
どの辺が相性悪いんかね？

エコシステムがライブラリの乱立と互換性軽視で無茶苦茶だからな
人間だったら上手くやれるというものでもなく、人間比のAIの圧倒的な強みであるインモデル知識を活かした0->1開発の速さが発揮されにくい

>>396
最新モデルはだいぶマシだが、ここらへんはダメダメ
最新やマイナーライブラリのエラー直せない
mod.rs作ったりと色々古い
jsonやtomlなどの設定周りがぐちゃぐちゃ

ルール書けば余裕

メモリの安全性はAIに任せればいいのに
Rustだとややこしくなるだけなんだよな

3月から反AIポリシーを標榜したRedoxが頑張っているな

Rust-Written Redox OS Sees Improvements For Running On Real Hardware - Phoronix
https://www.phoronix.com/news/Redox-OS-April-2026

>>399
それは相性悪くて補助が必要ということ違うん？

コンパイルのエラーメッセージが判る人は、
プロンプト修正も簡単だろうし
そもそも自身でコード書いた方が楽まであるから…

って言うと身も蓋もないか

後発で「AI Native」を謳うMoonBitとかにRustが捲くられるなんてことあるんかねぇ？

コンパイルのエラーメッセージがわからない人いるの？それ、サルだろ。

他のメジャー言語たちと比べて
実行時デバッグを最も少なくできることもRustの長所

>>400
人間にとってやり難いものは AI (LLM) にも難しいという明瞭な傾向がある。
ツールと連携する方向で解決が図られていて、プログラミング言語処理系・リンタも連携するツールの一部だ。

mod.rs なんて手で書いても必ず作るファイルじゃねーか
ディレクトリー名のファイルとか分かりづらくて仕方ないからmod.rsに統一してるわ

これを否定するようなの原理主義としか思えないがそんなレベルの人がこのスレに来てるのかよ

>>404
これ、キモさんの意見に100パーセント同意、、、俺もキモさんの仲間だわ
コンパイルエラーは親切にも程があるぐらい分かりやすい

>>405
これはその通り
でもAIはコンパイルエラーへの対処を間違えやすい
その場しのぎのエラー対処だけやって全体の設計が崩れるからRustではAIは使わないね。特に50万行ぐらいとか規模大きくなると全然コード読まないし
人間なら必ずコード読むから遅くても対処は正確だわ

riscvがrustを推してるからこれからなんかあるかも
armリスクでandroidのriscv化をtier1にするてgoogleもゆってるし

>>407
mod.rsいっぱいある方がきついだろ
エディタのタブこんなんなるわ
│mod.rs│mod.rs│mod.rs│

ファイルは少なければ少ないほど良い

mod.rsはやめろ、ディレクトリ名のファイルに書けぐらいはAGENTS.mdに書いとけば守らないか？
実際これは今もどっちも正しいって扱いだから、人間相手でも指示いるし

>>413
clippyでエラーにできる
rust-lang.github.io/rust-clippy/master/index.html#mod_module_files

https://www.reddit.com/r/rust/s/atsLtH1Yf6

レディットではどっちも
好みが分かれてたわ
俺はmod.rsちゃんに慣れすぎて、とりあえずディレクトリ開いたらmod.ra探してた


`name.rs` vs `name/mod.rs` - Is there a reason why projects go against the recommended practice?

There's two ways to declare a nested module in rust:

A
├── name/
└── name.rs

B
└── name/
└── mod.rs

The [Rust Docs](https://doc.rust-lang.org/reference/items/modules.html#module-source-filenames) recommend the first option:

>Prior to rustc 1.30, using [mod.rs](http://mod.rs) files was the way to load a module with nested children. It is encouraged to use the new naming convention as it is more consistent, and avoids having many files named [mod.rs](http://mod.rs) within a project

What I'm wondering is why most Rust projects are still using the [`mod.rs`](http://mod.rs) pattern. I understand some long-standing projects not seeing a compelling reason to change, but even some newer projects still go for [`mod.rs`](http://mod.rs)

I've checked most popular rust projects I know: **ripgrep, burn, candle, ruff, uv, zellij, alacritty, typst, bottom, bevy, spotify-player, yazi.**

Every single one uses `mod.rs`.

Does anybody know if there's a good reason for this?

>>415
自分も前はname/mod.rs派だった
何故ならJavaとかC#みたいにファイル分けまくってたわけよ
名前空間だけ意識した分割方針にしてからname.rs派になった

ファイル数はどっちも変わらない

name.rs
name/sub1.rs
name/sub2.rs

name/mod.rs
name/sub1.rs
name/sub2.rs

VSCodeは初期設定だとフォルダをファイルの上にまとめて並べるから

name/
sub1.rs
sub2.rs
other/
:
name.rs

みたいに離れてちょっと不便
mod.rsもアルファベット順だと中に紛れるから微妙だけど