Rust part34

**デフォルトの名無しさん** · 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が使われるとしたらシステムよりもアプリケーションだろうね