Rust part34

**デフォルトの名無しさん** · 2025/12/16(火) 22:02:24.31

Rustに勝つのは無理すぎる

**デフォルトの名無しさん** · 2025/12/17(水) 00:04:52.78

せっかくノリノリで自演再開したのに蒸し返された途端に止まるの笑える

**デフォルトの名無しさん** · 2025/12/17(水) 00:05:33.31

どういう指標において？
例えば「開発者の人口の多さ」なら主要言語の中では下位だし、そんなもの切り口によりけりだろ

**デフォルトの名無しさん** · 2025/12/17(水) 00:37:34.86

tronはスウィッチ2のコントローラで活躍しとるでぇ🧐

**デフォルトの名無しさん** · 2025/12/17(水) 09:00:54.55

活躍ではないかな

**デフォルトの名無しさん** · 2025/12/17(水) 13:00:34.90

NeXTは死にかけのところをあやうく拾って貰えた
BeOSの方がmac後継の有力候補とまで言われていたのに
ここまで立場がひっくり返るとは

**デフォルトの名無しさん** · 2025/12/17(水) 13:20:26.44

マイナーアーキテクチャ対応はgccrsプロジェクトの成否にかかってると思うんだが
現状どうなってるの？

**デフォルトの名無しさん** · 2025/12/17(水) 14:23:26.87

そんなもんお荷物になるだけだから失敗してくれた方がいい
最新エディションへの対応が遅れる(or放棄される)のは目に見えていて、
ライブラリがそれに引きずられて最新エディションへの移行を渋るようになれば、
俺達イケイケ最先端ウェーイでやってきたRustコミュニティの自尊心に致命的なダメージを与え、開発者離れを引き起こすことになりかねない

**デフォルトの名無しさん** · 2025/12/17(水) 16:13:18.06

アーキテクチャのLLVM対応はベンダーorメーカーの責任では
売りたいなら真っ先に用意するだろうし時代遅れでコストに見合わなければ切り捨てられる

**デフォルトの名無しさん** · 2025/12/17(水) 19:33:27.44

というかgcc対応の本命はrustc_codegen_gccの方じゃない？
最近はRust本体のCIでもテストされるようになってきたし、rustupでの配布も計画されている

**デフォルトの名無しさん** · 2025/12/17(水) 20:42:52.22

>>216
rustc_codegen_gccはrustcのバックエンドとしてLLVMと同様の立ち位置なんだよね
だから>>214の問題は起きないメリットが大きい

**デフォルトの名無しさん** · 2025/12/17(水) 22:06:20.53

bincode がサポート終了になったみたい
それなりに広く使われてるクレートでも突如消えることってあるんだな、と改めて思う…

**デフォルトの名無しさん** · 2025/12/17(水) 22:27:57.16

メンテナの一人が他のメンテナに相談なく脱GitHub作業を始めて履歴の書き換えとかをやりだして揉めたけど
その渦中のメンテナがトランスジェンダーのポリコレだってことで
実名と住所を晒されて、責任取ってプロジェクト自体終わりってことになったのか

**デフォルトの名無しさん** · 2025/12/17(水) 22:29:06.78

devでtestで用いてるクレートが多いな

**デフォルトの名無しさん** · 2025/12/17(水) 22:31:21.65

>>217
rustc_codegen_gccがお荷物になってライブラリではなくてRust本体への変更が遅れるデメリットはある

**デフォルトの名無しさん** · 2025/12/17(水) 22:55:48.90

そこはこれまでもrustcとLLVMとの間の調整でやって来たことだから新たな影響は限りなく小さい
一方でRustの仕様追加変更や標準ライブラリの追加安定化などは当面rustcまわりでの独裁決定事項であることが成長中のRustにとって好ましい

**デフォルトの名無しさん** · 2025/12/17(水) 23:05:52.77

bincodeの件、斜め読みしたけど、こんな感じじゃない？

1. 生成AIのクソissueにブチ切れる
2. 脱GitHubを実行
3. ついでに、トランスジェンダーの関係で改名した新しい名前を使って過去のコミットを書き換える
4. しばらく誰も気づかない
5. 誰かがコミットIDが書き変わってることに気づく
6. うわーサプライチェーン攻撃だーと大騒ぎする
7. 騒ぎの中で、作者の実名や住所を公開する奴が現れる
8. 作者がブチ切れて、メンテナンス終了を宣言
9. ついでに、作者名の欄を独立して編集できないcrates.ioがクソ、と意見

**デフォルトの名無しさん** · 2025/12/18(木) 00:40:08.71

>>221
RFCが承認されてから10年経っても実現できない機能がいくつもある言語だからな
その程度のデメリットはいまさらだろ

**デフォルトの名無しさん** · 2025/12/18(木) 12:26:48.37

ハッシュマップってハッシュ値を保持して値を調べるんじゃなくてキーも保存するんだな
保存したくない場合はキーを完全ハッシュ値にしてハッシュ値をキーにしないとだめだな

**デフォルトの名無しさん** · 2025/12/18(木) 13:24:31.83

キーを保存したくないならHashSetの方があってそう
値にEqが必要だけど完全ハッシュより現実的

**デフォルトの名無しさん** · 2025/12/18(木) 14:39:08.80

恐ろしい誤解だなと眺めてたら
さらに恐ろしいのが来た

**デフォルトの名無しさん** · 2025/12/18(木) 15:01:44.44

>>225
HashMapはハッシュ値を保持しない

>>226
HashSetもキーを保持する

**デフォルトの名無しさん** · 2025/12/18(木) 15:07:04.67

この場合のキーはHashMap<K, V>のKのことだろ
HashSet<T>のキーってなんだよ
ハッシュ値のこと？

**デフォルトの名無しさん** · 2025/12/18(木) 16:23:43.15

検索に使うオブジェクトがキー。
HashSet は値が常に () であるような HashMap だと説明されてる。

**デフォルトの名無しさん** · 2025/12/18(木) 16:51:07.77

普通のハッシュマップは何もしないハッシャーを実装すれば出来るな

**デフォルトの名無しさん** · 2025/12/18(木) 19:13:42.74

Rustの前に基本情報あたりを取る勉強したほうがいいんじゃないか
古臭いのが多いとはいえ応用は基礎の積み重ねの上にあるからな

**デフォルトの名無しさん** · 2025/12/18(木) 19:42:58.02

rustってグローバル変数が使えないんだよね。dfsつらくない？

**デフォルトの名無しさん** · 2025/12/18(木) 19:46:33.16

DFSのためにグローバル変数？？
プログラミングを基礎からやり直したほうがいいぞ

**デフォルトの名無しさん** · 2025/12/19(金) 10:28:35.58

Rustちょっとビルドの度に数分単位の時間掛かるのなんとかならんのかね
多分プロダクションビルドだけでやればいいような最適化とか毎回回してるよねこれ

**デフォルトの名無しさん** · 2025/12/19(金) 10:31:57.30

>>235
マクロのせいでしょ

**デフォルトの名無しさん** · 2025/12/19(金) 12:08:39.25

でかい依存ライブラリのリビルドが必要になったならまだしも自分のコードのインクリメンタルビルドだけで数分もかかるようならマシンのアップグレードを検討したほうがいいかもしれない

**デフォルトの名無しさん** · 2025/12/19(金) 12:10:44.45

Windowsならアンチウイルスのせいかもね

**デフォルトの名無しさん** · 2025/12/19(金) 12:20:12.19

>>235
少なくともデバッグビルドのデフォルト設定では最適化は控えめだよ。
単純にリンクが遅い傾向にある。
Rust プロジェクトの典型的な設計がリンカには負担がかかってしまう要素が多いらしい。
変更が少しだけでもリンカの仕事の量は特に変わらないし。

インクリメンタルリンクをサポートしたリンカ Wild が開発中で、開発中のリンク (修正を少しだけした場合のリンクしなおし) を爆速にする計画は進んでいる。
インクリメンタルリンクは構造がかなり複雑になるので複雑な処理と速度を両立できるのか疑問視されていて従来のリンカ開発者は消極的だったんだが
Rust でなら複雑さと性能を両立したリンカを書けるという自信があるらしい。

**デフォルトの名無しさん** · 2025/12/19(金) 12:24:59.93

C#みたいにプロセス起動したままホットリロードできるようになるのはいつ？

**デフォルトの名無しさん** · 2025/12/19(金) 13:38:24.83

ビルドする時間帯によっては依存cratesの更新確認だけで待たされる時があるな

**デフォルトの名無しさん** · 2025/12/19(金) 14:18:19.55

>>241
その仕組みのない言語はやばい

**デフォルトの名無しさん** · 2025/12/19(金) 14:24:27.94

Rust はシングルバイナリ指向なのでホットリロードは想定してないがバイナリを分割すれば (ホスト環境によっては) 今でもホットリロードできる。
実行環境次第。

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

ホットリロードが欲しいのはGUIみたいに「ちょっと変えて試す」をしたい分野だと思う
それはRustの得意分野でもないし、そこはC#やJSで良いじゃない
Rustが向く分野とそうでない分野があるというだけの話

**デフォルトの名無しさん** · 2025/12/20(土) 06:57:23.96

ホットリロードはWEB APIにこそ欲しい

**デフォルトの名無しさん** · 2025/12/20(土) 09:53:03.44

>>241
何時間も待たされて(ちょっとずつは進んでる)眠くなったのであきらめて
次の日やり直したら一瞬で終わったことがある

**デフォルトの名無しさん** · 2025/12/20(土) 09:54:12.80

>>243
その仕組みのないOSはやばい

**デフォルトの名無しさん** · 2025/12/20(土) 10:06:31.65

明示的にアップデート指定した時以外はイチイチ外部パッケージのダウンロード＆再コンパイルとかやらないで欲しいな

**デフォルトの名無しさん** · 2025/12/20(土) 13:27:35.26

>>248
クレイト使用バージョンを指定してないからでは

**デフォルトの名無しさん** · 2025/12/21(日) 13:34:39.31

hoge = "1.2.3"
よりも
hoge = ">=1.2.3"
よりも
hoge = "=1.2.3"
推奨ですね判ります

**デフォルトの名無しさん** · 2025/12/21(日) 14:35:21.91

Microsoft、2030年までにC/C++廃止を目指す
https://softantenna.com/blog/microsoft-c-to-rust-2030/

> 私の目標は、2030年までに Microsoft からすべての C と C++ のコードを排除することです。そのための戦略は、AI とアルゴリズムを組み合わせて、Microsoft が抱える最大規模のコードベースを書き換えることにあります。

> マイクロソフトの大規模C/C++システムをRustへ移行する

**デフォルトの名無しさん** · 2025/12/21(日) 14:43:34.11

マイクロソフトに限らず2030年代にはどの企業でもC/C++全廃してるでしょ

**デフォルトの名無しさん** · 2025/12/21(日) 14:48:05.86

>>251
>「Galen 氏の発言を Microsoft 全体の方針と見るな」という冷静な指摘も行われています。

はいおつかれ。解散解散

**デフォルトの名無しさん** · 2025/12/21(日) 15:03:43.26

お前らもExcelのマクロをRustで書きたいだろ？

**デフォルトの名無しさん** · 2025/12/21(日) 15:07:17.98

1ヶ月で1人あたり100万行のC/C++コードのRust化って
コーディングもレビューもテストすらAI丸投げで
誰も確認しない感じじゃないと不可能だよなあ

**デフォルトの名無しさん** · 2025/12/21(日) 15:15:34.65

実際にはWindowsをRustで書き換えるんじゃなくてWindows付属のアプリケーションをRustに置き換えていくんじゃないかな
人を集めるために大きいことを言ってるんだと思うよ

**デフォルトの名無しさん** · 2025/12/21(日) 19:17:27.17

そりゃ Rust のほうが良いとは思うが書き換えとなると書き換えに伴って発生するバグだってあるし、十分に安定している部分まで慌てて書き換える合理性がない

**デフォルトの名無しさん** · 2025/12/21(日) 19:46:26.13

そう言ってるわりにVisualStudio2026でRust対応しなかったよな
結構くるんじゃないかって期待してたんだけど

**デフォルトの名無しさん** · 2025/12/21(日) 20:27:44.41

Rustに書き換えたところで何かが改善されたというアピールがしにくいんだよね
速くなろうがエラーがへろうがそれが置き換えによるものなのかって切り分けにくいだろうし

**デフォルトの名無しさん** · 2025/12/21(日) 20:28:25.69

何かRustコンパイラをMSが自作する必要に迫らればVisual Studio入りもあるだろうけど
結局rustcとrust-analyzer頼みならVsCodeでいいじゃんで終わりそう

**デフォルトの名無しさん** · 2025/12/21(日) 21:38:22.40

処理系が少ないのは健全な状態ではないからマイクロソフトにも手をつけてほしいが、現時点では Rust の言語仕様の文書化があまり進んでないからな……。
https://github.com/rust-lang/spec
リファレンスマニュアルだけで十分に互換性のある処理系を作れるとは思えないし、やるにしても時期尚早かもしれない。

**デフォルトの名無しさん** · 2025/12/21(日) 23:07:13.70

vsてcodeの劣化版でしかないのにあれをまだ使ってる人おるんかな

**デフォルトの名無しさん** · 2025/12/22(月) 00:13:44.16

>>262
VSをエディタとしてしか使ったことないんか？

**デフォルトの名無しさん** · 2025/12/22(月) 00:37:10.74

バルマー時代のMSならいざ知らず、今のMSが今更わざわざWindows専用の新しいツールチェインなんか作るわけないでしょ

**デフォルトの名無しさん** · 2025/12/22(月) 08:42:53.10

Arm版Windowsなら可能性あるかもね。

x86windowsは過去互換性が重要だから互換層をたくさん用意する必要がある。互換層はunsafeまみれでpanicリスクのあるコードになるから、Rustの強みは活かせないだろうね。

**デフォルトの名無しさん** · 2025/12/22(月) 19:42:03.81

Arm版もどっこいかな
結局Rustが使われるとしたらシステムよりもアプリケーションだろうね