Rust part25

**デフォルトの名無しさん** · 2024/07/31(水) 00:46:26.17

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

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

**デフォルトの名無しさん** · 2024/08/13(火) 18:27:02.24

>>163
それはRustの問題じゃないよ
GC言語か否かの問題だね
GC言語は参照の有効性を気にしなくてもよい代わりに遅くてメモリを消費するペナルティ

**デフォルトの名無しさん** · 2024/08/13(火) 18:33:34.80

>>164
想定する利用ケースでコンパイルが通ればプログラマの意図通りで正しい
>>157の(5)の例もプログラマの意図通りでなかったためコンパイルエラーとなった
そしてコードを修正してコンパイルを通すことで意図通りの正しいコードになった

**デフォルトの名無しさん** · 2024/08/13(火) 18:35:53.44

「正しい」という言葉を多用する技術者にまともなやつはいない

**デフォルトの名無しさん** · 2024/08/13(火) 18:48:09.58

>>165
C/C++に比べても面倒では？
設計で防げる問題/考慮が要らない問題に対して必要以上のガードを書かされる感じ

例えばグローバルな変数 (一度だけ初期化され、以降は不変) に対して Sync が要るのも、初期化が複数スレッドから呼ばれた場合の安全性を保証しないとコンパイルが通らないからだけど、設計上それは要らないって場面はある
シングルスレッドなアプリだったり、マルチスレッドだけどスレッド生成は初期化の後であるいった場合

参照も同じで、設計上無効なデータを指すことがないといえるケースでも、コンパイラを納得させるために手動でライフタイム注釈を書く必要があるといった感じ

**デフォルトの名無しさん** · 2024/08/13(火) 18:49:04.65

>>167
>>157の「5) コンパイルされたならライフタイムの記述は正しい」が合っているかどうかの話が行われている
想定した使い方でコンパイルが通ったならば記述は正しい
何をどう想定するかでコードは変わりうる

**デフォルトの名無しさん** · 2024/08/13(火) 18:59:01.23

>>168
スレッド内でしか用いないならばthread_localにより!Syncでも使えるよ
「設計上それは要らない」「設計上無効なデータを指すことがない」という思い込みは絶対にダメ
例えば無効なデータを指さないが&'staticの意味ならばそれを使えばよいのだよ

**デフォルトの名無しさん** · 2024/08/13(火) 19:01:54.22

>>166
想定するケースが最初から全部書けるならそれでいいが、残念ながらそんな現実は無いよ
ソフトウェアテストの7原則のひとつ: 全数テストは不可能

それに、意図はコード化できるものばかりではない、unsafe関数のdoc-commentに書くべきsafety sectionだってそうだろう
コード化できなければ「プログラマの意図」ではないというのならそれも一理あるだろうが、多分誰も同意しないと思うぞ

**デフォルトの名無しさん** · 2024/08/13(火) 19:10:37.01

>>171
そんな大きな話はなされていない
一般的な話はRustの範囲を超えている
今回はRustのライフタイムの記述が正しいかどうかの話
想定した使い方でコンパイルが通ればそのコードは正しい＆安全となる
想定範囲を変えたり広げたりしてコンパイルエラーとなったならばそれに対応すればよい

**デフォルトの名無しさん** · 2024/08/13(火) 19:44:50.08

そもそもの話は「他の言語に比べてリファクタや設計変更がしづらい」という話では？
誰も「ライフタイムが提供する安全性が間違ってる」なんてレスはしてないよ
安全性の保証は強力だけど、そのぶん生産性を低下させ得るデメリットもあるよねって話をしてるだけで

**デフォルトの名無しさん** · 2024/08/13(火) 19:53:38.42

>>172
あなたが「コンパイルが通ればそのコードは正しい」というとき、それは利用側と定義側を含むコード全体の正しさのことを言っているんだよね

でも例のブログ記事は、利用側のfn main()の本体に何が書かれていようと、定義側のfn next()はそれ単独で「正しい」か（≒プログラマの意図通りか）を考えられる前提で書かれているんですよ
つまりmain()でnext()を1回呼ぼうが2回呼ぼうが、next()は変えていないんだから想定する意図は変わらない
最初からnext()は間違っていたことが、main()を変えたことで明らかになった、と

そう思ってもう一回読んでみてね？

**デフォルトの名無しさん** · 2024/08/13(火) 19:55:05.46

Dioxusのチームもこのような記事を書いている
https://dioxus.notion.site/Dioxus-Labs-High-level-Rust-5fe1f1c9c8334815ad488410d948f05e

GitHub Acceleratorに選ばれるくらい有望なプロジェクトだし、間違いなくレベルの高い開発者が揃ってるチームけど、彼らですらRustの課題を指摘してるわけで

**デフォルトの名無しさん** · 2024/08/13(火) 19:56:59.13

>>173
ライフタイムをコンパイラがチェックしてくれることで生産性は低下ではなく上昇でしょ
全てのコードを人間がチェックし続けたりチェックし忘れて実行時デバッグとなることが生産性の低下ですね
さらにその参照バグにきづかないままだとセキュリティホールを招いてしまいますよ

**デフォルトの名無しさん** · 2024/08/13(火) 19:57:14.06

>>157
めっちゃ判りますωωω

**デフォルトの名無しさん** · 2024/08/13(火) 20:05:14.94

>>174
最初のコードもコンパイラが通ってアサートも通って意図通りに動いている
次のコードはイテレータが返した値を保持したままイテレータを作動させられる仕様への変更 (今回の例は可能だが必ずしも仕様変更できるかどうかは別)
それぞれコンパイルが通れば意図通りに正しく動作している

**デフォルトの名無しさん** · 2024/08/13(火) 20:07:43.05

>>174
ほんそれ

**デフォルトの名無しさん** · 2024/08/13(火) 21:30:24.68

>>178
アサートも利用側のmain()にあるものなんだから、next()の呼び出し回数の話と同じで
ここからnext()についてのプログラマの想定を読み取ってたら、この記事が理解できないのは当然なんだってば
最初から理解する気が無くてそういう意地悪言ってるんじゃないよね？

修正後のプログラムの後に
> 今こうして前のプログラムを見返してみると、明らかに間違っていましたね。
って書いてあるんだから、これは仕様を変更したじゃなくて、最初から間違っていたのを修正したという体なんですよ

**デフォルトの名無しさん** · 2024/08/13(火) 21:51:35.56

>>180
一番最初に書いたようにその人の詭弁
後者の利用方法に対応する仕様にしたいならば最初からその後者用のアサートを入れたらよい
そうすれば一発でコンパイルエラーになって修正して終わり
ライフタイムに関してはコンパイルが通ればその利用方法については必ず正しい
コンパイルが通ったのに間違っていることはない

**デフォルトの名無しさん** · 2024/08/13(火) 22:37:13.69

もう少しわかりやすい別の例を出すと

struct Foo(&str, &str);
このライフタイム注釈が無いのは当然エラーになるのは置いとくとして

struct Foo<'a>(&'a str, &'a str);
このように宣言しても多くの用途で困ることはなく
むしろこれで都合がよいこともある
つまりこの宣言方法はバグではない
そしてこれでコンパイルが通る範囲の利用方法をしていれば正しく動作する

しかし用途によっては上記では困りエラーとなる利用方法もある
そこで
struct Foo<'a, 'b>(&'a str, &'b str);
このように宣言することで新たな利用方法に対応が可能となる
こちらに変えてもそれでコンパイルが通る範囲の利用方法をしていれば正しく動作する

どちらのケースでもコンパイラが通せば各々の利用範囲でライフタイムの記述は正しい
コンパイラが通したのに間違っているなんてことは起きない

**デフォルトの名無しさん** · 2024/08/13(火) 22:44:00.39

>>181
じゃあ別の切り口から
next()を単独で見てみようか
結局、問題の根本は戻り値のbyte(=&self.remainder[0])としてあり得る最大のlifetimeは'remainderなのに、それより小さい'mut_selfを指定してしまっていることだよね
trait実装の場合にはtraitの宣言に合わせるために実際より小さいlifetimeを指定しないといけない場合があるしれないが、この例は単なるミスで'mut_selfでなくてはいけない理由は特に無いということだった

このnext()の定義を単独で見て、おかしなところは本当に何も無いのか？
next()が正しくないということを示すために、main()の内容を考慮する必要が本当にあるのか？

別にコンパイルエラーになることをいちいち確認しなくても、「なんかおかしいなこれ」って早く気付いて修正できるならそのほうがいいでしょ、って個人的には思うけどね

**デフォルトの名無しさん** · 2024/08/13(火) 22:54:24.44

こちらの主張は最初から一貫して
>>157の記事「『5) コンパイルが通ればライフタイムの記述は正しい』は間違っている」
という主張とその説明例は詭弁だということ

以下は常に正しい
『5) コンパイルが通ればライフタイムの記述は正しい』

自分の意図通りの使い方をした利用範囲でコンパイラが通ったのならば
その利用範囲で記述は正しい
利用するつもりのない利用方法に必ずしも対応する必要がないことは>>182で説明した

**デフォルトの名無しさん** · 2024/08/13(火) 23:11:58.95

>>184
ここまでのあなたの主張は正確に言えば「*十分に実際のユースケースを反映した利用側コードとともに* コンパイルが通ればライフタイムの記述は正しい」じゃないか
強い前提を置けば正しいと言える確度も高まって当然だろう
勝手に前提を変えて違う結論を導くのは、それこそ詭弁ではないか

**デフォルトの名無しさん** · 2024/08/13(火) 23:29:33.49

利用方法とその範囲は各実際のケースで各々異なるのだよ
あらゆるケースを想定して対応することは必要ないだけでなく事実上無理なこともあるだろう
必要となるケースのみ対応すればよい
そして必要となるケースはプログラムとして書かれているかテストコードに書く
どのようなケースでもコンパイルが通ればその記述コードは正しい
コンパイルが通ったのに誤動作することは起きない

**デフォルトの名無しさん** · 2024/08/13(火) 23:29:58.94

next()で戻り値のlifetimeを不必要に小さくしているのが、単独で見て「普通に考えるとおかしい」と言えるように
>>182の構造体の例も、「普通は」struct Foo<'a, 'b>(&'a str, &'b str);のように分けるべきだろう
例外は実際に.0も.1も同じStringの部分列であることを想定しているような、同じlifetimeを持つ参照から作ることが想定されている場合か、他にもあるかもしれんが

あと例の「Rustのライフタイムについてのよくある誤解」にもある通り、こういう具体的なメンバを想定したlifeitme in pathには'inputとか'bufとか説明的な名前を付けるべきである
そうすれば「あれ、よく考えたらこの.0と.1って同じlifetimeで本当にいいのか」ってことを、利用側でコンパイルエラーになるのを待たず考慮できるとは思わんのかね
'aみたいなテキトウな名前のlifetimeが許されるのは汎用的なコンテナくらいだろう、Iter<'a, T>とかRef<'a, T>とかCow<'a, T>とか

そういう嗅覚というか、経験知みたいな情報は誰も持ち合わせちゃいないのかね

**デフォルトの名無しさん** · 2024/08/13(火) 23:36:10.30

複オジに何を言ったところで時間の無駄
そろそろ気付いてね

**デフォルトの名無しさん** · 2024/08/13(火) 23:40:06.70

同じところで生まれるものしか取り扱わない場合にFoo<'a, 'b, 'c, 'd, 'e>とする必要はない
そこをFoo<'a>でコンパイルが通る使い方をしているならばFoo<'a>で正しい
どちらかが間違っているという変な考えを捨てよう

**デフォルトの名無しさん** · 2024/08/13(火) 23:46:03.09

>>188
反論を通じて考えを整理しているという面もあるので
マサカリ歓迎

**デフォルトの名無しさん** · 2024/08/13(火) 23:55:49.36

>>175
読んだ
大雑把な要約

Rustは非常に素晴らしく成功しているがまだ改善できる点がある
一方で既存の言語には問題があり
他の新言語は社会的賛同が低い
そのため唯一の解決方法はRustをさらに改善に導くことである
そこで具体的な改善案を示す

**デフォルトの名無しさん** · 2024/08/14(水) 00:30:36.57

>>187
> >>182の構造体の例も、「普通は」struct Foo<'a, 'b>(&'a str, &'b str);のように分けるべきだろう
> 例外は実際に.0も.1も同じStringの部分列であることを想定しているような、同じlifetimeを持つ参照から作ることが想定されている場合か、他にもあるかもしれんが
これについていえば、必要なのは「構造体は自身よりも寿命の短いデータへの参照を持たない」ことなので、基本的には Foo<'a> だけで済むと思う

fn func() {
　let a: String = "foo".to_owned();
　{
　　let b: String = "bar".to_owned();
　　{
　　　let c = Foo{&a, &b};
　　}
　}
}

これはaとbは違う寿命を持つけど、Fooとしては「c が生きているうちに a と b の寿命が尽きない」ことが保証されてれば良いだけなので、aとbの寿命の区別までは必要まではない
だからメンバーは Foo<'a> の寿命である &'a だけで済むという感じ
自分の認識違いだったらすまん

**デフォルトの名無しさん** · 2024/08/14(水) 00:42:39.43

働け

**デフォルトの名無しさん** · 2024/08/14(水) 01:41:38.41

>>153
ライブラリが乱立してる点

**デフォルトの名無しさん** · 2024/08/14(水) 02:10:03.49

>>194
まずasync/awaitはRustの標準機能
そして使われるFutureやPollやWakerなど各種はRustのcore標準ライブラリにありno_stdでも使える
asyncランタイムは用途ごとに適したものを自由に作ったり選んだり使える
標準的に使われるものはtokioがダウンロード10倍差で圧勝しており乱立と悩まなくていい

**デフォルトの名無しさん** · 2024/08/14(水) 06:30:03.80

>>164
ライフタイム注釈が間違っているのにコンパイルが通ってしまい正しく動作しない、というプログラム例を一つでも示せばよいのではないか？
そんな例は存在しないと思う
コンパイルが通ったらそのプログラムでライフタイム注釈は間違っていなくて正しく動作するよ

**デフォルトの名無しさん** · 2024/08/14(水) 09:24:59.76

挙げた手降ろせない子どもすごい増えたよな
折り合いつける知能もない

**デフォルトの名無しさん** · 2024/08/14(水) 09:32:09.98

>>183
>trait実装の場合にはtraitの宣言に合わせるために実際より小さいlifetimeを指定しないといけない場合があるしれないが

kwsk
そっちの方が知りたい

**デフォルトの名無しさん** · 2024/08/14(水) 10:02:37.51

Tokioが圧勝しているせいでtokio でしか使えないライブラリが出てきていて、tokioが終わったらRustのasyncもオワる状況

**デフォルトの名無しさん** · 2024/08/14(水) 10:09:25.77

tokio以外を考慮してるライブラリの方が少数派だろ

**デフォルトの名無しさん** · 2024/08/14(水) 10:09:58.25

>>199
GAFMなどIT大手がtokio直接支持してるから不滅だよん

**デフォルトの名無しさん** · 2024/08/14(水) 10:12:07.88

>>201
GAFMは飽きっぽいから、支援されてるから不滅ってことはない
あ、Rustの寿命がそれより先に来るってことかな？

**デフォルトの名無しさん** · 2024/08/14(水) 10:21:35.01

Rustに代わりうるプログラミング言語の芽すらないよん
IT大手各社が結束して同じ新言語を支持したのはRustが最初で最後かな～

**デフォルトの名無しさん** · 2024/08/14(水) 10:31:23.23

>>203
zig 1.0待ちだろ

**デフォルトの名無しさん** · 2024/08/14(水) 10:45:06.96

Rustより保証してくれることが減ってしまう言語は代わりにならないよん

**デフォルトの名無しさん** · 2024/08/14(水) 10:50:42.29

良いか悪いかよりも一貫しているかどうかが寿命を決める。
(いや、及第点程度には良いものである必要はあると思うけど。)
C がよい言語とはとても言えないけど皆が一貫して使ってたから価値あるものとして認められてたわけで。
プログラミング言語も言語だからね。

**デフォルトの名無しさん** · 2024/08/14(水) 10:51:49.79

>>192
lifetimeって究極的には関数の引数と戻り値の間でのリソースの依存関係を示すものだから
FooのメソッドもFooを引数に取る関数も無いなら、どっちでもいいよとしかならんと思う
そして実際にメソッドや関数を定義するときになったら、別々になっていたほうが一番柔軟に指定できるから、第一選択としては分けておいたほうがいい、というのが俺の直感

>>196
「コンパイルが通ってしまい正しく動作しない、というプログラム」が作れてしまうことを問題にしているのではない
「コンパイルは通って正しく動作もするが、制約が強すぎるために使える状況が過剰に限定される関数」が作れてしまうということを問題にしている
だから前者の例を出すことに意味は無いし、あなたもよく知っている通りそれは実際できないだろう
そして「Rustのライフタイムに関するよくある誤解」5)のnext()は後者の問題を示す例になっている

>>196
trait Iteratorではそうなっていないけど、例のnext()が別のtraitのメソッドfn next<'a>(&'a self) -> Option<&'a u8>として宣言されていれば、実装側はそれに従わざるを得ない、と思ったけど
現実にそんなことが要求されることがあるか、と聞かれるとちょっと微妙かも

**デフォルトの名無しさん** · 2024/08/14(水) 12:46:04.27

zigは本当に最強

**デフォルトの名無しさん** · 2024/08/14(水) 13:07:18.24

>>174
>> next()を1回呼ぼうが2回呼ぼうが、

Rustではその1回目のnext()の値を保持したまま2回目を使えるかどうかの違いが大きいんだよ

最初の仕様は各々の値が使えれることが確認できればいい仕様になっているね
assert_eq!(Some(&b'1'), bytes.next());
assert_eq!(None, bytes.next());

その次の仕様は1回目の値を持ったまま2回目の値を使える仕様になっているね
let byte_1 = bytes.next();
let byte_2 = bytes.next();
if byte_1 == byte_2 {
// 何かしらの処理
}

つまり拡大された別の仕様となっているわけだよ
そのため最初の仕様ではライフタイムがselfと同じでも全く問題ないけど
次の仕様ではselfと異なるものでないといけなくなる
そこが本質があってどちらの仕様も別のものとして存在しているわけよ

わかりやすく例を挙げて説明すると
次のように&[T]ではなくVec<T>を保持するバージョンに変えてみよう

**デフォルトの名無しさん** · 2024/08/14(水) 13:08:44.09

>>209の続き
相違点以外は元コードと同じ名前と形で書いています

struct ByteIter {
vec: Vec<u8>,
index: usize,
}

impl ByteIter {
fn next(&mut self) -> Option<&u8> {
if self.index >= self.vec.len() {
None
} else {
let byte = &self.vec[self.index];
self.index += 1;
Some(byte)
}
}
}

参照を持たなくなったので一見すると有利になっているように見えるけど
最初の仕様しか満たせなくなってる！
ところがこれはGATを用いたLending Iteratorでは当たり前の仕様なんだよ
つまり制限された間違った仕様というよりは別の仕様と捉えることもできるんじゃないかな

**デフォルトの名無しさん** · 2024/08/14(水) 19:39:11.70

>>209-210
「ByteIterはバイトのスライスを繰り返すイテレータです」
「今こうして前のプログラムを見返してみると、明らかに間違っていましたね」

とかの日本語で説明した文章をすべて無視して、コンパイルの通ったRustコードだけを正しいものとして「プログラマの意図」を見出そうとすると、そうなるんだね
どう考えるとそういう結論に至るのかはよく分かった

**デフォルトの名無しさん** · 2024/08/14(水) 19:54:05.99

>>211
最初のプログラムのどこが間違っていると主張していますか？
assertも通って機能していますよ

**デフォルトの名無しさん** · 2024/08/14(水) 20:38:24.97

日本語を読めば分かるよ
新ネタ無さそうならもう終わりにしとくね

lending iteratorって発想は無かったから、そこだけは面白かったかもね

**デフォルトの名無しさん** · 2024/08/14(水) 20:56:34.44

>>213
最初のプログラムでイテレータの仕様を満たしており正しく動作していま
すよ
コードに問題はありません

その後に行われようとしているのはイテレータの仕様とは別の
以下を通す新たな仕様を満たすための拡張です

| let byte_1 = bytes.next();
| 　　　　　 ----- first mutable borrow occurs here
| let byte_2 = bytes.next();
| 　　　　　 ^^^^^ second mutable borrow occurs here
| if byte_1 == byte_2 {
| 　 ------ first borrow later used here

両者を区別できていますか？

**デフォルトの名無しさん** · 2024/08/14(水) 23:52:37.44

最初のプログラムは関連型のItemを定義できないからIteratorの仕様を満たせないだろ
type Item = &'a u8;
だと拡張（というか修正）した方のコードになる
「正しい」の意味が噛み合ってないことに気付こう

**デフォルトの名無しさん** · 2024/08/14(水) 23:59:55.13

結局>>157の記事は破綻してるんだな
イテレータをstd::iter::Iteratorだけを指す狭い意味に取ると
その記事の最初の&u8をItemにした時点でコンパイルエラーとなるから記事は破綻
イテレータを広い意味にとってその記事の方法でもOKとすると
最初の実装でイテレータとしての機能は満たしていて
それを&'a u8にする必要はなくなり記事は破綻

**デフォルトの名無しさん** · 2024/08/15(木) 00:04:11.15

「コンパイルが通ったならばライフタイムの記述は正しい」で常に合ってるのに、
それがいかにも間違ってるかのように仕立て装うから矛盾が出てる感じ。

**デフォルトの名無しさん** · 2024/08/15(木) 13:27:43.17

Rustは良い言語だと思うけど
清書用だね

**デフォルトの名無しさん** · 2024/08/15(木) 14:13:48.29

他の言語よりバージョン管理（git）の技術が問われる気がする
全体の整合性が求められるから個人開発でもまじめにブランチ使わないとしんどい

**デフォルトの名無しさん** · 2024/08/15(木) 14:43:48.85

>>219
整合性が求められるのはどの言語でも同じ
どの言語でもgitを使うかどうかブランチを切るかどうかの方針や判断は同じようになされて言語とは関係ない

**デフォルトの名無しさん** · 2024/08/15(木) 15:14:57.56

Rustはコンパイル通らないと嫌な気持ちになるから整合性が必要
動的言語はバグってても笑えるから整合性は不要

**デフォルトの名無しさん** · 2024/08/15(木) 15:28:46.91

>>218
Rustはリファクタリングに適していて
そのプログラムの本質のロジック以外のほとんどのミスをコンパイルエラーにしてくれるから
いきなり書き出し始めていってもなんとかなるよ
同じ機能が出てきた時点でtraitにして重複コードがあればそのprovided methodにするとかね

**デフォルトの名無しさん** · 2024/08/15(木) 15:33:22.56

「全体の整合性が求められるから」は「全体の整合性をコンパイラにチェックされるから」に読み替えてくれ
コンパイル通らないと嫌な気持ちになる以前にテストできないだろｗ

**デフォルトの名無しさん** · 2024/08/15(木) 16:10:36.88

モノリシックな巨大なコードを作らずにクレイトに分けよう
クレイト毎にコンパイルできる

**デフォルトの名無しさん** · 2024/08/15(木) 16:13:34.27

自分だけかもしれないけど、新規にコードを書くとき/リファクタするときにエディタにワーニングが表示された状態になるのが精神的に負荷がかかるんだよね
だから新しく作ったファイルの先頭でまず #![allow(dead_code)] するね…
（ある程度コードができてきたら取り払うけど）

**デフォルトの名無しさん** · 2024/08/15(木) 16:23:19.81

>>218
分野によってはそう思う
探索的なデータ分析をするとか画像処理のアルゴリズムを考えるとか、そういう場面だとPython等で試してからRust等に移植というのは分かる
「書いて捨てる」を前提にするにはRustはやや重い

**デフォルトの名無しさん** · 2024/08/15(木) 16:53:43.32

それはPythonに慣れてるだけじゃないか？
Python使ったことない人でもそうなるわけではない

**デフォルトの名無しさん** · 2024/08/15(木) 17:04:07.16

コンパイルワーニングやエラーが負荷になる人は動的言語でのテストファーストな開発も負荷になりそうだね。

**デフォルトの名無しさん** · 2024/08/15(木) 17:18:57.30

慣れというのは否定しないけど、そもそもコンパイル必要な言語とそうでない言語の違いだな
コード書いて Ctrl + S で保存すればすぐに変更後の動作を試せるのは大きい
特にRustなんてコンパイル時間長いんだし
書き捨てる前提の実験的なコードで完璧を目指すものでもないでしょ

**デフォルトの名無しさん** · 2024/08/15(木) 17:31:23.55

そんなにコンパイル言語が嫌いなら使うな
このスレから永久に出ていけ

**デフォルトの名無しさん** · 2024/08/15(木) 17:40:55.12

自分は用途によっては他の言語も使うとしか書いてないんだが
宗教的あるいは能力的に一つの言語しか使えないんです？

**デフォルトの名無しさん** · 2024/08/15(木) 17:53:40.88

特性の真逆なスクリプト言語と比較しても既知の話ばかりで新たな知見も情報も得られないからなあ
ノイズとなるだけのスクリプト言語との比較の話は禁止しようぜ
やりたい人は別スレを立ててやればいい

**デフォルトの名無しさん** · 2024/08/15(木) 18:21:12.60

自分が言いたかったのは「Rustは清書用」というレスへの同意だけなんだよな
特定の言語を推したり比較したりしたいわけではなく
これ以上の話はスレチになりそうだからやめとく

**デフォルトの名無しさん** · 2024/08/15(木) 18:25:33.11

俺はRustの方が慣れてるため最初からRust使うので慣れの問題だと思う

**デフォルトの名無しさん** · 2024/08/15(木) 18:46:44.09

スクリプト言語で下書きするっていっても直和型もないような言語だと
Rustで清書するときにデータ構造からやり直しだし
どういう言語を想定してるんだろ
TSとか？

**デフォルトの名無しさん** · 2024/08/15(木) 18:58:18.84

画像処理みたいな純粋なアルゴリズムの検討ならあまりそういう問題はないだろうけど
単なる数値計算なら別に最初からRustでいいと思うんだよな
DLみたいに既存のフレームワーク使うためにPythonで検討したいとかなら分かるんだけど

**デフォルトの名無しさん** · 2024/08/15(木) 18:59:39.70

アプリ全体の設計レベルだと流石に下書きなんてしないと思う
あくまでも部分的な話で、例えば画像処理なんかだと整数または小数型の多次元配列だけ扱えれば良いので

**デフォルトの名無しさん** · 2024/08/15(木) 19:32:04.42

RustやC++で書かれたライブラリを呼び出すだけの話ならばどの言語でも同じだから議論の意味ない
そうではなく自分でプログラムを組んで実行するなら最初からRustで書けば高速実行できる

**デフォルトの名無しさん** · 2024/08/15(木) 20:01:33.38

実験的な変更の波及範囲が広いんだよね
エラーの種類を増やすためにenum ErrorKindに新しい要素を追加したらErrorKindをmatchで網羅してるDisplayの修正も必要になるとか
最終的には必要な変更だから修正漏れを防ぐ意味では助かるけど一時的な変更だとちょっと大変
バージョン管理が適当だと戻すのも面倒になる

**デフォルトの名無しさん** · 2024/08/15(木) 20:17:28.56

>>239
thiserrorを使いなさい

**デフォルトの名無しさん** · 2024/08/15(木) 22:15:21.69

不満を言う人は単なる不慣れとそれによる知識不足という感じですねー

**デフォルトの名無しさん** · 2024/08/15(木) 22:23:50.08

慣れてくるとサボり方も分かってくるからあまり困らんよね
とりあえずunwrapやtodo!多用してメインのパスだけ作ってしまうみたいなのはよくやる

**デフォルトの名無しさん** · 2024/08/16(金) 01:41:31.76

で、Rustのコンパイル時間は改善されてるのかい？

**デフォルトの名無しさん** · 2024/08/16(金) 08:44:44.18

>>242
あとはclone連打したりBoxに入れたり

**デフォルトの名無しさん** · 2024/08/16(金) 11:16:32.52

cargo build とかで rustc にオプションを渡すにはどうすれば良いですか
特定の hoge.rs に対してだけ出来ると有難いです

**デフォルトの名無しさん** · 2024/08/16(金) 11:33:25.98

clone減らしても結局処理速度変わらなかったりする

**デフォルトの名無しさん** · 2024/08/16(金) 11:41:08.16

>>245
cargo rustcかRUSTFLAGS

**デフォルトの名無しさん** · 2024/08/16(金) 13:42:33.29

>>244
おまえらのために作ったった

// お手軽グローバル変数キット
#[macro_use]
mod x {
pub struct X<T>(pub std::sync::LazyLock<std::sync::Mutex<T>>);
#[macro_export]
macro_rules! x_init { ($x:expr) => { X(std::sync::LazyLock::new(|| std::sync::Mutex::new($x))) } }
#[macro_export]
macro_rules! x { ($x:ident) => (*($x.0.lock().unwrap())) }
}
use x::X;

// グローバル変数の宣言の仕方
static FOO: X<i32> = x_init!(999);
static BAR: X<Vec<i32>> = x_init!(vec![1, 2, 3]);

// グローバル変数の使い方
fn main_() {
x!(FOO) += 1;
assert_eq!(x!(FOO), 1000);
x!(BAR).push(777);
assert_eq!(x!(BAR), [1, 2, 3, 777]);
}

**デフォルトの名無しさん** · 2024/08/16(金) 14:04:22.59

純粋な質問だけどマクロ使わずにできる？
以下のような感じに

static x: X<中身の型> = X::new(初期化式);
assert_eq!(&x, 中身の型と比較可能な値);
x.do_something(); // メソッド呼び出し

**デフォルトの名無しさん** · 2024/08/16(金) 14:20:39.96

>>249
Mutexへの参照を持つMutexGuardを持つスコープ内でしかDerefできない
つまりメソッドを定義してDerefした結果の参照を返すのは無理
この仕組みにより参照をスコープ外へ持ち出せなくしていることが肝
ただしMutexGuardを返すメソッドは実現できる
その場合は自分でDerefして使うことになる
それにより具体的には *Foo.x() += 1; として使うメソッドx(&self)は実現可能

**デフォルトの名無しさん** · 2024/08/16(金) 14:28:26.26

>>249
それだけならできるよ

**デフォルトの名無しさん** · 2024/08/16(金) 14:28:39.39

>>248
こんなのZigならcomptime付ければ解決だろ

**デフォルトの名無しさん** · 2024/08/16(金) 14:43:23.29

>>252
グローバル変数、すなわち、タスクやスレッドが排他制御して安全に扱える話をしているところで、comptime？？

**デフォルトの名無しさん** · 2024/08/16(金) 15:12:00.16

Rustでもコンパイル時に作れるものは簡単にグローバルな定数にできる
問題なのは HashMap みたいなヒープを使うもので、LazyLockが必要になるのもほぼこのようなもののためだと思う
初期化した以降は不変な操作しかしない定数のような使い方をする場合でもMutexが必要なのは仕方ないという感じなのか

**デフォルトの名無しさん** · 2024/08/16(金) 15:14:27.12

>>254
すまんこれは勘違い
不変ならLazyLockだけで足りそうだ

**デフォルトの名無しさん** · 2024/08/16(金) 15:20:06.84

>>254
読み出しだけならMutexは不要

static READ_ONLY: LazyLock<Vec<i32>> = LazyLock::new(|| vec![1, 2, 3]);
assert_eq!(*READ_ONLY, [1, 2, 3]);

**デフォルトの名無しさん** · 2024/08/16(金) 17:40:52.16

LazyLockは油断するとデッドロックの要因になりそうだな
初期化が単純なうちはいいけど

**デフォルトの名無しさん** · 2024/08/16(金) 18:31:48.52

LazyLockは排他制御をRust1.0からあるstd::sys::Onceに任せている
その部分はOS依存だが例えばLinuxなどの場合、
未初期化か初期化中か初期化済かなどの状態を示すatomic整数で管理している
そして初期化実行は最初のスレッドのみで起きてそこでの競合は起きないことを保証している

一方で、あるLazyLock利用変数Aの初期化関数で資源Xを利用している時に、
資源Xをロックしたままの状態でその変数Aに最初にアクセスすればデッドロックとなりうる
これは一般的な話と同じなので今回特有の問題ではない
いわゆる資源ロック優先順序付けをA＞Xとするだけで回避できる

ちなみに、LazyLock初期化後のT読み出し追加コストはその状態整数を見ることだけになり、
「初期化済」状態でずっと変わらないため分岐予測もおそらくずっと成功
そのためコストは気にせずに使える

**デフォルトの名無しさん** · 2024/08/17(土) 01:30:12.83

小さなTauri v1アプリをv2 RCにアップグレードしたら
リリースビルドのファイルサイズが2倍になったんだが

ファイルサイズ小さいのが売りじゃなかったのか？
6MBが12MBになったぞ

**デフォルトの名無しさん** · 2024/08/17(土) 13:50:23.56

TauriのことはJavaScript/TypeScriptスレでやれよ

**デフォルトの名無しさん** · 2024/08/17(土) 14:00:58.13

>>260
Rust のバイナリにリンクする部分は Rust の話じゃね？

**デフォルトの名無しさん** · 2024/08/17(土) 14:22:14.92

もしRustやRustの汎用ライブラリのバージョンを変えてバイナリサイズが増えたのならRustの話なのでここでやればいい
しかしアプリのバージョンを変えてサイズが増えたのだからアプリの話であってRustスレで語ることはなにもない

**デフォルトの名無しさん** · 2024/08/17(土) 14:27:21.91

もしかしてTauriがRustのライブラリだと知らない人？

**デフォルトの名無しさん** · 2024/08/17(土) 14:30:56.85

Rustに問題があると読めそうな文章なら手段を選ばずに排除する人

**デフォルトの名無しさん** · 2024/08/17(土) 15:23:05.55

rustコードをコンパイルしたwasmバイナリが増えたってこと？