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/

RustのGUIツールキットはクロスプラットフォーム狙い過ぎだろ
APIが最大公約数になってみんなが損する

Xで動けばGUI十分なのにな

gtk4-rs

​C言語に頼らず、コンパイルエラーとRustの型システムだけでGUIの要塞を築き上げたいのであれば、王道の Iced か、手軽さの egui のどちらかを選ぶのが現在の最適解です。

C/C++の遺産に一切依存せず、レンダラーからウィジェットまですべてRustで書き下ろされた「純血のRustネイティブGUI」において、現在主役に君臨している代表格は以下の2つです。

​1. Iced （Elmアーキテクチャの正統派）
​先ほども挙げましたが、純血の代表格といえばやはり Iced です。
​思想: 関数型言語（Elm）にインスパイアされた、堅牢なデータフロー（Model-View-Update）を採用しています。
​特徴: 描画には GPU（wgpu）を直接叩くモダンな仕組みを採用しており、Linuxの次世代デスクトップ環境（COSMICなど）の基盤としても採用されるほど信頼性が高まっています。
​向いている人: 「状態管理を美しく、安全に、破綻しない設計でガッツリ作り込みたい」という人向け。

​2. egui （即時モードの爆速ツール系）
​もう一つのピュアRustの大御所が egui（および、それを動かすフレームワークの eframe）です。
​思想: 毎フレームすべてのUIをコードで再構築する「即時モード（Immediate Mode）」という独特なアプローチを取ります。

​特徴: コードの記述量が圧倒的に少なく、デバッグツール、ゲームの内部エディタ、ちょっとした個人用ユーティリティなどを爆速で開発するのに向いています。
​向いている人: 「細かい状態管理のボイラープレートを書き otraくなく、サクサク画面を作りたい」という人向け。

つかIcedってCOSMICなんだ
知らんかった

https://i.imgur.com/dXYKBlm.jpeg

githubにあるLapという画像ビューワ
やっぱWebブラウザではきついか

winio見たけどバックエンド切り替え型か
このタイプは用意されてるコントロールが公約数になってショボいからな

理由は単に「画像表示が重い」からじゃなくて、Lapの本体がむしろ ローカルファイルシステムとの密結合だから。

ここで本質なのは「画像ビューアが重い」じゃなくて、Lapが実質ローカル資産管理アプリだからWeb化コストが跳ねるって話だね。

挙げてる機能を見ると、ブラウザ側に寄せた瞬間に境界問題が一気に出る。既存フォルダをそのまま参照したいのにFile System Access APIは制約が強いし、10万枚規模だと単純なファイル列挙やサムネ生成だけでも永続インデックス・差分監視・キャッシュ戦略が必要になる。さらにSQLite、RAWデコード、HEIC/AVIF/JXL、FFmpegまで来ると、もう「Web画像アプリ」というよりデスクトップネイティブのメディアDBに近い。

クソみたいなバグ
https://github.com/pop-os/libcosmic/issues/1273

定期便

>>485,487 ブラウザエンジンで画像表示が重いわけないだろw

vscodeでプレビュー出切るのがあったな確か

ああ、起動が遅いとか操作に対するレスポンスのレイテンシが大きいという話か
画像に限った話じゅないだろ

激重クソCOSMIC

>>484
ありがとう
その4つで検討してみる

>>482-484
iced製アプリ探してとあるコマンドラインラッパーGUIを試したら
単純なUIなのに起動が1秒以上かかってメモリ使用量100MB超えてた

>>495
感覚がおかしい
既に全てのデータ貼られているようにメモリ100MB未満なんてこの世に存在しない

GPU使うアプリって起動遅い時あるよね？

ネイティブUIは初回起動遅いとかなんとか聞いたことがあるな

>>495
winio-example全機能有効
winuiバックエンド 700MB
win32バックエンド 650MB

>>494
どれが良かった?

キャッシュがない状態の起動からレンダリング完了までの全体の時間でいうと
eguiでwgpu使わずにglowでopenGL使うのが最も早いね
メモリの軽さならegui glowかslint
AIに聞くとなぜかeguiと回答するけども、UI書く簡単さならTauri

eguiってGPUへの負担が大きいとか聞いたけど
あまりにも雑魚雑魚PCには良くないとか

>>501
eguiは軽量なGDI描画はなくて、更にGPUで全部@60fps描画している
それ相応のグラフィックを用いるアプリ用

vulkanのほうが軽くてよかばい

eguiはマウスポインタ動かすだけでCPU使用率が跳ね上がる

ゴミじゃん

​###eguiの対策・確認すべきポイント
​Releaseモードでビルドする
cargo run --release のように、必ず最適化を有効にしたリリースモードで実行してください。これだけで無駄な負荷の大部分が消えます。

​無駄な再描画要求を避ける
コード内で毎フレーム ctx.request_repaint() を叩いていないか確認してください。イベント駆動（リアクティブ）な状態であれば、マウスが静止している間はCPU使用率はほぼ0%になります。

​正しく実装されていれば、必要最低限の描画処理が行われ、普段は極めて軽量に動作します。

rust製guiで一番使ってるのはzedだわ、丁度いい使用感
だからってgpuiで書こうとは思わんが

gpuiのコードみりゅとドットで無限に改行されててこわくなるけぇのう

gpuiは機能追加PRは一切受け付けない
zedに必要十分な機能だけで終了
もうメンテモードになってる

速度を求めるならNeovideみたいな選択になるんだよ
TauriでいいならそもそもRustじゃなくても全然いいんだから

>>510
Neovideもwinitか...
WindowsだとWin+↓↑（Winを離さずに順番に↓と↑キー）で
Windowが前面に戻らない症状がそのまま出ている

Tauriは個人で開発よりも
UIを外注するのに向いてると思う

AIに外注してるわ
4o時代に作り込んだがバグだらけなのでsolで修整させる

Tauriもwinitだから>>511の問題あるよ
コードで対策してるアプリは画面は全部に戻ってもフォーカスがなかったり
Win+↓だけの時に移るべきフォーカスが移ってなかったりで、かえって予測不能になる

ratatuiかrust-bridge-flutterメインで普段からいじってる人おらんのかな
感想知りたい

虫のいい組み合わせ要求ですがこの後ちゃんと感想が出てきます

エレクチオンみたいにこれってゆうデファスタがないのがにゃあ。。。

未だにMS- Windows使ってる人もいるのね

>>517
他のザコ言語と一緒にするな
それだけRsutは柔軟性があるってことだぞ

くたばれ激重Electron！

>>519
これぞ雑魚プログラマーの発想ｗｗｗ

Rustは勝ち確
高みの見物ですかなぁ？

RustというかAIが勝った
近いうちにAIがAI専用の言語を発明してRustコードが置き換えられるかもしれないが、そうなってももう人間は気付かないだろうな

どちらもインフラへ昇格ですかなぁ？

Java
PHPとそれで書かれたWordpress
に続く宗教臭

そんな古臭い言語なんて知らんわ

米国防総省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

AI「Claude」を使って開発ツールの「Bun」の53万行のZigコード全てをRustへ書き換え
https://gigazine.net/news/20260712-bun-zig-rust/

>>520
>>465,468

>>522
>>465,468

FirefoxとChromeにRustで書かれたJPEG XLデコーダーが正式に入った

Servoのリリースビルドでバイナリサイズが100MB超えてるんだが
今のショボ機能でそんなに大きいとjsやメディア関連が入ったら実行ファイルだけで1GBいきそう

型パラメータ展開しすぎて肥大化したか

>>528
Webアプリはウンコ

>>530
バイナリサイズ小さくするビルドオプションとか試したか？

ウェブブラウザのバイナリサイズが数百メガバイトくらいなのは普通のことだろ。

>>530
JSはとっくに入ってる

servo
exe ~ 100MB
dll ~ 170MB

chrome,msedge
exe ~ 4MB
dll ~ 300MB
軽量exeを素早く立ち上げて必要に応じて重量dllは共有でロードする設計

>>536
exeのコードも共有すればいいよね
メモリ上に同じコードがいくつもあっても無駄だから

>>537
exeでも共有される。OSの仕組みを学ぶとよい。
一方dll化が効くのは、ChromeみたいにServoをベースにしたアプリが複数種類起動するケースだ。
心配せずとも、そんな状況にはなる日は未来永劫こない。

氏ねWebアプリ！

死なないぴょーん

rustはまだいいかな。rustが枯れて仕様が落ち着いてから勉強する。
数値計算分野を趣味でぽつぽつやってるし。職業プログラマでもない。

Fortran や C ですらどんどん変わっていて、枯れたとは言えない。
趣味なら選択は自由ではあるけど枯れるのを待ってたら半世紀後でもそのときは来ないぞ。

>>522
Rustを改良したMoonBitの勝利だろうね

GCのあるゴミ言語なんて話にならん

用途によっては GC のほうが高性能にメモリ管理できるということはありえるが、 GC を作るような用途にも使えないと C を捨てられない。

GCに親でも殺されたのか？　GCと和解せよ

動画処理とか頻繁に大容量メモリー使っては解放するアプリとかはGCなんかアテにならないからな

GCつきはAI時代の超高速化についてこれんよ😅

RustはすでにAI時代についていけず落ちこぼれてる
RustでGPU Kernel書くやつが皆無といっていいのがその証拠

###しかし、実際の開発現場やオープンソースの動向を見ると、RustはむしろAI・GPU領域で急速に存在感を増しています。

​注目すべきRustのGPU・AIエコシステム

​CubeCL: RustだけでマルチプラットフォームのGPUカーネルを記述・コンパイルできる最先端のフレームワーク。

​Burn: バックエンドにGPUを指定して柔軟にディープラーニングモデルを構築・訓練できる、純粋なRust製のDLフレームワーク。

​Candle: Hugging Faceが開発した軽量なMLフレームワーク。Pythonに依存せず、純粋なRustでLLMの高速な推論を実現。

​wgpu: WebGPUのRust実装であり、安全かつクロスプラットフォームにGPUコンピュート（計算）を実行可能。

​Note: AIの表舞台（モデルの定義やスクリプト）は依然としてPythonが主流ですが、その裏側を支える高速なエンジンやランタイムにおいて、Rustの採用は着実に広がっています。

くたばれPython！

>>547
動画処理は予めクソデカバッファを取って繰り返し使い回すのが主で、
Rustがフォーカスしているような細かいメモリの割り当てと解放はなるべく避けるんだよ

とりあえず↓の頂点データを1000個並べた配列をどう表現するかでそのGC言語を評価しよう

struct Vertex {
x: f32,
y: f32,
z: f32,
nx: f32,
ny: f32,
nz: f32,
color: u32,
flags: u32,
}

>>554
面白いことを教えてやろう
究極のパフォーマンスを追求するガチ数値計算だと、キャッシュヒット率を高めるために x, y, z それぞれを配列で持つ列指向のデータ構造を採用することが多いんだ
Rustご自慢のゼロコスト抽象化でうまく扱えるかな?

struct {
x: f32,
y: f32,
z: f32,
} [N]

struct {
x: f32[N],
y: f32[N],
z: f32[N],
}

3DレンダリングもRustは全く食い込めてない領域
最終的にはFFIのオーバーヘッドを解消できないから多少性能が落ちても許される分野じゃないとだめなんだよな

​###完全な置き換えには時間がかかっているものの、周辺領域や特定のレイヤーではRustの採用が進んでいます。

​WebGPU / wgpuエコシステム: Mozillaが開発を主導した wgpu（WebGPUのRust実装）は、Bevyなどの新しいゲームエンジンやレンダラーで広く使われており、安全かつクロスプラットフォームなグラフィックスAPIとして注目されています。

​アセット処理やツールチェーン: 描画のコアエンジンそのものではなく、3Dモデルのコンバートツール、テクスチャ処理、シーン管理といった周辺ツール（ツールチェイン）の領域では、メモリ安全性の高さや並行処理の書きやすさからRustへの置き換えが進んでいます。

​オープンソースの挑戦: BevyやRusterizerなど、純粋なRust製ゲームエンジンやレンダラーをゼロから構築する動きも活発です。

>>555
頂点のxyzまで分かれてたらシェーダが泣いちゃう
xyzが一か所に並んでた方がキャッシュヒット率上がりそうだけど
究極のパフォーマンスを追求するガチ数値計算は奥が深いんやな

>>542
イワシの群れみたいに振り回されるのが嫌やねん。C++で懲りた。
AIに訊いてかなりの事が理解できるし、RustもAIでかなりの所
まで勉強できるだろう。仕様や状況が落ち着くまではやりたくない。
お前みたいな人柱に頑張ってもらわねば。

仕様や状況が落ち着くまではやりたくない。
↓
でも、仕様が落ち着いて問題点、実情が明らかに
なるまではやりたくない。

>>560
Rustは仕様が落ち着いてあらゆるところで使われまくってるよ
ネット基盤やウェブ基盤の従来C/C++で書かれていた分野も既に新たなものからRustに変わっているよ

Rustは勝ち確
あとは消化試合ですかなぁ？

>>560
Rustの言語自体は他のメジャー言語と同程度にもう落ち着いてる
ライブラリが全く落ち着いてないが落ち着く頃にはRustを勉強する必要なんてもうなくなってるだろう

>>564
それは単に本来なら標準ライブラリとして提供すべきものを
外に出したからでしょ

​###「Rustを勉強する必要がなくなる」とするならば、それは以下の2つのどちらかのパターンが考えられます。

​Rustよりも優れた別の言語が主流になった場合： メモリ安全性を担保しつつ、C/C++並みのパフォーマンスを出せる、かつ学習コストが劇的に低い新しい言語が登場した場合。ただし、現在のところ、システムプログラミングの領域でRustのポジションを脅かすほどの決定的な対抗馬はまだ現れていません。

​AIがコードを完全に書いてくれるようになった場合： 人間が言語やライブラリの仕様を覚える必要が一切なくなり、AIに指示するだけでシステムが構築できるようになる未来です。これはRustに限らず、すべてのプログラミング言語に当てはまる話になります。

>>560
その C++ は待ってれば枯れたのか？
変化しないのは使われないものだ。

オーナーの概念がいまだにネックです

オーナーとなる主体、実在性、レイヤー

C++23、C++26で枯れてきているんじゃね？
お前みたいな待てない人が頑張ったおかげでな。俺は待つわ。
言語自体が目的になってもしゃあねえわ。

どうせ覇権とるのは確定してるから
The Bookさえ理解できればなんとでもなるわ

C++23とかC++プログラマーの1%も使ってないだろ
使いそうな人たちはRustへ移行したため

>>561
問題点も実情もすでに明らかになってる
ただそれを認めたくない人が多くいるので
うまく聞かないとAIは汚染された回答を返す

rustはasyncが書きづらいので、いずれはその辺の文法が変わると思う
中の人もそれを匂わすようなこと言ってるし

>>574
asyncみたいな魔法の呪文はいらないよぉ

jpeg xlの話面白いな

>>543
MoonBitは関係者が臭いからイヤ

>>577
中国政府支援で作ってる国策言語だから将来性は抜群だよ

JPGでもPNGでもない　2026年内に主要ブラウザが「JXL (JPEG XL)」を正式採用へ
https://atmarkit.itmedia.co.jp/ait/spv/2608/27/news047.html

2026年8月24日「Firefox」において、次世代画像フォーマット「JPEG XL」（JXL）を正式採用する方針を明らかにした。
「Google Chrome」の開発チームも同様の意向を示している他、
「Safari」には先行して一部機能が実装されている。
業界の主要プレイヤーが足並みをそろえ、2026年内にも主要ブラウザでJPEG XLが広くサポートされる。

2021年当時提供されていたデコーダーはマルチスレッドで動作する約10万行のC++コードで構成されており、複雑かつ広大なコードベースによりブラウザの攻撃対象領域を著しく広げるため、脆弱性のリスクを高める懸念があった。

Google ResearchのJPEG XL開発チームが、メモリ安全性に優れたプログラミング言語「Rust」を用い、安全かつ高性能なデコーダー「jxl-rs」を開発した。