Rust part30

**デフォルトの名無しさん** · 2025/05/28(水) 09:31:36.60

公式
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 part29
https://mevius.5ch.net/test/read.cgi/tech/1746200850/

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

**デフォルトの名無しさん** · 2025/05/31(土) 16:23:22.78

>>261
消え行くスクリプト言語の話だろ

**デフォルトの名無しさん** · 2025/05/31(土) 16:35:20.26

単純に関数名などで用途がわかって実行できる言語が有利だと思うけどね
rustはそうはいかない

**デフォルトの名無しさん** · 2025/05/31(土) 16:37:33.86

>>263
プログラマがAIで不要になる話だよ

**デフォルトの名無しさん** · 2025/05/31(土) 16:46:59.83

第1段階スクリプト言語はAIのみが生成の時代へ
第2段階 AIはもっと速い言語のコードを生成へ

**デフォルトの名無しさん** · 2025/05/31(土) 17:00:21.29

RustにとってAIによる目先の脅威は、既存物のRustへの書き換えの作業のうちコーディングが自動化されて人間はテストばかりやらされるようになることじゃないかな
書き換えなんてAIが最も得意とするタスクで、Rustでも十分な精度が出る
書き換えは単純作業なので人間にとっては脳内麻薬ドバドバなのに、その気持ちいい部分がAI化されちゃうとRust触って俺スゲーしたいだけの人達がやる事なくなっちゃうよ

**デフォルトの名無しさん** · 2025/05/31(土) 17:26:37.61

>>266
普通の人は書き換えなんてやりたくない
新たな設計や機能の改善など創造的なことが楽しい

**デフォルトの名無しさん** · 2025/05/31(土) 19:05:28.17

>>267
その論でいくと書き換えAIの精度を上げていくのは楽しいんじゃないかな

**デフォルトの名無しさん** · 2025/05/31(土) 19:14:49.45

それはllmが何をしているのかを理解してない発言

**デフォルトの名無しさん** · 2025/05/31(土) 19:23:46.27

遅い言語のコードを生成するのはバカげてる時代になるから速くて省メモリな言語が有利だね

**デフォルトの名無しさん** · 2025/05/31(土) 19:26:17.54

悪いリファレンスカウントとヒープを使っていてもあれはライブラリだから
言語は悪くも良くもならないという中立性に魅力がある

**デフォルトの名無しさん** · 2025/05/31(土) 21:52:40.30

ワナビおじさん

**デフォルトの名無しさん** · 2025/05/31(土) 21:56:37.03

>>236,243
指摘した人も指摘しただけで
マルチスレッド対応したままArcやめるPRは出してないな

**デフォルトの名無しさん** · 2025/06/01(日) 01:44:05.23

Linux 6.15リリース：486クラスCPUサポート終了でRust統合加速
https://innovatopia.jp/uncategorized/55816/

**デフォルトの名無しさん** · 2025/06/01(日) 08:13:47.82

コマンドを作った奴は本当は喉から手が出るほどGUIがほしいんでしょ
ほしがれー

**デフォルトの名無しさん** · 2025/06/01(日) 08:47:16.18

BionicGPTもそのGUIのDioxusもRust製
https://github.com/bionic-gpt/bionic-gpt

**デフォルトの名無しさん** · 2025/06/01(日) 08:52:33.88

実用レベルのGUIアプリはどれもWebブラウザを使ってる奴か

**デフォルトの名無しさん** · 2025/06/01(日) 09:00:06.64

>>277
DioxusはTauriやElectronのようなWebブラウザJavaScript依存とは違って純Rust

**デフォルトの名無しさん** · 2025/06/01(日) 09:01:28.49

文字合成とかまで含めてきちんと UNICODE の全部をサポートしようとするとおおごとだからなぁ……
OS (または実質的に OS の一部のようなミドルウェア) が提供する機能のラッパーという形にしてもらったほうが安心できる。

**デフォルトの名無しさん** · 2025/06/01(日) 09:03:49.22

>>277
DioxusはTauriやElectronのようなWebブラウザではない
JavaScript依存もなくピュアRust

**デフォルトの名無しさん** · 2025/06/01(日) 09:19:26.30

>>280
現実は非情
https://dioxuslabs.com/learn/0.6/guides/desktop/#
> Apps built with Dioxus desktop use the system WebView to render the page.

Rustのコード自体はwasmじゃなくてネイティブで動くらしいから、頑張って慣れない英語読もうとしてそのあたりの説明を勘違いしちゃったんだろうね
健気で哀れな複おじ

**デフォルトの名無しさん** · 2025/06/01(日) 09:33:24.37

>>281
違いが理解できない？
ElectronとTauriはブラウザそのものでJavaScript依存
Dioxusは純Rust

**デフォルトの名無しさん** · 2025/06/01(日) 10:02:51.51

XAMLみたいなのはスクリプトじゃなくてデータだから純度が下がらないというのはまあわかる
じゃあCSSは

**デフォルトの名無しさん** · 2025/06/01(日) 10:03:09.02

>>282
ElectronのJSランタイムは基本Node.jsで、オプションとしてブラウザ側も使用できる
Tauriも同様に、Rustコードの実行はネイティブ
上記のリンクにも記述のある通り、Dioxusはブラウザ側のDOMやjs/wasmにアクセスする手段がなく、その点で機能性が劣っていると言えるが、本質的には現時点ではElectronやTauriと大きな違いはない

**デフォルトの名無しさん** · 2025/06/01(日) 10:14:51.82

>>284
さっきのURLに document::eval() でDioxusはブラウザ側jsにアクセスできるって書いてあるじゃん

**デフォルトの名無しさん** · 2025/06/01(日) 10:16:54.42

>>284
全く異なる
Dioxusはマルチプラットフォーム
desktop platformの時のみwebviewを使う

**デフォルトの名無しさん** · 2025/06/01(日) 10:20:48.90

単純にWebに載せるやつのほうが機能が充実してるしフレームワークのメンテナも利用者も多い
あと流行りのデザインやアニメーションを容易に組めるのが一番でかい
こういうとRustじゃない～て暴れられるけどGUIとロジックで役割分担してるだけなんよ

**デフォルトの名無しさん** · 2025/06/01(日) 10:38:08.36

>>286
stableな実装は現状どのプラットフォームでもWebブラウザベースのみだよ
DOMとCSSが独自仕様なFlutterと違ってDioxusは仕様上HTML/CSSに依存してるんで、脱WebViewしようとすれば結局自前でブラウザを実装する必要があり、
互換性は全く期待できないしパフォーマンスでWebViewに勝つのも相当厳しいだろうな

**デフォルトの名無しさん** · 2025/06/01(日) 10:42:10.51

>>288
いいえ
Dioxusがwebviewを使うのはdektopのみ

**デフォルトの名無しさん** · 2025/06/01(日) 10:46:19.31

>>289
https://dioxuslabs.com/learn/0.6/guides/mobile/
> Mobile is a first-class target for Dioxus apps, with a robust WebView implementation that supports CSS animations and transparency effects.
> Mobile apps are rendered with either the platform's WebView or experimentally with WGPU.

**デフォルトの名無しさん** · 2025/06/01(日) 10:50:53.13

DioxusはAndroidもiOSも対応してるのか
なかなか良さそうだな

**デフォルトの名無しさん** · 2025/06/01(日) 10:53:22.67

互換性ねえ
JVMと完璧な互換性のあるScalaみたいなのをまた作りたいのか

**デフォルトの名無しさん** · 2025/06/01(日) 10:59:10.87

Androidではjni-rs使ってRustで書けるのね

**デフォルトの名無しさん** · 2025/06/01(日) 11:27:32.43

>>287
Rustで一番書きたいのは、ビジネスロジックというかバックエンド側だし
今現在GUIの表現において、一番大量の資産と表現力があるのはWebブラウザだから、あんまりそっちをRustでこだわるうまみって薄いんよな
Excelだってテキストエディタだってもうブラウザベースでやれてんだし

ハード屋でもないなら、どうせフロントには一切触れないとかありえないからそっち方面の資産は持ってるだろってのもある

**デフォルトの名無しさん** · 2025/06/01(日) 12:35:57.00

偏見だけどそもそもRustを好むような人ってフロントやりたがらない印象がある

**デフォルトの名無しさん** · 2025/06/01(日) 13:03:57.46

DioxusもwebviewレンダリングじゃなければIME部分を含めバグだらけなのでまだまだ使い物にならないよ
どのライブラリもwinit依存が多いからバグも共有してるものが多い

>あれだけメモリ安全性に固執しておいて、バグッててもOK的な姿勢とは。
これは耳が痛いね

**デフォルトの名無しさん** · 2025/06/01(日) 14:36:26.65

>>296
バグどれよ？

**デフォルトの名無しさん** · 2025/06/01(日) 15:24:01.36

>>296,297
ちょっとおねだりが過ぎませんか？w

dioxusは不合格でした
https://i.imgur.com/EcQtVvZ.png

**デフォルトの名無しさん** · 2025/06/01(日) 15:31:33.86

platformはデフォルトのdesktop

WebView2 Managerが起動するので
> Render using Webview or - experimentally - with WGPU or Freya (Skia)
の内Webview backendかと

ウィンドウ移動やフォーカスを変えたりすると>>298になります

**デフォルトの名無しさん** · 2025/06/01(日) 15:35:54.01

>>298
それの何が問題なの？

**デフォルトの名無しさん** · 2025/06/01(日) 15:40:02.37

>>298はDioxus TodoMVCのテキスト入力ボックスにフォーカスがあります

逆にWebViewでここまでひどいとは思いませんでした

フォント中華
インライン入力可
再変換可
再フォーカス後オンオフ状態リセット、入力途中文字も消える

**デフォルトの名無しさん** · 2025/06/01(日) 15:43:26.55

>>296,298
WebView内で閉じた処理はブラウザベースなので良いのでしょうが(中華フォント以外)
WebViewと橋渡しする処理がバグっているのでしょう

**デフォルトの名無しさん** · 2025/06/01(日) 16:18:17.18

まじで？
それタイミング関係なく常に発生する？

**デフォルトの名無しさん** · 2025/06/01(日) 16:46:42.32

>>298の画像を見ても問題があるように見えない
重箱の隅を突くようなバッシングをしてる？

**デフォルトの名無しさん** · 2025/06/01(日) 16:53:14.17

ウィンドウ移動ですかね、>>298 バグのトリガー

正常動作(IMEオンしないパターン)
TodoMVC起動(自動的にテキストボックスに入力フォーカス)
タイトルバーをつまんでウィンドウを少し移動(入力フォーカスはテキストボックスのままカーソル点滅もしている)
キーボード入力
テキストボックスに反映される

異常動作(IMEオンするパターン)
TodoMVC起動(自動的にテキストボックスに入力フォーカス)
FEP切り替え
IMEオン
タイトルバーをつまんでウィンドウを少し移動(入力フォーカスはテキストボックスのままカーソル点滅もしている)
キーボード入力
デスクトップ左上に位置に入力エコーバックと変換候補ウィンドウ

起動後の初回IMEオン以外でも
テキストボックスフォーカス&IMEオンのまま、ウィンドウを移動、キーボード入力したら再現するかと

**デフォルトの名無しさん** · 2025/06/01(日) 16:59:11.99

>>304
アプリが IME に非対応なときは IME の側で離れた場所に窓を開いて対処する仕組みになってる。
つまりこれはアプリが IME のサポートを(充分には)していない図。

**デフォルトの名無しさん** · 2025/06/01(日) 16:59:40.03

>>305
その動作の何が問題なのかな
webviewを使ってる数多のアプリでの動作は？

**デフォルトの名無しさん** · 2025/06/01(日) 17:01:32.91

>>307
自分でVSCodeで試してみたらいいでしょ
いくらRustエアプでもそれくらいはすぐできるだろ？

**デフォルトの名無しさん** · 2025/06/01(日) 17:07:21.32

コーディングができるのは玄人だけだがインストールと設定は素人でもできる
という認識と
フォントが文字化けしたりする現実が乖離してるんじゃないか

**デフォルトの名無しさん** · 2025/06/01(日) 17:13:02.27

>>308
Microsoft管轄のと比較しても意味ない
もっと単純な比較をすべきだ

**デフォルトの名無しさん** · 2025/06/01(日) 17:21:03.72

>>310
だったらSlackで試したらいい
Rust経験ないのは仕方ないとしてもプログラミング自体完全エアプじゃなきゃさすがに入ってるだろ

**デフォルトの名無しさん** · 2025/06/01(日) 17:26:45.46

なぜデカいのと比べようとする？
もっと単純な比較にしとけよ

**デフォルトの名無しさん** · 2025/06/01(日) 17:34:03.73

>>305
なるほどありがとう
普通のWebViewアプリやブラウザでは再現しないから何かバグってるんだな
WebViewに全部まかせてるわけじゃないのか

**デフォルトの名無しさん** · 2025/06/01(日) 17:41:33.42

比較がおかしい
WebViewを使うGUIフレームワーク同士を比較しないと意味がない

**デフォルトの名無しさん** · 2025/06/01(日) 18:16:51.61

いまだにまともなGUI一つ作れないっておかしくね？

**デフォルトの名無しさん** · 2025/06/01(日) 18:29:20.11

>>314
TauriでもElectronでもWailsでも、サンプルに入ってるような小さなアプリをビルドすれば分かるんじゃない？

**デフォルトの名無しさん** · 2025/06/01(日) 18:38:52.12

>>315
誰も気にしていないどうでもいいことで叩き合ってるだけ
GUIは多数あり実用に使われている

**デフォルトの名無しさん** · 2025/06/01(日) 18:45:14.37

>>317
果たしてそうだろうか。

**デフォルトの名無しさん** · 2025/06/01(日) 18:49:41.21

>複オジの品質基準では「何の問題もない」
>一般的な品質基準では「問題ありまくり」

これに尽きる

**デフォルトの名無しさん** · 2025/06/01(日) 19:12:46.36

GUIを好む人はバグを再現する最小のコードを書きたがらない
反GUIの人はバグがなくても最小のコードを書いてる

**デフォルトの名無しさん** · 2025/06/01(日) 19:12:53.21

Rustに限らずGUIフレームワーク全般に言えることなんだけど、優秀なプログラマほどGUIを使わなくなるから、
ボランティアベースのGUIフレームワークってロクなの無いんだよね。
実際、Rustで成功しているGUIアプリの代表的な例として、ターミナルエミュレータがある。
Rust製のAlacrittyやWezTermはターミナルエミュレータとしては非常に人気があり、日本語も問題ない。

**デフォルトの名無しさん** · 2025/06/01(日) 19:29:51.30

Alacritty スクショ
https://i.imgur.com/rDqVWcO.png

**デフォルトの名無しさん** · 2025/06/01(日) 19:32:30.27

Rustで書くことが目的化してる人に何を言っても変わらないでしょ
ちょっとくらい見た目や動作に問題があっても、Rustで作られてるならそちらの方が優れてる的な価値観なわけだし
普通の人は逆で、作りたいものが先にあって、それを達成するのにどの道具が良いかを検討するものなんだけど

**デフォルトの名無しさん** · 2025/06/01(日) 20:23:59.45

基本的な入力動作すらまともに動かなくてもメモリ安全であればいいんでしょ
そんなアプリを誰が使うのか

**デフォルトの名無しさん** · 2025/06/01(日) 20:31:34.92

>>322
さすがにこの状態でまともに使えるとは言わんよ
手元の環境ではこんなことにはならないからAlacritty使ってるけど

**デフォルトの名無しさん** · 2025/06/01(日) 21:05:48.26

>>322
それおまえの環境がおかしいんじゃね？
こちらでは起きない
そんな問題も上がっていない

**デフォルトの名無しさん** · 2025/06/01(日) 21:07:24.61

Rustのような新興システムプログラミング言語の優位性を
業務アプリすらWebばっかで、デスクトップ開発の需要自体が死んでる令和の時代になぜかデスクトップGUIフレームワークなんかで決めようとしてる時点で
Rustはクソ言語C++のほうが優れてるみたいな感じに持ってくのがゴールなんだよね

**デフォルトの名無しさん** · 2025/06/01(日) 21:13:17.99

安心安全のはずのRustがGUIではバグだらけ
不思議

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

>>328
バグがあるなら示してみろ

**デフォルトの名無しさん** · 2025/06/01(日) 21:20:41.09

示されてるのに「こちらではおきない」で無かったことにしてるのはお前だろ。

**デフォルトの名無しさん** · 2025/06/01(日) 21:34:08.02

Alacrittyは人気のターミナルエミュレータでもう9年目だけどそんなバグは聞いたことないな

**デフォルトの名無しさん** · 2025/06/01(日) 21:35:32.32

>>305
Tauri v2もこのウィンドウ移動によるバグがあるけど誰も指摘しないから
これぐらいの軽度バグは世間的には許されるってことじゃないか？
日本語対応は100点満点じゃないけど70点ぐらいはある

**デフォルトの名無しさん** · 2025/06/01(日) 21:49:21.86

IME使った文字の入力中にウインドウを移動するっていうユースケースが、どれだけ日常かという話

**デフォルトの名無しさん** · 2025/06/01(日) 21:52:14.83

>>333
>>305の手順では必ずしも文字の入力中ではない様だけど

**デフォルトの名無しさん** · 2025/06/01(日) 21:58:36.70

>>332
そう自分で直すのが面倒だから見て見ぬふりするね
使うだけの側からしたら代わりは幾らでもある、そっと閉じ

**デフォルトの名無しさん** · 2025/06/01(日) 22:02:27.70

Rustを叩きたい人が通常ではありえない使い方をして無理やりにAlacrittyを批判してるだけか

**デフォルトの名無しさん** · 2025/06/01(日) 22:22:04.75

脆弱性もありえない使い方すると出てくるんでは
メモリ安全だからロジックに集中できて完成度があがるはずじゃなかったんすかｗ

**デフォルトの名無しさん** · 2025/06/01(日) 22:28:33.11

Windows11のAlacrittyでIME入力中にウィンドウ移動しても普通に追従するけどな
環境と再現手順を知りたいところ

**デフォルトの名無しさん** · 2025/06/01(日) 22:34:44.87

Rustのコードが1行もないソフトに同じバグがあればとりあえず安心

**デフォルトの名無しさん** · 2025/06/01(日) 22:38:36.61

>>322,338

Alacritty 異常動作(IMEオンするパターン)
Alacritty起動
IMEオン
タイトルバーをつまんでウィンドウを少し移動
キーボードでa
デスクトップ右下に変換候補ウィンドウ

Windows11

**デフォルトの名無しさん** · 2025/06/01(日) 22:42:20.46

>>338
変換候補ウィンドウが出た後にAlacrittyウィンドウを移動するのではなく
>>340の順番通りにやると再現率半分くらい
(IMEオンはAlt+`)

**デフォルトの名無しさん** · 2025/06/01(日) 22:43:57.89

Microsoft IME
旧バージョン互換性オプションオフ

**デフォルトの名無しさん** · 2025/06/01(日) 22:45:30.38

再現率が半々で、ウィンドウを移動しなくても時々発生するので
ウィンドウを移動が根本原因ではない可能性もあるかと

**デフォルトの名無しさん** · 2025/06/01(日) 22:46:29.92

tao（tauri版winit）の実装見たけど少なくともWindowsのIMEはあまりやる気ないな
WM_IME_*が↓でしかヒットしないしWM_IME_REQUESTもWM_IME_CONTROLも出てこない

https://github.com/tauri-apps/tao/blob/dev/src/platform_impl/windows/minimal_ime.rs

winitも同じかな

**デフォルトの名無しさん** · 2025/06/01(日) 22:46:30.67

今の所、WezTermでは同様のバグは発生してないですね

**デフォルトの名無しさん** · 2025/06/01(日) 22:51:47.81

>>343
再現率低いAlacritty 異常動作(IMEオンするパターン)

Alacritty起動
IMEオン
キーボードでa
デスクトップ右下に変換候補ウィンドウ

**デフォルトの名無しさん** · 2025/06/01(日) 22:57:05.24

今度はAlacrittyですか…
>Alacrittyはパフォーマンスとシンプルさを重視した自由かつオープンソースのGPUアクセレレーション端末エミュレータである。
知らんがな

**デフォルトの名無しさん** · 2025/06/01(日) 23:03:02.79

>>340
おお、確かになるね
IMEオン状態のままだとならないから切り替え直後の1回だけって感じ？
ここ数年常用してて見たことないし、うちの環境ではウィンドウ移動なしでは発生しないっぽいかな

**デフォルトの名無しさん** · 2025/06/01(日) 23:11:44.02

>>340
Rustを叩くためにそんなありえない使い方をして深刻なバグだと吹聴していたとは呆れた

**デフォルトの名無しさん** · 2025/06/01(日) 23:15:24.99

Rustは安心安全
※ただしありえない使い方をしない時にかぎる

**デフォルトの名無しさん** · 2025/06/01(日) 23:45:33.58

ありえおじ

**デフォルトの名無しさん** · 2025/06/01(日) 23:46:59.52

>>350
ありえない使い方をしても問題ないことをRust叩きしてる人が証明してくれた

**デフォルトの名無しさん** · 2025/06/02(月) 00:05:41.71

ミニマム再現条件にすると滑稽ですが
好みの位置にウィンドウを持って来るのは普通の事なので(デスクトップ)
ありえない使い方と言うよりも、windowsでネイティブ日本人がテストしてないのか?品質に出ていますね

「ウィンドウ移動する前には、IMEはオフにせよ」なんて使用条件の方が変かと

**デフォルトの名無しさん** · 2025/06/02(月) 00:06:41.28

>>348
確認できたのはそのパターンです、自分は常用してないので他のバグ発生条件までは分かりませんね
(念のためPowerToysを落としても状況は同じだった)

Dioxus TodoMVCの方はIMEオン直後だけではなくウィンドウ移動後の1キー目で>>298こうなります

**デフォルトの名無しさん** · 2025/06/02(月) 00:07:15.73

>>332,335
ターミナルで日本語入力する事自体が稀なのでAlacrittyには70点あげても良いですが
Dioxusは「そっと閉じ」の方ですね

**デフォルトの名無しさん** · 2025/06/02(月) 00:09:31.08

>>355
じゃあ、Dioxusでターミナル作ったら？

**デフォルトの名無しさん** · 2025/06/02(月) 00:11:29.28

>>344
納得しましたw

**デフォルトの名無しさん** · 2025/06/02(月) 00:13:19.40

>>355
Readmeみたらそっと閉じ

windowsでの品質は現時点も先々もこんな感じなんですかね

**デフォルトの名無しさん** · 2025/06/02(月) 00:18:26.39

Windowsを使う人は滅多にいないだろうしな
普通はLinuxかMac

**デフォルトの名無しさん** · 2025/06/02(月) 00:33:24.53

人間の頭から放電した場合は下記の経路になる
人間は電磁界【脳波８Hz～４０Hz】【電線【６０Hz】の電圧と同じ】なので周囲に影響を与えれる範囲が狭い

人体への雷撃パターン｜身を守る｜雷の知識
https://www.franklinjapan.jp/raiburari/knowledge/safety/61/
超低周波電磁界にばく露した人体に起きる電磁的現象
https://www.jeic-emf.jp/public/web_mag/explanation/1016/

1 人間の頭部から放電しないことはここで説明されている
2 お風呂場で湯船につかっているのでお湯の方に電流が流れる
3 頭からお湯をかぶっているやシャワーを浴びている場合はお湯にそって電流が流れる
4 雨降りの時は雨によって地面の方に電流が流れる
5 何か物に接している【手で手すりを触っているなど】場合はその者にそって電流が流れる

などこれらの条件がそろっているのに外部の人が対象者の思考や動作がわかるはおかしなことを話している

**デフォルトの名無しさん** · 2025/06/02(月) 01:35:42.19

>>321
何を言ってるんだか。