Rust part24

**デフォルトの名無しさん** · 2024/05/27(月) 06:41:26.82

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

**デフォルトの名無しさん** · 2024/06/30(日) 10:53:06.05

あえて >>493 で頑張ると
https://paiza.io/projects/sk40IXUgPm0k_VgI1wsHBg

fn main() {
let cwln = |s| { println!("{}", s) };
let g = |(i, line): (usize, &str)| { format!("{:>2}:{}", i + 1, line) };
let f = |file_name: String| {
cwln(file_name.clone());
std::fs::read_to_string(file_name).map(|u8b| {
u8b.lines().enumerate().map(g).for_each(cwln)
}).unwrap()
};

std::env::args().skip(1).for_each(f)
}

**デフォルトの名無しさん** · 2024/06/30(日) 10:54:12.53

do記法のたぐいはラムダで実装しても命令型で実装してもどっちでもいい
外側から見れば同じだからだ

**デフォルトの名無しさん** · 2024/06/30(日) 11:17:03.52

>>496
.net標準にはList型にしかForEachが導入されてないからやな。
C#ではチェインメソッドにしないほうがいいとされてる。
https://learn.microsoft.com/en-us/archive/blogs/ericlippert/foreach-vs-foreach

**デフォルトの名無しさん** · 2024/06/30(日) 12:31:43.09

>>499
「.ForEachしたいけど標準にないからToListする」という考え方が間違い
enumerable.ToList().ForEach()のパターンは最悪

それとそのEric Rippertの意見がMSやC#コミュニティのコンセンサスというわけではないよ
IEnumerable以外ではForEach等の副作用適用メソッドが標準で用意されてるものが多々あるしIEnumerableに拡張メソッド追加して使ってるところもごまんとある

**デフォルトの名無しさん** · 2024/06/30(日) 13:08:54.78

>>497
キツイ

**デフォルトの名無しさん** · 2024/06/30(日) 13:13:35.11

>>500
foreachとForEachくらいは好きなほうでやればいいわな
ものによっては最適化度合いが変わるからそこだけ気にしとけばいい

**デフォルトの名無しさん** · 2024/06/30(日) 13:41:54.85

unwarpほんま糞ダサい

**デフォルトの名無しさん** · 2024/06/30(日) 14:01:03.54

「すべてはオブジェクトである」が糞ダサいのだ
いい感じの構文糖はたいていオブジェクトではない

**デフォルトの名無しさん** · 2024/06/30(日) 15:34:51.28

>>497
エラー返しができていない
ファイル一括読み込みでなくバッファリングすべき
本当の関数型だとセミコロンを使うのは邪道

**デフォルトの名無しさん** · 2024/06/30(日) 16:34:51.56

>>497
ありがとうございます。
u8b受け取ってるラムダ式を関数化したらスッキリしそうですね。

>>496
Selectもindexを受け取れるんですが値を返さないとダメで、
あえてvoidなメソッドの後にreturn 0を、入れてエラーが出なくなったと思ったら、
遅延評価なのかfor/foreach/ForEachじゃないと中身を実行してくれないんですよ…orz
（結論、Selectはデータ加工専用で入出力には使えない）

**デフォルトの名無しさん** · 2024/06/30(日) 16:49:10.64

Rustで関数型のように書くなら

use std::env;
use std::fs::File;
use std::io::{self, BufRead, BufReader};

fn main() -> io::Result<()> {
　env::args()
　　.skip(1)
　　.inspect(|file_name| println!("{file_name}"))
　　.map(|file_name| {
　　　File::open(file_name).and_then(|file| {
　　　　BufReader::new(file)
　　　　　.lines()
　　　　　.enumerate()
　　　　　.map(|(i, line)| line.map(|line| println!("{}: {line}", i + 1)))
　　　　　.collect()
　　　})
　　})
　　.collect()
}

**デフォルトの名無しさん** · 2024/06/30(日) 16:59:35.48

質問です。

.map(|(i, line)| line.map(|line| println!("{}: {line}", i + 1)))
↑
line.mapは文字列へのmapで１文字１文字に番号振ってる様に見えますが、違うのでしょうか？
素直に

.map(|(i, line)| println!("{}: {line}", i + 1))

とは出来ないのでしょうか？

**デフォルトの名無しさん** · 2024/06/30(日) 17:13:06.42

>>508
そこは手続き型で書くと
let line = line?;
のところ
最初のlineはio::Result<String>型
それをmapして次のlineがString型

**デフォルトの名無しさん** · 2024/06/30(日) 17:55:47.01

こうやって関数型を勘違いしたやつが量産されてるんだな

**デフォルトの名無しさん** · 2024/06/30(日) 18:10:42.55

>>509
なるほど、最初のmapと内側のmapで型が違うのですね。
ありがとうございました。

**デフォルトの名無しさん** · 2024/06/30(日) 18:12:41.76

さすが二つ名持ちの汚コーダー
ひと味もふた味も違う

**デフォルトの名無しさん** · 2024/06/30(日) 18:28:40.79

関数型のように書きたいならば基本はfor_eachを使わない
行き詰まりのfor_eachを使うと値もエラーも返せなくなる

**デフォルトの名無しさん** · 2024/06/30(日) 18:46:14.08

>>506
イテレータがどういうものか全然理解してないのな
試行錯誤もいいが最低限の座学知識は必要やぞ

**デフォルトの名無しさん** · 2024/06/30(日) 20:38:10.26

let a: [u32; 4] = [1, 2, 3, 4];
let s: &[u32] = &a[1..3];

a[5]; と書くとコンパイルエラーが発生しますが、
s[5]; と書くとコンパイルは通り実行時にエラーが発生します。

なぜ、 s[5]; が範囲外の領域へのアクセスであることをコンパイル時に見抜けないのでしょうか？

本を見ても、理由が書いてないです。
ただ、そうなるとしか書いてありません。

**デフォルトの名無しさん** · 2024/06/30(日) 21:21:34.70

見抜けるようになっていないから
a は array である一方で s は slice
array は型として長さの情報を持つ一方 slice は持たない
slice の長さはコンパイル時にわからないしわかろうともしないしチェックもない

**デフォルトの名無しさん** · 2024/06/30(日) 21:23:59.76

>>515
静的にサイズが定数だと静的に比較できるから事前にコンパイルエラーとなる
配列は静的にサイズが定数
スライスもこのように静的にサイズを定数にしてやれば事前にコンパイルエラーとなる
const X: &[u32] = &[1, 2, 3, 4];
let x = X[5];

**デフォルトの名無しさん** · 2024/06/30(日) 21:57:28.27

🦀🦀🦀

**デフォルトの名無しさん** · 2024/06/30(日) 22:10:02.00

本といえども一方通行のメディアではなくなってるんじゃないか
読者の側がそれをどうしても知りたい気持ちを表明しなければならないのが双方向でしょ

**デフォルトの名無しさん** · 2024/06/30(日) 22:48:34.24

>>513
一体全体何を言ってるんだ？

**デフォルトの名無しさん** · 2024/06/30(日) 23:09:55.43

>>520
for_eachは値を返せない
関数は基本的に値やエラーを返す
イテレータ利用で値やエラーを返すためにはfor_eachではなくcollectやfoldなどを用いる

>>507のように表示するだけで値を返さない場合であっても
関数はエラーを返さなければならない

**デフォルトの名無しさん** · 2024/07/01(月) 00:45:59.76

>>521
>for_eachは値を返せない
for_eachはunitを返してるよ

>関数は基本的に値やエラーを返す
voidやunitやnilを返すものも関数だよ

>イテレータ利用で値やエラーを返すためにはfor_eachではなくcollectやfoldなどを用いる
try_for_each使ってね
file openやprintのような副作用をイテレータのmapで行うのは関数型の考え方からは程遠いよ

**デフォルトの名無しさん** · 2024/07/01(月) 01:02:37.18

値を()しか返せないのでは意味がない

**デフォルトの名無しさん** · 2024/07/01(月) 01:19:54.94

お前の人生よりは意味あるよ

**デフォルトの名無しさん** · 2024/07/01(月) 04:16:03.32

unwrapをmapで代用とかセンス無さ過ぎ

**デフォルトの名無しさん** · 2024/07/01(月) 05:26:16.34

見抜いたことを全て警告するコンパイラがあったらこんな感じになるのか

**デフォルトの名無しさん** · 2024/07/01(月) 05:49:45.95

Rustは清書用(キリっ

**デフォルトの名無しさん** · 2024/07/01(月) 05:51:10.72

犯人不明ボイス・トォ・スカル被害者にしている者皆判明
AIで被害者が苦しんでいる映像を作成してそれで喜んでいる脳細胞を読み取れば使用しているかの判定
AIで自分が高みの見物ができるかどうかも判定
あとは下記を参考にして行えばよい

いじめで殺害したかも判明するので迷宮入り事件犯人を絞り込める
隠しカメラの場所も判明

忘れた記憶を再び思い出せるようにする脳細胞を発見！
2024.06.28
「あなたの一番古い記憶は？」人は覚えていても2歳以前の記憶にアクセスできなくなっている
2023.11.30
なぜ私たちは起こってもいない間違った記憶をしてしまうのか？
2023.11.27
自分でも気づいていない「記憶の間違い」を脳波で判断できると判明
2023.10.19
富山大、睡眠中の脳で行われている推論の演算を神経細胞レベルで解明
2024/06/26
サイコパスはためらわない？－－嘘つきの脳のメカニズム
2019/09/26

脳を刺激して特定の記憶を呼び戻す技術「記憶プロテーゼ」を開発
2024/02/21

「0」を”思う”ときの脳活動は「1」に近い！捕食者への恐怖がゼロの根幹だった？
2024.03.07
>>MEGを使うと、脳内でわずかに発生する磁場変化をとらえて、脳活動を記録することが可能です。
>>（※脳波計が脳の電気活動を読み取るのに対して、脳磁計は脳の磁気活動を読み取ります）

東工大、磁束集中器を用いない高感度「ダイヤモンド量子センサ」を開発
2024/06/07
>>日常的な検診や脳機能のより詳しい研究や、ブレイン・マシン・インタフェースの研究などへ大きく貢献できると期待されている。

**デフォルトの名無しさん** · 2024/07/01(月) 06:29:11.19

>>525
unwrapは使わずにmapでNone/Errを透過的に渡すのはRustの基本

**デフォルトの名無しさん** · 2024/07/01(月) 07:19:14.88

これmapメソッドでもmap関数でもない中立な勢力が勝つパターンだ

**デフォルトの名無しさん** · 2024/07/01(月) 11:47:54.40

Functorのmapなんだよね
でもFunctorは定義されてなくて統一的に扱えないんだから
Result/Optionはfmapとか違う名前にしておいたほうがよかったと思う

どっちにしろmap/fmapで副作用はアンチパターン

**デフォルトの名無しさん** · 2024/07/01(月) 11:55:40.56

fmapなんかflatMapと勘違いされるだろ

**デフォルトの名無しさん** · 2024/07/01(月) 12:47:47.85

そんな勘違いをする人にRustは無理

**デフォルトの名無しさん** · 2024/07/01(月) 12:59:53.25

>>525
こう書くとresultがErrの時に返せずここでpanicになってしまう

　let val = result.unwrap();
　f(val)

そのためpanicしてもいいとか絶対にErrとならない特殊な場合を除けば
unwrapを用いてはダメでmapを使ってこのように書くんだよ

　result.map(|val| f(val))

ここで本当に関数fを呼ぶだけならresult.map(f)と簡略化できるけど
f(val)の部分は式やブロックの可能性もあるので簡略化せずに進めるね

これは以下と同等でErr(err)の時に保持してくれている

　match result {
　　Ok(val) => Ok(f(val)),
　　Err(err) => Err(err),
　}

ちなみにf(val)もResultを返すときは
mapの代わりにand_thenがある

　result.and_then(|val| f(val))

つまり以下の二つは同等

　result.map(|val| f(val))
　result.and_then(|val| Ok(f(val)))

この場合はもちろん簡素なmapを用いるべき

**デフォルトの名無しさん** · 2024/07/01(月) 13:41:34.54

Rustを10年以上使ってるひとに質問です
Rust本体をバージョンアップしたときに
動かなくなった旧バージョン用のcratesや自分のプロジェクト(main.rsなど)は
どれくらいありましたか？
またdeprecatedやobsoletedにされた機能は
使えなくなるまでに実際何年くらい使い続けられましたか？

**デフォルトの名無しさん** · 2024/07/01(月) 14:05:59.07

Rust 1.0からまだ10年経っていない
Rustは3年毎のedition制度があって後方互換性がない変化はeditionが変わるため安心
今も最初のRust 2015 editionがサポートされてる
さらにedition移行支援ツールもある
Rustは他言語と比べてかなり恵まれてる良い環境

**デフォルトの名無しさん** · 2024/07/01(月) 14:11:38.44

>>534
>ちなみにf(val)もResultを返すときは
の条件なら
>つまり以下の二つは同等
>　result.map(|val| f(val)) // Resultを還さないf
>　result.and_then(|val| f(val)) // Resultを還すf
じゃないんですかね(Ok(f(val))は蛇足)

**デフォルトの名無しさん** · 2024/07/01(月) 14:22:14.04

Resultを返すか返さないか関係なくこれは常に成り立つね

>>534
＞以下の二つは同等
＞ result.map(|val| f(val))
＞ result.and_then(|val| Ok(f(val)))

例えばf(val)がOptionを返したとしても成立するよ

**デフォルトの名無しさん** · 2024/07/01(月) 14:22:38.11

flat_map の関数名を and_then にしたのはどこの言語の文化？

**デフォルトの名無しさん** · 2024/07/01(月) 14:43:32.98

iostreamの記号をまるでセガサターンのように見下して英単語を推した文化

**デフォルトの名無しさん** · 2024/07/01(月) 14:48:54.46

and_thenはor_elseに対してのantitheseだと思った

**デフォルトの名無しさん** · 2024/07/01(月) 14:51:31.68

result1.and(result2) がまずあって
result1.and_then(|ok1| return_result2(ok1)) が関数版だね
OptionでもResultでも同じ命名

**デフォルトの名無しさん** · 2024/07/01(月) 14:59:21.90

iostreamの << をRustに導入しなかったのはなぜ？

**デフォルトの名無しさん** · 2024/07/01(月) 15:05:11.12

std::fmtで十分だから

**デフォルトの名無しさん** · 2024/07/01(月) 15:05:34.52

うるせぇやりたきゃShl実装しろ

**デフォルトの名無しさん** · 2024/07/01(月) 15:30:41.32

>>543
単純な二項演算子でやると書式指定の範囲を制御できないんだよ。
C++ ではストリームに対する書式指定は永続的な効果を持っていて、その効果を上書きするまで続く。
普通の方法で指定したらグローバルな影響を持ってしまうのは明らかにまずい。

iostream が出来たときは可変長引数の関数を型安全に扱う方法 (variadic template) が無かったし、
書式指定文字列をコンパイル時に解釈して安全に扱う方法 (constexpr) も無かったから
その範囲内で当時の知見で比較的マシな形にしたらああなったという程度のもんで、
今の考え方からすると iostream は真似したいようなもんじゃない。

むしろ C++ のほうが新しい仕様では Rust 風のやり方に寄せて来てる。

**デフォルトの名無しさん** · 2024/07/01(月) 15:53:07.19

>>543
ダサすぎるから

**デフォルトの名無しさん** · 2024/07/01(月) 15:56:35.04

rustもprint時のstring interpolationはもう少しどうにかならんものかね

**デフォルトの名無しさん** · 2024/07/01(月) 18:51:52.61

macroなんで自分で描き替えればええんやで

**デフォルトの名無しさん** · 2024/07/01(月) 20:45:22.07

自作した後の自己肯定を10年続けるまでがプログラム技術

**デフォルトの名無しさん** · 2024/07/01(月) 23:04:21.05

昔、C++でprintf使ったら怖い人に怒られたのに
今じゃあれはクソ設計だったって評価に固まってるんだね、英語圏でも

**デフォルトの名無しさん** · 2024/07/01(月) 23:12:10.92

>>551
C/C++ の printf は iostream 以上にカス。
型のチェックがガバガバだし、ちゃんと理解してないやつのほうが多いので常に問題を引き起こしていた。
ただ、記法としてはこれで良かった。

**デフォルトの名無しさん** · 2024/07/02(火) 02:06:02.53

今の C/C++ の printf はコンパイル時に型チェックして警告してくれる

**デフォルトの名無しさん** · 2024/07/02(火) 05:00:17.05

>>553
型チェックできて型がわかっているのに
なぜ%dや%fや%sなど指定しなきゃいけないのか理解できない
型がゆるゆるだった大昔の遺物にみえる

**デフォルトの名無しさん** · 2024/07/02(火) 06:06:14.65

>>554
みえる、じゃなくて完全に遺物だろ

**デフォルトの名無しさん** · 2024/07/02(火) 06:44:02.90

表示はRustのDisplayトレイト実装方式が洗練されていて使いやすくていいね

**デフォルトの名無しさん** · 2024/07/02(火) 08:28:24.43

仕様書が聖書のようなものだから遺物だろうが仕様書に逆らうわけにはいかないじゃん

**デフォルトの名無しさん** · 2024/07/02(火) 08:41:47.20

>>544
C の関数は基本的にはちゃんと型はついてるが可変長引数は静的な型情報を捨てること実現してる。
もちろんそれを引き継いだ C++ も。
C++ は後に variadic template による安全な可変長引数を導入したが古いスタイルの可変長引数も廃止はしてない。
言語仕様を素朴に実装したら型はわからないんだよ。
printf などの一部の関数に限っては「関数の型情報によらずに」コンパイラが特別扱いでチェックしてる。
関数の型を元に検査してるんじゃなくて printf の仕様をビルトインして特別扱いしてるの。

**デフォルトの名無しさん** · 2024/07/02(火) 10:27:11.96

>>538
result.and_then(|val| Ok(f(val)?))
とか
result.and_then(|val| Ok(f(val).unwrap()))
じゃなくて
result.and_then(|val| Ok(f(val)))
で良いのはなぜ？

**デフォルトの名無しさん** · 2024/07/02(火) 10:37:23.15

Rust初めて使ったときは「println! みたいな基本的なものがマクロで？大丈夫かこの言語」みたいに思ったもんだが、
よくよく考えるとマクロにせずに、柔軟なシグニチャでなんとかしようとする他の言語のほうがよっぽど醜いもんな。

**デフォルトの名無しさん** · 2024/07/02(火) 10:55:15.33

>>559
上2つはResult<T>
最後のはResult<Result<T>>かResult<Option<T>>
ネストが一つ深くなる

**デフォルトの名無しさん** · 2024/07/02(火) 11:50:20.39

>>560
C++ のライトユーザは関数テンプレートのことを誤ってテンプレート関数と呼ぶことが頻繁にある。
関数テンプレートが関数であるという誤解が言葉になって表れてるんだと思う。
単に使うだけなら関数みたいに見えてしまうからかもしれない。

関数テンプレートは関数を生成する元になるテンプレートだから関数テンプレートなので「生成する」というところに着目したらマクロで生成するのでも理屈はあまり変わらないかもしれない。

ただ、 LISP 系言語の経験から言うと構文レベルで制御されるマクロはエディタのサポートが受けづらいし、ドキュメントを型で表現できないのはやりづらい。
マクロ展開の失敗がどういう失敗なのかをきちんとエラーメッセージにするのも難しい。
デメリットもあるけど、どうせどこかに問題があるならこのくらいで良いという潔さは感じる。

**デフォルトの名無しさん** · 2024/07/02(火) 12:37:13.61

仕様書がなくなっても
統合環境の支援の成功体験から逆算された縛りがあるんだな

**デフォルトの名無しさん** · 2024/07/02(火) 16:01:50.82

and_thenってネストが深くても自動で中いじってくれるのか

**デフォルトの名無しさん** · 2024/07/02(火) 17:51:34.66

Slint ってなんなん？ javascript ?
conrod とどう違うん？

**デフォルトの名無しさん** · 2024/07/02(火) 18:31:45.59

conrodならもう死んだよ

**デフォルトの名無しさん** · 2024/07/02(火) 18:32:06.29

>>559
Rustでそれらは全てmatchになるので置き換えて比較すれば理解は簡単
ちなみにmatchにすると記述が長くなるが同レベルで「?」オペレータ適用できるメリットがある

result.and_then(|val| f(val))
これはこう置き換えられる
match result {
　Ok(val) => f(val),
　Err(err) => Err(err),
}

result.map(|val| f(val))
これはこう置き換えられる
match result {
　Ok(val) => Ok(f(val)),
　Err(err) => Err(err),
}

つまり常にこれが成り立つ

>>534
＞以下の二つは同等
＞ result.map(|val| f(val))
＞ result.and_then(|val| Ok(f(val)))

**デフォルトの名無しさん** · 2024/07/02(火) 18:34:46.10

>>565
SlintはGUI部分だけ専用スクリプトで宣言して
プログラムはRustでもC++でもJavaScriptでも記述できる

**デフォルトの名無しさん** · 2024/07/02(火) 22:09:25.08

RustのGUIまわりは安定しない印象
conrodやdruidやorbtkのようにここ数年内に消えたものもあるし、いま人気のものも今後消えないとは言い切れない感じがする

**デフォルトの名無しさん** · 2024/07/02(火) 23:44:50.93

RustでGUIならこの5つ
https://iced.rs/
https://slint.dev/
https://tauri.app/
https://www.egui.rs/
https://dioxuslabs.com/
方向性がそれぞれ異なるので目的に合わせて選ぶ

**デフォルトの名無しさん** · 2024/07/03(水) 03:55:17.90

tauri遅いな
eguiはサクサク

**デフォルトの名無しさん** · 2024/07/03(水) 06:25:46.46

>>570
tauriはその中に入れるべきじゃないだろ
あれはReact/JSだぞ

**デフォルトの名無しさん** · 2024/07/03(水) 07:06:30.59

>>572
無知すぎ
Reactは全く関係ない
併用可能な一つに過ぎない

TauriではJavaScriptを一切書かなくても利用可能
Rustによるプログラミングのみでも使うことができる

**デフォルトの名無しさん** · 2024/07/03(水) 09:04:55.71

rstkはどうなの？

**デフォルトの名無しさん** · 2024/07/03(水) 20:03:02.84

しかしほんとにデスクトップアプリのライブラリってすぐ出ては消えていくな
自分で作ったほうが安定するんじゃないか

**デフォルトの名無しさん** · 2024/07/03(水) 22:16:18.13

クロスプラットフォームでいくならwinitとwgpuぐらいは頼らないと無理じゃないかな。
しかしその2つもまだまだブレイキングチェンジ激しい発展途上だけどね。

**デフォルトの名無しさん** · 2024/07/03(水) 22:53:26.72

>>574
*/Tkは30年以上の歴史と実績があるGUIライブラリ
rstkはそのRust版

**デフォルトの名無しさん** · 2024/07/03(水) 23:54:41.68

>>573
Yewのこと？ならそう書けよYewなんてくっそマイナーでReact使うのが普通なのに

**デフォルトの名無しさん** · 2024/07/03(水) 23:56:15.32

Yew使ったことあるけどゴミだぞまじで

**デフォルトの名無しさん** · 2024/07/04(木) 00:31:14.93

30年くらい前にTcl/Tkを使ったわ。

**デフォルトの名無しさん** · 2024/07/04(木) 00:37:01.85

>>575
利用者が集まらなきゃ結局のところ本番環境で使われないもんね
MAUIもだけど本番環境で使われなきゃ不具合修正すらされずにフェードアウトしていく

**デフォルトの名無しさん** · 2024/07/04(木) 04:07:16.49

>>570
eguiの公式サイト、オサレね

**デフォルトの名無しさん** · 2024/07/04(木) 07:04:39.24

サイト自体が見本なのな

**デフォルトの名無しさん** · 2024/07/04(木) 10:17:42.23

reactもこの10年でだいぶ変わったわな。
プレゼンテーション層はそういうもんかもなと思ってる。

**デフォルトの名無しさん** · 2024/07/05(金) 08:36:28.68

銀河英雄伝説で考えるセキュリティ--将来の「帝国の双璧」が陥った罠とセキュリティ業界
https://japan.zdnet.com/article/35220819/

**デフォルトの名無しさん** · 2024/07/05(金) 10:29:56.20

>>574 >>577
rstk より tk ( https://crates.io/crates/tk ) の方が良いよ

**デフォルトの名無しさん** · 2024/07/05(金) 18:22:04.62

どちらも利用者少なくて数の差ではわからんな

**デフォルトの名無しさん** · 2024/07/06(土) 04:04:15.80

Tkは何十年も前のGUIで古いからね

**デフォルトの名無しさん** · 2024/07/06(土) 04:24:49.23

やりたいことを出来る範囲で最小限の道具を選ぶのが望ましい。
Tk で足りるときは Tk を使えばよい。

**デフォルトの名無しさん** · 2024/07/06(土) 09:36:32.81

UNIX系でGUIをどうしても使わないといけない場合にTk使ってたけど
今はhtmlでいいかなって

**デフォルトの名無しさん** · 2024/07/06(土) 09:36:55.52

wgpu最強だが変化速過ぎ

**デフォルトの名無しさん** · 2024/07/06(土) 10:12:50.18

正直GUIをRustで書くメリットが思いつかない
ただの2DグラフィックでRustの実行速度を求めるってのはおかしな話だと思うもん
ロジックをRustで書いてGUIは安定してるReactでいいよ

**デフォルトの名無しさん** · 2024/07/06(土) 10:14:23.55

wgpuは三角を書きたい人向けでGUIとは関係ない

**デフォルトの名無しさん** · 2024/07/06(土) 11:05:29.63

>>592
お前がそう思うならそうなんだろう
お前ん中ではな

**デフォルトの名無しさん** · 2024/07/06(土) 12:27:12.12

>>592
reactはデータリフトアップして上にまとめるのめんどい。状態管理だけにライブラリ導入とか無理あるんじゃねーの

**デフォルトの名無しさん** · 2024/07/06(土) 12:35:51.52

streamlitなどのHTML書かないでも作れるようなのがメジャーになればいいんだけど