Rust part23

**デフォルトの名無しさん** · 2024/02/23(金) 17:37:52.13

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

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

**デフォルトの名無しさん** · 2024/04/23(火) 12:06:18.33

panicは安全ですヨ

**デフォルトの名無しさん** · 2024/04/23(火) 12:11:09.83

>>734
緊急停止して「安全ですよ」はちょっと……

**デフォルトの名無しさん** · 2024/04/23(火) 12:14:00.43

>>733
セキュリティホールにならない
異常データに対して止まり動作を続けない

**デフォルトの名無しさん** · 2024/04/23(火) 15:43:54.29

>>733
>なんでコンパイル時にエラーにできないんだろう？
出来るわけないだろw
実行時に与えられる外部入力をコンパイル時にどうやって判定するんだよw
バカすぎる

**デフォルトの名無しさん** · 2024/04/23(火) 16:19:44.91

しいて言えばargs()を使う方が特殊ケースなのにデフォルトの名前を引き継いだのは設計ミス
もう治る見込みはないからargs_os()を使おうねってだけだけど

**デフォルトの名無しさん** · 2024/04/23(火) 16:52:58.90

一応argsをdeprecatedにして徐々に移行させていくのはできるだろうけど
特に提案もなさそうだし誰も困ってないんじゃないかな
そもそもほとんどのケースでclapとか使うだろうし

**デフォルトの名無しさん** · 2024/04/23(火) 17:20:16.94

>>733
＞>>725
＞なんでコンパイル時にエラーにできないんだろう？

むしろ何でできると思ってるんだろう。謎

**デフォルトの名無しさん** · 2024/04/23(火) 17:22:13.22

環境変数もvarとvar_osがあるから慣れろとしか言えない
OS標準が全部utf-8になる未来もありえるし

**デフォルトの名無しさん** · 2024/04/23(火) 17:48:20.12

>>741
紛らわしいけどvar/var_osとvars/vars_osは別物だよ
varはinvalid UTF-8でもエラーハンドリング可
varsはpanic

argsは引数にUTF-8以外はダメだよって前提で使える余地がまだあるけど
varsはそんな前提をおける状況はほぼなくてよりたちが悪い

**デフォルトの名無しさん** · 2024/04/23(火) 18:06:35.01

>>741
>OS標準が全部utf-8になる未来もありえるし
10年前のその未来予想が大外れしてるから今となっては設計ミスとしか言いようがない
もう10年経ったとしても状況は変わらないと思う

**デフォルトの名無しさん** · 2024/04/23(火) 19:06:07.68

>>732
公式チュートリアルまともに読めるならC++で良いからな

**デフォルトの名無しさん** · 2024/04/23(火) 20:01:34.96

よーわからんけど10年ぐらい前はすべてutf16になると考えられてたのでは？

どう考えてもstd::env::argsを非推奨にしろとは思うけどね
欧米人がつくるとこんなことになるんだ

普通は2種類の扱いがある
・実行環境に合わせて自動的に内部での標準形式に変換
か
・何もしない
何もしないならOSから受け取ったままOSに渡して置けば大体問題はない

第三の愚策がRust
受け取ったままそのままOSに渡してもコケる
Rustは何もしないように見えるけど何かしてるからコケるのでは？

**デフォルトの名無しさん** · 2024/04/23(火) 20:52:29.82

>>745
間違いだらけだな
世界の標準はUTF8
ウェブももちろんUTF8
RustもUTF8

Rustがこの件でコケることはない
きちんと各関数の仕様が明記されていて常に正確に動作している

**デフォルトの名無しさん** · 2024/04/23(火) 21:05:41.35

Rustのパニックは綺麗なパニック
いいね？

**デフォルトの名無しさん** · 2024/04/23(火) 21:12:51.81

>>747
一般的なパニックは色んな意味合いがあるけど
Rustでのパニックは関数ドキュメントに明記されている想定のことが起きた
ライブラリ関数の作成者はパニックを発生させる時の条件をドキュメントに明記しなければならない
だからそれを利用する各プログラマーにとっても想定内のことのみパニックが起きる

**デフォルトの名無しさん** · 2024/04/23(火) 23:35:29.98

>>745
勘違いしてることが多すぎてもう笑うしかないwww

**デフォルトの名無しさん** · 2024/04/23(火) 23:41:39.78

>>745
>よーわからんけど10年ぐらい前はすべてutf16になると考えられてたのでは？
30年以上前にUCS-2がWindowsやJavaに採用された時代のことを言ってるのかな？
(UTF-16と違ってUCS-2は固定幅なので今でもまだ使い所はあるけど)

↓これが15年くらい前のUTF-16に対する一般的な認識
https://softwareengineering.stackexchange.com/questions/102205/

**デフォルトの名無しさん** · 2024/04/24(水) 00:43:41.33

utf-16はUnicode 2.0（1996年7月）のサロゲートペア導入でutf-8に逆転されたな
しばらくはBMPしか使われなかったから耐えてたけど
1990代前半に始動したJavaは運が悪かった

**デフォルトの名無しさん** · 2024/04/24(水) 01:21:01.63

>>749
そう書きながら何もまともなレスすらできないレス乞食

**デフォルトの名無しさん** · 2024/04/24(水) 01:23:24.26

Rust界隈では狂信者がいてそいつらはまともに反論すら出来ないけど
Rustが正しいRustが正しいと繰り返すばかり

**デフォルトの名無しさん** · 2024/04/24(水) 12:36:38.15

>>737 >>740
windows環境とかunicode以外が混ざる環境でargをコンパイルエラーにできないのかね。

そもそもargは廃止していい。

**デフォルトの名無しさん** · 2024/04/24(水) 12:47:56.41

すげーどうでもいい話だな

**デフォルトの名無しさん** · 2024/04/24(水) 12:47:57.96

>>746
なるほど。
「RustはWindowsをケアする気が無い」
ということですか。

**デフォルトの名無しさん** · 2024/04/24(水) 12:58:45.05

>>754
Windowsでも設定すればUTF-8になるしLinuxだってUTF-8以外に自由に変えられるわけだから、そんな判定は不可能
まぁ廃止していいには同意するけども

**デフォルトの名無しさん** · 2024/04/24(水) 13:18:14.84

Windows は Windows の機能として文字コードの管理はしてるが歴史的事情でツギハギのグダグダ。
今の Linux はおおよそ UTF-8 で統一されているけど規約で縛っているだけで、 OS としてはバイナリ単位で素通し。
保証としてはあてにならん。

**デフォルトの名無しさん** · 2024/04/24(水) 13:18:30.26

コンパイルエラーにできないから引数まで廃止するとか原理主義もここまで来てんのか。

**デフォルトの名無しさん** · 2024/04/24(水) 14:25:14.78

>>754
無知にもほどがある！

unicodeとUTF-8が区別できない
Windowsに限らずLinuxでもmacOSでも非UTF-8の引数や環境変数が使われる可能性があるのは同じなんだがそんな常識を知らない

**デフォルトの名無しさん** · 2024/04/24(水) 15:25:54.44

>>760
そんなんだったらなおさらのこと、Rustの安全指向に従ってargs_osだけにすべきで、argsは廃止にすべきだろ。
Rustはメモリ安全しか興味無いんかね。

**デフォルトの名無しさん** · 2024/04/24(水) 15:53:48.65

保証できるものはするに越したことはないけど (充分に実行コストが小さい形では) できんからしゃーない。

**デフォルトの名無しさん** · 2024/04/24(水) 16:02:42.64

どうでもいい話でもめてるな
Rustはすべて提供してドキュメントにそるぞれ明記しているのだから使う側の各自の問題
こちらはUTF8環境でしか使われないのでargs()のみ利用している

**デフォルトの名無しさん** · 2024/04/24(水) 16:05:40.76

https://github.com/rust-lang/rust/issues/91226#issuecomment-1034188905
関係する議論はこのあたりかな
もともとはargs/varsをパニックさせずに無視するか置換してほしいって要望だったが
無視や置換はセキュリティ上問題になる可能性があるので却下
varsは将来的にdeprecatedにするかもと言っている
なんでargsもdeprecatedにすべきだろって提案すれば通る可能性はあるかもね

**デフォルトの名無しさん** · 2024/04/24(水) 16:26:19.27

正しく使え論は暴論だな

それが許されるならスマートポインタやGCは出ずみんな今でも生ポインタを使ってる

**デフォルトの名無しさん** · 2024/04/24(水) 16:40:56.16

>>765
生ポインタは安全ではないから全く違う
argsは常に安全

**デフォルトの名無しさん** · 2024/04/24(水) 16:44:59.20

常に自動変換したほうが安全だけどな
開発者が特別コードを書く必要もない

**デフォルトの名無しさん** · 2024/04/24(水) 17:05:56.77

Rustはファイル名も自動変換なんかしていないように
変換するかどうかは各自の自由裁量であるところが非常に良い点だよ
自分の好みと合わないからといって批判している人たちは頭がおかしいので相手にしても無駄なのだろうけど

**デフォルトの名無しさん** · 2024/04/24(水) 17:17:38.15

>>768
ここまで読んで何の話をしているのか理解できないならRust使うのは辞めたほうがいい

**デフォルトの名無しさん** · 2024/04/24(水) 17:21:01.52

ファイルの引数だけ標準では何もしない
普通のキーボード入力などでは変換している

**デフォルトの名無しさん** · 2024/04/24(水) 17:23:28.05

>>770
え？？

**デフォルトの名無しさん** · 2024/04/24(水) 18:26:14.33

>>768
自動変換は正直意味不明だが（変換元の文字コードが判定不能なのに何を変換するのか？）
argsは今RFC出したらResultにしろって突っ込まれると思うし
1.0であまり深く考えずに入れちゃった気はするよ

**デフォルトの名無しさん** · 2024/04/24(水) 18:50:02.66

Resultとかのハンドリングが面倒な人向けの簡便方法として用意されてるのでそれはないと思う

argsじゃなくてargs_utf8onlyとか名前をダサくして
逆にargs_osを元のargsに戻しとけば
リファレンスをよく読まない人たちがつまづく可能性を下げられる

**デフォルトの名無しさん** · 2024/04/24(水) 19:00:18.55

こういうのを見ると、RustのデザイナーはRustに求められているのがなんなのか理解できていないと思うわな。

Rustは雇われコーダー用Safe Rustのニーズがほとんどで、Unsafe Rustとかのニーズは無いと思うがね。

**デフォルトの名無しさん** · 2024/04/24(水) 19:01:34.27

>>772
自動変換が本当に意味不明ならここまでの話が見えてないとしか言いようがない

**デフォルトの名無しさん** · 2024/04/24(水) 19:14:39.18

自動変換とかそんなアホなこと言ってるのはあんただけやで
そんなものは無いし必要ない

**デフォルトの名無しさん** · 2024/04/24(水) 19:18:07.57

こいつOsStringの概念が分かってないのか
本当に知能レベルが低すぎる

**デフォルトの名無しさん** · 2024/04/24(水) 19:45:20.62

OsStringはOSから渡されたバイト列をそのまま格納するだけで
EUC-JP環境ならEUC-JPバイト列がそのまま入るし何も変換されたりしないが…

**デフォルトの名無しさん** · 2024/04/24(水) 19:49:39.48

想像力が欠如しているか頭がおかしいか指示待ち人間だからそういう幼稚なレスになる

結局内部で使う場合は簡単にutf8に変換してる
なにからutf8に変化するか指示も必要がない
ただのボイラープレート

**デフォルトの名無しさん** · 2024/04/24(水) 19:58:53.67

>>777
自動変換なんてものはない
むしろ自動変換を避けるために用意されているのがOsString
もちろん自動変換は行われない

**デフォルトの名無しさん** · 2024/04/24(水) 20:02:00.63

人間じゃなくて壊れたロボットに話しているようだな
いくつになろうとこんなダメな人間になってはいけないな

**デフォルトの名無しさん** · 2024/04/24(水) 20:16:20.94

ぼきのかんがえたさいきょうのげんごにはstring<encoding>とchar<encoding>があって
どんなエンコーディングの文字列でも統一的に扱うことができましゅ
Rustもまだまだでしゅね

**デフォルトの名無しさん** · 2024/04/24(水) 20:44:42.25

ほとんどの環境がWebも含めてUTF8に統一となったからRustのstr/String内部表現がUTF8であるのは合理的といえる
もちろんWebでもローカルファイルでも古いものは様々な文字コードが使われているため必要なら各々で対処する必要がある

**デフォルトの名無しさん** · 2024/04/24(水) 21:30:38.14

文字コードをUTF-8とか特定のものに決め打ちにしないという点ではRubyが一番先進的だったが、あれはやりすぎで以降の言語には採用されなかったな。

**デフォルトの名無しさん** · 2024/04/24(水) 21:49:41.83

めちゃくちゃ間違ってるのになぜ上から目線で自信満々にレスするんだろう？
複オジは昔の自分を諭してる気分じゃないか？

**デフォルトの名無しさん** · 2024/04/24(水) 22:41:53.26

Rustが正しいの一点張りの狂人

**デフォルトの名無しさん** · 2024/04/25(木) 01:24:12.71

>>0774
お前の着眼点は凄えよ！感動した。
その通り、Rustは初心者/素人御用達言語だよ。

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

おじいちゃん誰にも相手にされず寂しくなったんだねw

**デフォルトの名無しさん** · 2024/04/27(土) 03:20:12.65

聞き分けることができない。
https://kanji.reader.bz/pronunciations/last,lust,rust

**デフォルトの名無しさん** · 2024/04/27(土) 21:28:13.67

crates.io が死んだときはどうすれば良い？

**デフォルトの名無しさん** · 2024/04/27(土) 21:31:55.69

cargo run --offline

**デフォルトの名無しさん** · 2024/04/28(日) 09:02:55.08

ミラーサイトとか無いんだっけ？

**デフォルトの名無しさん** · 2024/04/29(月) 14:17:37.62

5chが荒らされてる時はどうすれば良い？

**デフォルトの名無しさん** · 2024/04/29(月) 16:10:30.59

取り敢えずアゲとけばいいんじゃね？

**デフォルトの名無しさん** · 2024/04/30(火) 02:47:45.81

したらば掲示板あたりに避難所作っておけばいかが

**デフォルトの名無しさん** · 2024/04/30(火) 03:09:09.37

落ち着いてpanicしよう

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

core吐きそう

**デフォルトの名無しさん** · 2024/05/01(水) 23:17:38.38

python みたいに何でも格納できる辞書型ってC++には無いよね？

**デフォルトの名無しさん** · 2024/05/02(木) 02:40:57.58

enumも弱いなあ

**デフォルトの名無しさん** · 2024/05/02(木) 18:14:15.88

anyとmap組み合わせればいいんじゃね？
ここRustスレだけど

**デフォルトの名無しさん** · 2024/05/02(木) 20:59:19.04

Rustで辞書型はHashMap
複数の型を格納したかったらenumかdyn Trait
TraitをAnyにするならdowncastして使う
実際には共通に処理したい目的があるはずなのでそのTraitを用意すればdowncastしなくて済む

**デフォルトの名無しさん** · 2024/05/03(金) 11:35:32.62

pythonみたいにだからclassがわりなのかも

p["name"]="yamada taro";
p["age"]=25;
みたいなのかな
いずれにしてもC++じゃないので

**デフォルトの名無しさん** · 2024/05/03(金) 23:02:14.16

静的型付けの有用性が大きく上回るから
そのケースならstructにするだろうし
色んな型を横断的に扱いたいケースならtraitかな

**デフォルトの名無しさん** · 2024/05/04(土) 04:23:28.64

https://pbs.twimg.com/media/GLs31gXbYAA6xIr.jpg

**デフォルトの名無しさん** · 2024/05/04(土) 09:38:11.89

GUI付きのポータブルなデスクトップアプリを作るとなるとどのライブラリがいいんだろ？

**デフォルトの名無しさん** · 2024/05/04(土) 12:00:07.75

tauri?

**デフォルトの名無しさん** · 2024/05/04(土) 12:04:17.00

UIはもうネイティブにこだわらなくてもいいんじゃないかな
昔からwebでしかUI提供してないソフトはゴロゴロある

**デフォルトの名無しさん** · 2024/05/04(土) 15:02:31.51

用途次第
WebベースのUIでは反応速度が遅すぎる場合もあるしサイズが許容できない場合もある

**デフォルトの名無しさん** · 2024/05/04(土) 15:44:19.83

Tauri は各環境の WebView を使うからアプリケーションの側では管理しなくてよくなり楽……
みたいな言説もあるが、 WebView の種類・バージョンを固定できないから変化に追従する必要が生じる。
そもそもウェブの世界は変遷が激しい。
Living Standard ってなんやねん。普通の産業の感覚では信じられんようなことをしやがる。
元からウェブ系のスキルセットを持っている人が開発してメンテナンスもするってのなら
Tauri は良い選択肢だと思うが、それなりにデメリットもあるよ。

ただ、多言語 (というか Unicode) に隅々まで対応しているようなフレームワークってことになると
ウェブ系の基盤がめちゃくちゃ整備されているのでそこらへんは唯一無二だわ。

**デフォルトの名無しさん** · 2024/05/04(土) 16:01:23.73

即応性が必要な人は特殊な学習を手間暇というか単純に時間をかけてやって
そうでない場合は普通にhtmlで

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

実行時のメモリ使用量の違いもかなり大きいから最初に考慮しといた方がいい
常駐の軽いアプリを作りたい場合なんかは特に

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

UI を記述するためのものとしては html は「普通」じゃないってことをウェブ系の人は思い出して欲しい。
元はドキュメント記述用だったのに html5 から大幅に路線変更してアプリケーション基盤として再編したけどどう見たって無茶苦茶だ。
ウェブの人が使う分にはこれでいいことは否定しないけど、 UI 記述の「普通」ではない。

**デフォルトの名無しさん** · 2024/05/04(土) 16:17:08.35

UI記述は宣言的なものが主流になりつつあってhtml的なものが「普通」になってきてるんだよ

MFCやCocoaやGTK的なものが今では逆に「普通」ではない

**デフォルトの名無しさん** · 2024/05/04(土) 16:22:01.06

html5は死んだ
もうどこにも存在しない

**デフォルトの名無しさん** · 2024/05/04(土) 16:22:16.16

>>813
宣言的がどうこうとかいう問題ではなく html が「普通」ではないと述べてる。
これが良いとか悪いとか言ってるわけではないよ。
まず第一に選ぶべき「普通」だとする論を否定してる。

**デフォルトの名無しさん** · 2024/05/04(土) 16:58:29.96

じゃあslint?

**デフォルトの名無しさん** · 2024/05/04(土) 18:05:18.74

何気にslintと書いてみたが紹介動画見る限りvs codeにアドオン入れてライブプレビューしながらuiの構築がサクサク行えるのは割といいな…

tauriは環境構築する段階でnodeのバージョンやら依存ライブラリの不備でエラーがでてしまい結構時間が掛かってしまった

**デフォルトの名無しさん** · 2024/05/04(土) 18:12:14.00

デスクトップアプリのここにグラフ出してくださいって言われて
対応できる環境は少ない

**デフォルトの名無しさん** · 2024/05/04(土) 19:49:33.93

他にいい表現方法があるなら自分で作って使ってりゃいいじゃん

**デフォルトの名無しさん** · 2024/05/04(土) 21:10:45.57

dioxusはあんま使われてない感じ？

**デフォルトの名無しさん** · 2024/05/04(土) 23:00:15.61

iced.rs

**デフォルトの名無しさん** · 2024/05/05(日) 10:17:39.98

>>821
Elm Architectureの設計パターンを覚える必要があるけどなかなかいいですね

**デフォルトの名無しさん** · 2024/05/05(日) 18:52:14.60

試してみたけど導入のカウンタの例がいきなりビルド出来ない…

バージョンの変更にドキュメントが追いついていないのは残念ですね…

**デフォルトの名無しさん** · 2024/05/05(日) 23:14:06.38

freyaはどう？

**デフォルトの名無しさん** · 2024/05/09(木) 16:51:54.63

https://blog.logrocket.com/state-rust-gui-libraries/

**デフォルトの名無しさん** · 2024/05/09(木) 22:53:04.47

一覧
https://lib.rs/keywords/cross-platform-gui

**デフォルトの名無しさん** · 2024/05/10(金) 22:11:46.56

Edera

**デフォルトの名無しさん** · 2024/05/11(土) 15:19:35.98

https://loglog.games/blog/leaving-rust-gamedev/
Rustはゲーム開発に向いてないという記事
C/C++を置き換えるという目標がまた一つ遠のいてしまったな

**デフォルトの名無しさん** · 2024/05/11(土) 16:10:55.98

Rust製ゲームエンジンが未成熟なんだから当たり前だろ😅

**デフォルトの名無しさん** · 2024/05/11(土) 17:53:51.16

Web開発は素早い実装と更新が必要だから
Rustは向いてない動的型言語が向いてる
みたいな記事は昔あった気がする

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

>>828
＞Rustが上手くなれば、これらの問題はすべて解消されます。
＞Rustは大規模なリファクタリングに優れているため、
＞borrowチェッカーのほとんどが自業自得の問題を解決します。
＞十分な経験を積めば、ユーザーは考えずにそれらを完全に予測し、生産的になります。
＞私はRustでさまざまなユーティリティやCLIツールを書くのをとても楽しんでいますが、
＞数行のコード以外はPythonよりも生産性が高いことがわかりました。
＞「コンパイラ駆動開発」をどこまで進めて、実際に成功できるのかと驚いたことが何度もあります。
＞Rustの最大の強みは、Rustにふさわしいコードを書いていると、物事が非常にうまくいき、
＞言語がユーザーを正しい道に導いてくれることです。

**デフォルトの名無しさん** · 2024/05/11(土) 19:27:53.90

>>828
この記事、ゲーム開発においていかにUnityがすばらしいかを伝えたいだけじゃん

**デフォルトの名無しさん** · 2024/05/12(日) 06:43:20.67

>>831
エキスパート専用、初心者お断り
というRustのいつもの欠点。