Rust part38

公式
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/
（コミュニティによる日本語翻訳版もあります: https://doc.rust-jp.rs/book-ja/）

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

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

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

前スレ
Rust part37
https://mevius.5ch.io/test/read.cgi/tech/1784283151/

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

Win10と11は紛れもないゴミ😲

MicrosoftにはKokaに本腰入れて欲しいなぁ
無理かなぁ

プログラマでwin使ってる人少なくね
unix系ばっかり

>>375
ボットかAIエージェントじゃねーの
除外してるらしいけど100％とはいかんやろ
WEBのアクセス集計だからわざわざLinuxマシン買ってきてネットサーフィン楽しんでる層がいるってことになっちゃうよ

>>379
Kokaは略記バリエーションありすぎてAIと相性悪い

​###背景: Windows 10のサポート終了（2025年10月）に伴い、まだ物理的には十分使えるにもかかわらず、Windows 11の厳格なCPU要件やTPM 2.0のせいで「非対応」とされた膨大な数のPCが存在します。またWindows 11で導入された強力なAI機能（Copilotや画面キャプチャを記録する「Recall」機能など）や、OS全体に組み込まれた広告・肥大化（ブルートウェア）に強い不満を持つユーザーが増えています。

AIの回答を調べもせずにコピペして答えた気になってるジジイ

ど、どうしたんだ？いきなり発狂し始めて

just deploy

justは殆どのディストリビューションに入ったし、もう普及したね

Android を Linux にカウントするべきかどうかでも差は大きいんじゃないの。

>>374
物議を醸した投稿はあったよね
https://www.linkedin.com/feed/update/urn:li:activity:7407863239289729024/

C/C++を全廃してRustへ行く方針はホワイトハウスが方針を示してアメリカ全体が進めてることだからその流れは止まらない

もうRustだけですべてを賄える

関数型でも似たようなこと言ってた奴いたし眉唾かな

Javaに時に死ぬほど聞いたんじゃぁ

今まで無数のプログラミング言語が出てきたけど
C/C++と同等の速さで動く実用的な言語はRustオンリー

昔のアメリカでは Ada を使うことを要求していた時期があって軍事システムはなにもかも Ada だったんだぞ。
その時代にはそれもひとつの選択として間違ってはいなかったかもしれないが、民間にはたいして関係ないまま Ada は消えてしまった。
アメリカ政府の主導なんてその程度の影響力しかないよ。

民間（メガテック）が主導してるのに乗っかっただけじゃね？

時代が違うんだよ
これからのAI時代はRustの時代

これまでC/C++使うしかなかった
しかしセキュリティホール山積みで現在も増えてる
だからIT企業はRustへ移行し始めた
アメリカ政府はその後追い

政府が言ってるのはCを使うな
移行先は何でもいい

>>399
バーカ死ね🤪

米国防総省DARPA、C言語のコードからRustへの自動変換実現を目指す「TRACTOR」プログラム開始
https://www.publickey1.jp/blog/24/darpacrusttractor.html

NASAのSpaceWasm
github.com/nasa/spacewasm
宇宙船上でWasmバイナリを解釈・実行することを目的とした、Wasm 1.0仕様のインタープリタ

静的サイトジェネレータ「Astro 7.0」正式リリース、ビルドシステムがVite 8/Rolldownに、Rust製コンパイラ採用で高速化 － Publickey
https://www.publickey1.jp/blog/26/astro_70vite_8rolldownrust.html

😅

>>399
移行先のまともなプログラミング言語がRustしかない

いいかげん、c++標準にはsafe rust みたいなsafe c++ を開発してほしい。

コーダー向けは関数呼び出しのみ・スマートポインタのみくらいで十分。クラスもテンプレートも要らんと思う。

###後方互換性の呪縛: C++の最大の強みであり弱みでもあるのが、「何十年も前の古いコードが最新のコンパイラでそのまま動く」という鉄の掟です。そのため、Rustのように「デフォルトで安全にし、古い書き方を段階的に排除する」というドラスティックな変更が極めて困難です。

>>1
>>400
「Bun」の53万行のZigコード全てをRustへ書き換え
https://gigazine.net/news/20260712-bun-zig-rust/

>>405
Zigがプロトタイピングに向いていて今までのBunに合っていたけど、今後Bunは保守運用メインに軸足を移すから清書用Rustが丁度いい、というだけだろ。

サムナーも「Zigがなければここまで来られなかった」と言ってるしな。

>>406
そんな理由で言っていない

そもそもcプラみたいな肥大化しすぎたゴミはいらない
c系てコンパイラも緩いしゴミ

>>407
>405の記事をちゃんと読めよ。

「Zigそのものが問題だったとは思いません。Zigがなければここまで来られなかったでしょう」

移行を決断した最大の理由は、Rustのメモリ安全性によってBunで頻発していた種類のバグをコンパイル時に防ぐためであり、長期的な保守性や開発効率を重視したためだとしています。

書きやすい言語と安全なrustのトレードオフ
長期的には安全なほうで固まる

>>409
やっぱRustはすげーな

Zig「放蕩息子のBunが出ていって清々したわい」

>>406
Zig 版の Bun は JavaScriptCore を軸に据える前提で性能を出すために細部のメモリ管理を手作業で制御するという設計方針がバグを頻発させる根本原因だ。
この方針を曲げないなら Rust に置き換えてもバグはコンパイル時に防げないし、保守性も開発効率も良くならない。
Rust の考え方に沿った形に書き直すならそれはもうほぼフルスクラッチなので長い期間の開発フェイズが入る。 保守運用フェイズに入ることは出来ない。
Bun の開発者がどういう意図を持っていたのであれ前提がおかしいので書いてあることを信じるな。

zigはRustと比べたら未熟な言語なんだろ

AIで全自動やろ書き換えもそうだし

>>414
作者が仕様にこだわりたいからまだ1.0になっていない

>>409
Zigでバグだらけだったのか

>>408
肥大化って、
Boostとかのこと？

ご指摘の通り、C系言語（特にC++など）が抱える肥大化の本質的な原因は、まさにその3点に集約されます。

* 過剰な後方互換性の維持
* 何十年も前の古いコードや設計ミス、C言語との互換性を切り捨てられず、古い構文と新しいモダンな機能が層のように積み重なり、言語構造が複雑化している。

* 標準ライブラリの分散と未統合
* 実用的な機能が標準で一元的に提供されないため、外部ライブラリの選定やバラバラのパッケージ管理に開発者が余計な労力を奪われる。

* 取捨選択のない機能の追加（全部入り）
* 設計の哲学や一貫性よりも「過去のコードを壊さないこと」や「あらゆる要望への対応」を優先し、機能を厳選せずに足し算し続けた結果、誰も全貌を把握できない巨大な仕様になった。

この3つの要因が相互に絡み合うことで、言語の仕様自体も、それをとりまくエコシステムも極めて重く扱いにくいものになっています。

>>417
Rustのようにsafe領域があってそこでの安全を保証する言語とZigは異なる
Rustならunsafeを使っていてもそれを関数やモジュールの中で閉じ込めてsafeな関数を作ることでunsafeな領域がどこまでなのかを見える形で管理できて残るその検証に集中できる
それ状況すらプログラマーの頭の中だけにあって曖昧だとバグを生みやすくなりやすいだろう

細部を手作業でメモリ管理するという方針をとる Bun は unsafe な小さな部品に閉じ込めるのは不可能。
JavaScriptCore のメモリ管理に合わせて性能を出すために全体が独自の、そして一貫性のないメモリ管理をしているので全体が unsafe にならざるを得ない。
Bun がカス品質なだけなのでそれで Rust や Zig を論じるな。

もう最初からRustで書かれたdenoでいいじゃん

バギーで信頼性高いけど劇的に速い！
安全に書くと何割も性能がダウンする！
なんてことは起きるわけがない

Deno（ディーノ）の強み：堅牢なセキュリティと美しい設計

​DenoはNode.jsの反省点（セキュリティの脆弱さや複雑な設定）をゼロベースで見直し、安全でクリーンな開発環境を目指して作られたランタイムです。

​デフォルトで安全（サンドボックス）: 許可を与えない限り、勝手にファイルを書き換えたり外部と通信したりできないため、セキュリティ面で非常に安心。

​Web標準APIの徹底: ブラウザと同じような書き方（fetchなど）でそのまま動くため、モダンなJavaScriptの書き方がそのまま活きる。

​厳格でクリーンなTypeScriptサポート: 設定ファイルをいじらなくても、TypeScriptが最初から爆速かつエラーなく快適に動く。

Rustは最強だな

もうRust使わない奴は引退しかけのボケたエンジニアぐらいだろ

>>426
Rust以外の言語が未熟すぎた

お前らがやったRustの案件教えて

ドローンの制御システム

産業機械の状態監視・制御

個人プロジェクトだけど、 Node.jsで書かれていたサーバとバッチ処理をrustで書き直し
速度とメモリ効率が劇的に改善したわ

Javaうんち

プログラマーはどの言語からどの言語へ移住しているのか？JetBrainsが8837人分の回答を分析 - GIGAZINE
https://gigazine.net/news/20260820-jetbrains-programming-language-migration/

皆Rust用のGUIライブラリーは何使ってるの

RustでGUIは使わない

​まとめ：どれを選ぶべき？
​「とにかく手軽にサクッとツールを作りたい」 ➡ egui
​「純RustでモダンなUIアプリを設計したい」 ➡ Iced
​「Webの技術を使って、リッチで綺麗なUIにしたい」 ➡ Tauri
​「Linuxなどのネイティブ感を重視したい」 ➡ gtk-rs

決め手は日本語入力の可否だろ

slint

もうRustに出来ないことはない

とにかく手軽にサクッとツールを作りたい guiなし
軽量高速優先 ratatui
手軽に腐らない技術でUIつきツールを作りたい tauri

​「Tauriで十分」 ➡ Tauri
​「日本語入力しない」 ➡ 好きに選べ
​「する」 ➡ 出口

フォント入れたらええやん

​「Tauriで十分」 ➡ 他の言語で十分 ➡ 他言語へ
​「Tauriでは不十分」➡ C/C++へ

これが現実

>>441
フォント入れても何も解決しません

tauriの中身ほぼRPCやから計算量少ないツール向けやね
高速レンダリング必要てなるとwgpuじゃないとキツイ

>>442
他の言語は遅かったり安全に問題があって役に立たん

Ratatuiも選択肢に入れてほしい

Dioxusは微妙？

>>444
ウェブで可能なものはTauriで十分だよ
その場合の選択肢はこの二つ
・処理サーバ＋Webアプリ
・Tauri
前者はより汎用になりWebブラウザがあれば誰でも利用できるメリットがある
後者は処理サーバ部分を内蔵かつWebブラウザも不要なメリットがある
どちらもRustで書ける

高速であればあるほど良いに決まっているから
早い段階でリッチで綺麗なUIを作って、
高速は妥協してTauriが良いな、と言う判断に持ち込むのが重要

>>448
444は高度なビデオ編集等の事だと思う
その場合は綺麗なUIだけじゃ話にならないな

CEFを使えばRPCなしでブラウザエンジンを使えるのかも

>>449
△ 高速であればあるほど良いに決まっているから
○ 高速であればあるほど良いに決まっているから(際限がない)

>>451は結局>>442と言う事だな

>>453
Rustで可能なことを他言語を使えと嘘の誘導するのはだめよ

>>451
Tauri＋cef_rsで使える

多少低速でも機能性に問題の出ないアプリなら「Tauriで十分」「Webviewで十分」になりやすい
ビデオ編集は例外中の例外

>>451
https://zenn.dev/tasuren/scraps/01f47381e351d1
に
https://github.com/tasuren/cef-rs-message-router (IPCを使ってみる)
とあるからプロセス間通信は必要なのでは

>>457
プロセス間通信とは別のプロセスと通信すること
別のプロセスなんてない

tauri重いから嫌や～

TauriはElectronと比較して軽量で省メモリでバイナリサイズも小さいメリットがある
CEFを使うとそれらのメリットを失うがChromiumの機能が使える
Rustで使う場合はTauri + cefクレート

今一番有望なのは winio だよ
compio 作者が作ってるやつ
日本語入力も問題ないはず

Builder::register_asynchronous_uri_scheme_protocol
あたりで頑張ればビデオ編集（ストリーミング）もできそうだけどな

tauri v2でmessage（command）とは別にRequest/Responseのデータ経路も開通してる

tauri が軽量なんて言うのはちょっと感覚がずれてる。
ウェブブラウザは重量級アプリケーションだ。
ウェブウィジットは本来的に高機能・高負荷なのがあたりまえなんだ。
その上でユーザー規模・開発者規模が大きいから最適化に投資されているし、大抵の場合に関連コンポーネントがロード済みだったりするから体感的な応答性は良いってだけ。
electron よりは大幅に軽いけど、各種 GUI フレームワークを軽量さで比較すると tauri が特に軽いってことはない。

>>463
日本語が読めない人はお断り

＞TauriはElectronと比較して軽量で省メモリでバイナリサイズも小さいメリットがある
＞CEFを使うとそれらのメリットを失うがChromiumの機能が使える

うむ
https://static.zenn.studio/user-upload/4b99f051cdc0-20260815.png

WebサイトやWebアプリを作る時と同じ知識のまま非常に楽にGUIを作れることが最大のメリット
それらと比較するとTauriはWebサーバとWebブラウザが不要になるメリットもある

欧米人がGUIツールキット作ると、だいたい日本語入力がゴミになる
それを回避できるのがブラウザベースの最大のメリット

それはそう、

> 軽量で省メモリでバイナリサイズも小さい
＝ 軽量
× 省メモリ
○ バイナリサイズも小さい

https://static.zenn.studio/user-upload/9bd70bda6b3e-20260815.png

例えばPCに向かってる時だけでなくスマホからも見たいことが多い
そんな場合のGUIはWebアプリがオススメ

>>462
それでネットワークスタックをバイパスしても
普通の環境だと高速インターネット回線やSSDの方が帯域的に速い

>>461
> 日本語入力も問題ないはず

ダメだった、変換確定エンターで改行になる

>>471
中国人が作ってるのに？

arrayrefクレートに対するサプライチェーン攻撃が発生した件

定期便や

日本人の現実
​「Tauriで十分」 ➡ Tauriまたは他Webview
​「Tauriでは不十分」➡ OSプラットフォームネイティブ言語へ

ジャップエンジニアの99%はRustを使えない低レベルの量産品だから気にしないでいいよw

>>471
まさか君がフォントを入れてないというオチじゃないだろうな
念のため確認

>>461
winuiバックエンドでIME入力概ね問題なし
ていうかwinui3のコントロールそのものなので一番良い

win32バックエンドは改行問題あり